Pull to refresh

Comments 81

> никогда не используйте
> никогда так не делайте в реальных проектах


Извините, может быть я чего не понимаю, но в чем тогда смысл таких задач? Проверить знание всевозможных извратов, возможных в языке?
Да, экзамены не нацелены на проверку знаний чего-то удобного и крутого (отчасти), что можно использовать в проектах, а только если что нового разработчики скрыли в недрах Java и как не напороться на грабли по большей части.
Чтобы знать все тонкости языка/компилятора и понимать, почему та или иная вещь сделана именно так.

Лично я с удовольствием перетяну в свой c++ код правило обозначать тип большого целого числа только большой буквой L. Хотя, казалось бы, каким боком c++ к java.
Я готовлюсь сейчас к этому экзамену и меня это тоже просто вымораживает. Несмотря на то что я могу программировать на яве вполне нормально, я не могу выбить больше 60% из тестовых заданий ну никак — потому что 50% задач которые приходится решать первым делом вызывают вопрос «какой идиот это писал?». И все чем я занимаюсь готовясь — учу в основном фокусы и тонкости которые никто никогда не будет использовать, и ловко отличать фишку которая скомпилируется явой от той которая не скомпилируется явой. Плюс составители обожают писать код для заданий наплевав на все правила программирования, например назвав вперемешку классы, интерфейсы и методы A/B/C и D и слепив из них жуткое месиво наследований, имплементаций и выводов и задва гениальный вопрос «что выведет данный код?» не забыв добавить вариант ответа «не скомпилируется».
Короче это жуткий экзамен на фантастическую въедливость во все тонкости языка и внимательность.
Смысл в том чтоб кто-то заплатил Ораклу за сертификацию, и даже если этот кто-то серьезно программирует ему должно быть трудно пройти тест, чтоб не было ощущения дешевки.
Мне в свое время было просто интерестно оценить уровень своих знания на всевозможных тестах. Поробовал симуляции тестов на exambraindumps.com/ просто ради удовольствия. Когда делать нечего, то мозги очень хорошо разминаются. Как бонус можно оценить сможешь ли здать реальный сертификационный экзамен.
Некоторые вопросы предостерегают вас от ошибок, о которых я написал в пояснениях. И вообще в исходниках чужих всякое встречается. ИМХО — надо глубоко знать язык, особенно если у него есть жёсткая спецификация.
UFO just landed and posted this here
Разделяю ваше мнение по поводу сертификации. Они полезны только в тех компаниях, куда нормальные разработчики ни за какие деньги не сунутся, имхо :)

Есть у нас в универе один препод с over9000 сертификатами от Microsoft и т.д., но стоит его спросить о чем то реальном, так он так плавать начинает, что аж самому неловко становится от того что спросил это :)
У меня достаточно знакомых, которые работают на хороших должностях в крупных компаниях и они все утверждают, что сертификаты дают значительный бонус при устройстве на работу. Хотя да, есть процент работодателей, которых не волнуют сертификаты, но он не велик. Возможно, вам просто не повезло =)
Всё почти как с институтским дипломом блин.
Не подскажете, что за «значительный бонус» такой мифический?
Например, в случае двух людей на одно место скорее берут того человека, у которого есть сертификат. Кроме того, в некоторых компаниях на более высокие должности берут только при получении соответствующего сертификата — и повышают зарплату также. Речь идёт о крупных компаниях.

«Без бумажки ты букашка, а с бумажкой — человек!» (с) советский поэт
Это какой-то очень синтетический случай. Если на собеседование пришел человек, которого ты готов взять на работу (независимо от того что за сертификаты у него, есть ли во, служил, сидел и тд) это уже повод плясать джигу, но чтобы сразу двое — ну, так просто не бывает.
Я вот, кстати, такого же мнения — нормальных специалистов днем с огнем не сыщешь, когда такой появляется — это праздник просто. И все это знают — и наниматели, и сами специалисты. И зачем этому специалисту тратить время и силы и деньги на прохождение сертификации, которая к его опыту ничего не добавит, и на которую никто все равно не смотрит? Вот и получается ситуация, что человек с сертификатами уже скорее подозрение вызывает :)
Сертификаты волнуют работодателей из-за проведения тендеров (нужно N-сертифицированных специалистов). Да это нравится HR-ам, но сомневаюсь что сертификаты произведут впечатление на людей которые проводят техническое интервью.
Удивлен этим — за 11 лет карьеры не помню ни одного раза, чтобы сертификат по яве зачитывался хоть сколь-либо существенно сам по себе. Может, озвучите названия крупных компаний? Любопытно просто, что это за компания, которая, скажем, разработчику с опытом даст/не даст бонус только на основании сертификата.
Странно, мне там про это не упоминали. Ну да ладно, главное, чтобы все были счастливы :)
Вот я теперь не знаю, кому верить =)

Но я не пожалел что сдал его, потом планирую ещё и OCP сдать. Пускай для портфолио будут. Вообще это больше как личный мотиватор к качественному изучению курса по Java. Причём к широкому изучению. Например, я не пожалел что изучил Formatter и регулярные выражения (готовился-то к SCJP 6). Потом нашёл им применение, а раньше о них даже не знал.
Великолепная описка в итогах:

Мне нравится Java за её жёсткую стандартизованность. Спецификация определяет практически все тонкости с очень большой тонкостью. А значит — изучив эти тонкости один раз — вы сможете работать с ними везде.


Хехе :)

А на самом деле, я даже рад, что не во всех вопросах правильно ответил
Ну если все тонкости спецификации всегда помнить, то и JavaScript недоумения не вызывает. Это можно про любой язык сказать.
Опять это дрочерство. Лучше JavaEE учите, полезнее будет.
Да, должен же кто то джава бины клепать для говноформочек к базам данных.
можно подумать на JavaEE только джава бины к говнофомочкам делают… вы, судя по всему, совсем не знаете JavaEE
orly?
я работал в дойче банке и других компаниях такого уровня и прекрасно представляю себе, какие проекты делаются на java SE и какие на java EE. EE используется для нетребовательных проектов как раз уровня говноформочек к БД, потому что это промышленный подход, не требующий особого знания кишок машины, системы и окружающей среды. И вот те самые клепатели этих CRM и прочего считают себя реальными хардкор прогерами и удивляются, зачем же надо знать про кишки JVM и особенности компиляции. Вам не надо, расслабьтесь.
Ну так зачем знать чо там как в JVM, если тебе что-то нужно, а для этого не существует аннотации — значит этого не существует в принципе.
Судя по некоторым, их тех, кого приходилось собеседовать или с кем пришлось поработать, сарказма тут маловато.
Это вам просто так везло. Мне приходилось делать красивые и удобные биллинговые системы под веб и заниматься оптимизацией крупных кластерных приложений. Всё на Java. Поэтому я не согласен с вашим обобщением. Хотя это может просто мне так повезло с работой.
Не хочу теперь в дойче банк :)
По поводу букв. F допускается в шестнадцатеричной форме: это 15.
Интересно, сколько пользователей, решивших этот тест, ответит больше чем на половину?

Я неправильно ответил только на 3-й вопрос. Меня сбило с толку нижнее подчеркивание. Хотя, если бы меня попросили пояснить, то я бы пояснил не все. То есть, местами угадал просто. Спасибо, узнал кое-что новое.
UFO just landed and posted this here
Наоборот, прибавлять нужно — тогда появится различие. Разумеется, на исходном тексте, а не на пиксельной картинке.
Хотя убавить тоже можно, разница будет в нижней засечке.
Для того и пишут заглавную l. Вроде бы, нетбинс и идея на такое даже ругаются.
Я не очень понял насчёт заглавной L (пока что не прорешал задачи, надо сделать это обстоятельно, а не наспех), но если имеется в виду Long вместо long, то это совершенно не одно и то же, и так без нужды делать не стоит. Первое — объект, а второе — примитивный тип. В вычислениях объект придётся превращать в примитивный тип, и это вызовет ненужные проблемы с эффективностью кода. А если результат нужно будет записать обратно в переменную, то ещё и создастся новый объект в процессе автоупаковки.
Речь об L в константе: 201L

BTW Следуя привычкам я бы определил константу в теле класса, убив интригу и неоднозначность восприятия:
public static final long YEAR_201 = 201L;
Значит, я даже с масштабом не там единичку разглядел. Ещё удивился насчёт типов.

Константа тут, мне кажется, не очень поможет. Если прописать в названии число, то тогда потом, когда оно поменяется, придётся её переименовывать, что не очень хорошо. А если не прописать, то тогда и разницы между константой и переменной особенно нет. Неоднозначность тут убирает именно заглавная L. Я сам обычно в литералах чисел строчные вообще не пишу, чтобы такая проблема не возникала.
Не зависимо от того, находится буква L в нижнем регистре или верхнем, в конце целочисленного литерала она всегда означает примитивный тип long.

Для случая Long year = 201L; автоупаковка будет также произведена.
Да единицу я не там просто разглядел. Рано утром смотрел, показалось, что в начале long единица, а в конце литерала L, а там на самом деле наоброт.

Что касается автоупаковки, я имел в виду случай вроде этого (случай, разумеется, надуманный, чтобы было нагляднее):

Long year = 201L;
for (int offset = 0; offset < 100; offset++) {
    year += offset;
}

В первой строчке запакуется только один раз, что ни на что особенно не повлияет, но потом каждый раз будет распаковываться, когда нужно что-то сделать со значением.
Пардон, хотел написать «а в конце литерала всё как надо», не успел отредактировать.
хром на маке

eclipse

хром на андроиде

ЧЯДНТ?
Перечень моноширинных шрифтов не заканчиваются на monaco и droid mono. И я бы сказал что шрифты и должны быть такими, в которых нельзя спутать 0/O, 1/l
Именно поэтому я предпочитаю anonymous pro на linux. Без нормального шрифта можно выстрелить в ногу. Особенно в языках с динамической типизацией.
UFO just landed and posted this here
И я бы сказал что шрифты и должны быть такими, в которых нельзя спутать 0/O, 1/l

Угу, стандартная настроечная таблица шрифтов для программирования: O01Il|
Спецификация определяет практически все тонкости с очень большой точностью. А значит — изучив эти тонкости один раз — вы сможете работать с ними везде.

Эх, если бы так просто было — «один раз», «одну спецификацию» и навсегда для всех проектов — не получится! :-)
В Java есть куча спецификаций, которые в совокупности определяют «хитрости» гораздо более высокого порядка.
Надо помнить, что Java это не только язык.

Попробую показать это на задачке из жизни:
Надо «на лету» создать класс с конструктором, который в своем теле на основании значения параметра вызывает конкретный конструктор суперкласса.
На языке Java конструктор такого класса выглядел бы как-нибудь вот так:

    public A(int ctorNo, Object param) {
        switch(ctorNo) {
            case 1:
                super(param);
            default:
                super();
        }
    }



Если только изучить The Java® Language Specification, то правильный ответ будет:
Это невозможно! — call to super must be first statement in constructor.

Но, The Java® Virtual Machine Specification (Second Edition) позволяет такое!
То есть задача решается в среде Java, если не использовать язык Java :-)

Да, задачи очень разные бывают. Эта задача была весьма специфическая. И для этой задачи хитрое до ненормальности решение (но не противоречащее нужным спецификациям!) было наиболее оптимальным.

Но, это факт, что большинство задач являются типовыми. И правильно для их решения использовать хорошо известные и проверенные шаблонные решения. Это так же относится и к стилю написания исходного кода. Если писать код следуя принятому «шаблонному» стилю, то его поддержка будет стоить намного дешевле.

IMHO большинство языковых «хитростей», которые содержит этот пост, я бы просто отнес к плохому стилю написания исходного кода. Изучать Java надо на положительных примерах и «набивать руку» согласно Code Conventions for the Java Programming Language.

число записано в шестнадцатеричной форме. Но ведь она допускает только A,B,C,D,E в качестве букв — кажете вы. Откуда тогда P и F?

Сижу вчитываюсь… С каких пор «F» — не часть 16тиричного числа? Я что-то не так понял?
А как, кстати, записать DE * 22F? Если нужен тип float?
Интересно конечно, только это к программированию не имеет никакого отношения, как собственно и к знанию JAVA.
Приведу пример, сделанный на базе одного известного реального проекта:
class Base {
  public static Base[] CHILDREN = { Child.NAME };
}

class Child extends Base {
  public static String NAME = "child";
}


Что выведет такой вариант?
System.out.println(Base.CHILDREN[0]);
System.out.println(Child.NAME);


А такой?
System.out.println(Child.NAME);
System.out.println(Base.CHILDREN[0]);


результат
Первый:
child
child


Второй:
child
null


Всё дело в порядке инициализации. В JLS есть следующая строчка:
Before a class is initialized, its direct superclass must be initialized, but interfaces implemented by the class are not initialized.
Если первым обращаются к Base.CHILDREN, то это требует загрузки, верификации, подготовки и инициализации Base, в процессе которой происходит обращение к Child.NAME (при выполнении статического инициализации поля CHILDREN).

Это приводит к загрузке, верификации, подготовке (при которой создаются static-поля и в них записываются значения по умолчанию) и инициализации класса Child.

Инициализация класса Child требует инициализации суперкласса (Base). Разрешение таких циклических зависимостей описано в JLS. Не касаясь синхронизации (для случая инициализации классов из разных потоков), произойдет следующее: JVM проверит состояние инициализации класса Base и, узнав что он инициализируется этим же потоком, продолжит процедуру инициализации класса Child. Это приведет к тому, что в static-поле NAME будет записана ссылка на соответствующую строку "child".

После этого инициализация класса Base продолжится и в массив CHILDREN будет записано значение инициализированного поля Child.NAME.

Напротив, при обратном порядке инициализации (сначала Child, потом Base), произойдет следующее: после загрузки, верификации и подготовки класса Child его статической поле NAME будет создано и заполнено значением по умолчанию (для ссылочных полей — null). После чего JVM начнет инициализацию суперкласса Base.

При инициализации суперкласса Base (загрузка, верификация и подготовка аналогичны) произойдет обращение к static-полю Child.NAME, что потребует инициализации Child, при попытке которой JVM выяснит, что класс находится в процессе инициализации этим же потоком и прекратит попытку. Из поля NAME будет считано текущее значение null.

Избежать этого можно проставив static-полю NAME модификатор final, тогда оно инициализируется раньше, чем будет предпринята попытка инициализировать суперкласс. Подробна эта процедура рассмотрена в 12 главе JLS. Правда, этот метод сработает только, если поле NAME инициализируется compile-time константой.

Вот такие пироги с котятами.

Кому интересно — issues.apache.org/jira/browse/SOLR-5526.
Хороший пример. Порядок инициализации классов нужно знать.
Пожалуй добавлю Вам в копилку примеров «неправильного» кода на Java…
> никогда не используйте
> никогда так не делайте в реальных проектах несвязанных с Brainfuck

7) Скомпилируется ли данный код и если да — то каким будет вывод?

Файл Pure.java:
\u0070u\u0062lic\u0020\u0063la\u0073\u0073
Pure \u007B\u0070ubl\u0069c\u0020st\u0061tic
void \u006Da\u0069n(\u0053tr\u0069ng[]\u0020
\u0061rgs)\u007B\u0053ys\u0074e\u006D. out.
\u0070\u0072int\u006Cn(\u0022H\u0061p\160y new \u0022+
// Мне нравится Java за её жёсткую стандартизованность.
\u0022ye\141r with Java!\r\u0022\u0029;\u007D\u007D


Ответ: Да
Пояснение: Исходный код файла Pure.java является 100% чистой Java.

Если Ваша IDE не выдерживает такого издевательства, то сделайте это без IDE:
1. Создайте файл Pure.java и скопируйте в него код.

2. Запустите команду компиляции исходного кода
javac Pure.java

3. Запустите программу в виртуальной машине Java с помощью команды:
java Pure
Человекочитаемо. Это вам не однострочник.
Разумеется! Мы же не для компьютеров пишем :-)
Весьма интересно, но всё-таки как задача для решения в уме — не пойдёт.

Но как демонстрация некоторых особенностей компилятора — вполне сойдёт.
У всех разные способности. Если помнить латинский алфавит и знать, что 0x41 это заглавная «A» и 0x61 это прописная «a», то легко можно составить таблицу кодов букв. Это значит что все ключевые слова и имена могут быть дешифрованы без всяких инструментов. Небольшое знание синтаксиса языка позволит восстановить всякие скобочки и кавычки, даже если их коды не в памяти. Конечно, это бесчеловечно мучить коллегу такими упражнениями. Но, услышать подобное описанному выше это вполне реально от многих даже без доступа к компьютеру (я надеюсь).

Правильнее сказать некоторых особенностей языка Java, а не компилятора. Так как это определено в JLS и все правильные реализации компиляторов обязаны воплощать эти особенности. Но, каждый компилятор может быть со своими тараканами, которые естественно желательно, чтобы по породе приближались бы к жукам эталонной реализации компилятора javac из JDK.
Хмм, довольно интересно. Узнал кое-что новое для себя. Спасибо.
Что-то я не зная java на все вопросы ответил. Идти получать сертификат? :)
Минимум это запомнить, как делать не следует без осознанной необходимости.
По поводу русских букв. Как-то в проекте поставил в классе переменную «с» по-русски. Где-то час убил, чтобы понять, в чём ошибка и проект в другой части кода ругается на как бы ту же самую переменную c, которая уже на английском. Добавьте в топик к русским буквам в качестве примера.
Знаете, вот вопросы насчет каких тонкостей языка я понимаю, но вопросы с опечатками, аля как с 201l — убивать готов. Это бред, а не тонкий вопрос, вопрос на остроту зрения. Я не первый раз встречаю этот вопрос, но каждый раз когда его встречаю, негодую и не понимаю зачем его несут в массы. В IDE это проблема решается подсветкой синтаксиса, но вы поймите, что есть впечатлительные люди, которые возьмут этот вопрос на собеседование и напечают на бумаге без подсветки и еще специально шрифт подберут, чтобы ну прям совсем… Вот если бы я оказался на собеседовании с таким вопрос, я бы от досады, что у меня спрашивают вопросы не столько по делу, сколько картинки «найди 10 отличий», начал бы ругаться, причем сильно.
Эти вопросы составлены не для проверки уровня знаний, а для предостережения от ошибок. Например, мораль вопроса про 201l такова, что всегда надо использовать заглавную L, иначе могут быть такие вот проблемы.

Если нужно, я могу добавить в начале статьи предупреждение о том, что запрещаю использовать эти вопросы на собеседованиях.
А скинте, пожалуйста, схему подсветки все-таки… На первый взгляд кажется удобной =)
drive.google.com/file/d/0BwTdIuGuk1gxYUVTcy0yc1lkc2c/edit?usp=sharing
Мне кажется, людей, которые убивают читаемость код посредством использования подобных финтифлюшек, нужно превентивно сжигать огнём.

Бывает так, что раскладываешь всё на примитивные части, убираешь даже такие базовые вещи как тернарные операции и всё равно, код не очень хорошо воспринимается другим человеком (с которым нужно работать)…

Тем не менее, достоинства материала это не умаляет. Спасибо автору, провёл 5 минут с интересом и удовольствием.
Вот ведь интересное явление — статью на данный момент добавило в закладки 430 человек (!!!), и с каждым днём добавляет всё больше. Я пролистал 5 страниц хаба Java, и все статьи, которые были там — по количеству добавлений в закладки ниже этой статьи. Неужели статья получилась действительно удачной?
Не знал только про объявление методов в виде short() [] {… }
Это во всех версиях Java работает? :-)

А про русские буквы в идентификаторах — обычно ошибаются только в букве «c», т.к. на клавиатуре для обоих языков одна и та же клавиша. На остальные можно нарваться, IMHO, только в результате обфускации кода.
Должна во всех. Но эта форма хороша для переменных, а для методов лучше использовать другую
short[] func() {…}
Все, кроме 3, ответил корректно.
Уже потом про P в HEX-формате вспомнил )
Молодцы) Мало кто настолько хорошо знает язык
Sign up to leave a comment.

Articles