kciray 29 дек 2013 в 19:08

Хитрые задачи по Java

7 мин

117K

Oracle * Программирование * Java *

+45

Комментарии 81

isden 29 дек 2013 в 19:16

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

Извините, может быть я чего не понимаю, но в чем тогда смысл таких задач? Проверить знание всевозможных извратов, возможных в языке?

auvn 29 дек 2013 в 19:24

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

foxin 29 дек 2013 в 19:32

Чтобы знать все тонкости языка/компилятора и понимать, почему та или иная вещь сделана именно так.

Лично я с удовольствием перетяну в свой c++ код правило обозначать тип большого целого числа только большой буквой L. Хотя, казалось бы, каким боком c++ к java.

Mnemonik 29 дек 2013 в 20:52

Я готовлюсь сейчас к этому экзамену и меня это тоже просто вымораживает. Несмотря на то что я могу программировать на яве вполне нормально, я не могу выбить больше 60% из тестовых заданий ну никак — потому что 50% задач которые приходится решать первым делом вызывают вопрос «какой идиот это писал?». И все чем я занимаюсь готовясь — учу в основном фокусы и тонкости которые никто никогда не будет использовать, и ловко отличать фишку которая скомпилируется явой от той которая не скомпилируется явой. Плюс составители обожают писать код для заданий наплевав на все правила программирования, например назвав вперемешку классы, интерфейсы и методы A/B/C и D и слепив из них жуткое месиво наследований, имплементаций и выводов и задва гениальный вопрос «что выведет данный код?» не забыв добавить вариант ответа «не скомпилируется».
Короче это жуткий экзамен на фантастическую въедливость во все тонкости языка и внимательность.

Sauron 30 дек 2013 в 16:27

Смысл в том чтоб кто-то заплатил Ораклу за сертификацию, и даже если этот кто-то серьезно программирует ему должно быть трудно пройти тест, чтоб не было ощущения дешевки.

zipo 5 янв 2014 в 14:01

Мне в свое время было просто интерестно оценить уровень своих знания на всевозможных тестах. Поробовал симуляции тестов на exambraindumps.com/ просто ради удовольствия. Когда делать нечего, то мозги очень хорошо разминаются. Как бонус можно оценить сможешь ли здать реальный сертификационный экзамен.

kciray 29 дек 2013 в 19:28

Некоторые вопросы предостерегают вас от ошибок, о которых я написал в пояснениях. И вообще в исходниках чужих всякое встречается. ИМХО — надо глубоко знать язык, особенно если у него есть жёсткая спецификация.

НЛО прилетело и опубликовало эту надпись здесь

Artem_zin 29 дек 2013 в 20:20

Разделяю ваше мнение по поводу сертификации. Они полезны только в тех компаниях, куда нормальные разработчики ни за какие деньги не сунутся, имхо :)

Есть у нас в универе один препод с over9000 сертификатами от Microsoft и т.д., но стоит его спросить о чем то реальном, так он так плавать начинает, что аж самому неловко становится от того что спросил это :)

kciray 29 дек 2013 в 20:23

У меня достаточно знакомых, которые работают на хороших должностях в крупных компаниях и они все утверждают, что сертификаты дают значительный бонус при устройстве на работу. Хотя да, есть процент работодателей, которых не волнуют сертификаты, но он не велик. Возможно, вам просто не повезло =)

Newbilius 30 дек 2013 в 04:10

Всё почти как с институтским дипломом блин.

fogone 30 дек 2013 в 08:28

Не подскажете, что за «значительный бонус» такой мифический?

kciray 30 дек 2013 в 09:21

Например, в случае двух людей на одно место скорее берут того человека, у которого есть сертификат. Кроме того, в некоторых компаниях на более высокие должности берут только при получении соответствующего сертификата — и повышают зарплату также. Речь идёт о крупных компаниях.

«Без бумажки ты букашка, а с бумажкой — человек!» (с) советский поэт

fogone 30 дек 2013 в 10:06

Это какой-то очень синтетический случай. Если на собеседование пришел человек, которого ты готов взять на работу (независимо от того что за сертификаты у него, есть ли во, служил, сидел и тд) это уже повод плясать джигу, но чтобы сразу двое — ну, так просто не бывает.

kciray 30 дек 2013 в 10:21

Смотря в каких компаниях

cheremin 30 дек 2013 в 15:13

Я вот, кстати, такого же мнения — нормальных специалистов днем с огнем не сыщешь, когда такой появляется — это праздник просто. И все это знают — и наниматели, и сами специалисты. И зачем этому специалисту тратить время и силы и деньги на прохождение сертификации, которая к его опыту ничего не добавит, и на которую никто все равно не смотрит? Вот и получается ситуация, что человек с сертификатами уже скорее подозрение вызывает :)

ilinchik 30 дек 2013 в 08:32

Сертификаты волнуют работодателей из-за проведения тендеров (нужно N-сертифицированных специалистов). Да это нравится HR-ам, но сомневаюсь что сертификаты произведут впечатление на людей которые проводят техническое интервью.

cheremin 30 дек 2013 в 15:10

Удивлен этим — за 11 лет карьеры не помню ни одного раза, чтобы сертификат по яве зачитывался хоть сколь-либо существенно сам по себе. Может, озвучите названия крупных компаний? Любопытно просто, что это за компания, которая, скажем, разработчику с опытом даст/не даст бонус только на основании сертификата.

kciray 30 дек 2013 в 15:29

Oracle

cheremin 30 дек 2013 в 18:38

Странно, мне там про это не упоминали. Ну да ладно, главное, чтобы все были счастливы :)

kciray 31 дек 2013 в 18:23

Вот я теперь не знаю, кому верить =)

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

Walrus 31 дек 2013 в 11:37

ой, так ли? ;)

Artem_zin 29 дек 2013 в 20:14

Великолепная описка в итогах:

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

Хехе :)

А на самом деле, я даже рад, что не во всех вопросах правильно ответил

kciray 29 дек 2013 в 20:19

Исправил

Ryotsuke 30 дек 2013 в 05:26

Ну если все тонкости спецификации всегда помнить, то и JavaScript недоумения не вызывает. Это можно про любой язык сказать.

garbuz 29 дек 2013 в 20:16

Опять это дрочерство. Лучше JavaEE учите, полезнее будет.

Nostromo 29 дек 2013 в 20:32

Да, должен же кто то джава бины клепать для говноформочек к базам данных.

cproject 30 дек 2013 в 11:39

можно подумать на JavaEE только джава бины к говнофомочкам делают… вы, судя по всему, совсем не знаете JavaEE

Nostromo 30 дек 2013 в 18:47

orly?
я работал в дойче банке и других компаниях такого уровня и прекрасно представляю себе, какие проекты делаются на java SE и какие на java EE. EE используется для нетребовательных проектов как раз уровня говноформочек к БД, потому что это промышленный подход, не требующий особого знания кишок машины, системы и окружающей среды. И вот те самые клепатели этих CRM и прочего считают себя реальными хардкор прогерами и удивляются, зачем же надо знать про кишки JVM и особенности компиляции. Вам не надо, расслабьтесь.

ashofthedream 30 дек 2013 в 19:06

Ну так зачем знать чо там как в JVM, если тебе что-то нужно, а для этого не существует аннотации — значит этого не существует в принципе.

NektoDev 12 янв 2014 в 22:08

Надеюсь сарказм?

ashofthedream 13 янв 2014 в 11:34

Судя по некоторым, их тех, кого приходилось собеседовать или с кем пришлось поработать, сарказма тут маловато.

cproject 17 янв 2014 в 11:27

Это вам просто так везло. Мне приходилось делать красивые и удобные биллинговые системы под веб и заниматься оптимизацией крупных кластерных приложений. Всё на Java. Поэтому я не согласен с вашим обобщением. Хотя это может просто мне так повезло с работой.
Не хочу теперь в дойче банк :)

SeptiM 29 дек 2013 в 22:32

По поводу букв. F допускается в шестнадцатеричной форме: это 15.

kciray 30 дек 2013 в 09:23

Исправил

rimmer 29 дек 2013 в 22:45

Интересно, сколько пользователей, решивших этот тест, ответит больше чем на половину?

Я неправильно ответил только на 3-й вопрос. Меня сбило с толку нижнее подчеркивание. Хотя, если бы меня попросили пояснить, то я бы пояснил не все. То есть, местами угадал просто. Спасибо, узнал кое-что новое.

НЛО прилетело и опубликовало эту надпись здесь

man_without_face 30 дек 2013 в 00:25

а если убавить шрифт? :)

Mercury13 30 дек 2013 в 01:02

Наоборот, прибавлять нужно — тогда появится различие. Разумеется, на исходном тексте, а не на пиксельной картинке.
Хотя убавить тоже можно, разница будет в нижней засечке.

lanseg 30 дек 2013 в 02:53

Для того и пишут заглавную l. Вроде бы, нетбинс и идея на такое даже ругаются.

DrMetallius 30 дек 2013 в 03:15

Я не очень понял насчёт заглавной L (пока что не прорешал задачи, надо сделать это обстоятельно, а не наспех), но если имеется в виду Long вместо long, то это совершенно не одно и то же, и так без нужды делать не стоит. Первое — объект, а второе — примитивный тип. В вычислениях объект придётся превращать в примитивный тип, и это вызовет ненужные проблемы с эффективностью кода. А если результат нужно будет записать обратно в переменную, то ещё и создастся новый объект в процессе автоупаковки.

victorv 30 дек 2013 в 03:31

Речь об L в константе: 201L

BTW Следуя привычкам я бы определил константу в теле класса, убив интригу и неоднозначность восприятия:

public static final long YEAR_201 = 201L;

DrMetallius 30 дек 2013 в 08:39

Значит, я даже с масштабом не там единичку разглядел. Ещё удивился насчёт типов.

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

kciray 30 дек 2013 в 08:13

Не зависимо от того, находится буква L в нижнем регистре или верхнем, в конце целочисленного литерала она всегда означает примитивный тип long.

Для случая Long year = 201L; автоупаковка будет также произведена.

DrMetallius 30 дек 2013 в 09:04

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

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

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

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

DrMetallius 30 дек 2013 в 09:09

Пардон, хотел написать «а в конце литерала всё как надо», не успел отредактировать.

zagayevskiy 30 дек 2013 в 04:41

хром на маке

eclipse

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

ЧЯДНТ?

Veliant 30 дек 2013 в 05:05

Перечень моноширинных шрифтов не заканчиваются на monaco и droid mono. И я бы сказал что шрифты и должны быть такими, в которых нельзя спутать 0/O, 1/l

grossws 30 дек 2013 в 05:06

Именно поэтому я предпочитаю anonymous pro на linux. Без нормального шрифта можно выстрелить в ногу. Особенно в языках с динамической типизацией.

НЛО прилетело и опубликовало эту надпись здесь

ilammy 31 дек 2013 в 18:50

И я бы сказал что шрифты и должны быть такими, в которых нельзя спутать 0/O, 1/l

Угу, стандартная настроечная таблица шрифтов для программирования: O01Il|

victorv 30 дек 2013 в 02:51

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

Эх, если бы так просто было — «один раз», «одну спецификацию» и навсегда для всех проектов — не получится! :-)
В 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.

paveldudka 30 дек 2013 в 04:30

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

Сижу вчитываюсь… С каких пор «F» — не часть 16тиричного числа? Я что-то не так понял?

kciray 30 дек 2013 в 04:37

Опечаточка, исправил

sophist 30 дек 2013 в 17:22

А как, кстати, записать DE * 2^2F? Если нужен тип float?

Divers 30 дек 2013 в 05:59

Интересно конечно, только это к программированию не имеет никакого отношения, как собственно и к знанию JAVA.

grossws 30 дек 2013 в 06:12

Приведу пример, сделанный на базе одного известного реального проекта:

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.

kciray 30 дек 2013 в 09:30

Хороший пример. Порядок инициализации классов нужно знать.

victorv 30 дек 2013 в 06:38

Пожалуй добавлю Вам в копилку примеров «неправильного» кода на 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

grossws 30 дек 2013 в 06:49

Человекочитаемо. Это вам не однострочник.

victorv 30 дек 2013 в 06:52

Разумеется! Мы же не для компьютеров пишем :-)

kciray 30 дек 2013 в 09:33

Весьма интересно, но всё-таки как задача для решения в уме — не пойдёт.

Но как демонстрация некоторых особенностей компилятора — вполне сойдёт.

victorv 30 дек 2013 в 10:31

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

Правильнее сказать некоторых особенностей языка Java, а не компилятора. Так как это определено в JLS и все правильные реализации компиляторов обязаны воплощать эти особенности. Но, каждый компилятор может быть со своими тараканами, которые естественно желательно, чтобы по породе приближались бы к жукам эталонной реализации компилятора javac из JDK.

kciray 30 дек 2013 в 10:46

Хмм, довольно интересно. Узнал кое-что новое для себя. Спасибо.

victorv 30 дек 2013 в 06:38

дубликат почему-то :-(

rafuck 30 дек 2013 в 08:22

Что-то я не зная java на все вопросы ответил. Идти получать сертификат? :)

victorv 30 дек 2013 в 10:36

Минимум это запомнить, как делать не следует без осознанной необходимости.

Yurevich1 30 дек 2013 в 08:31

По поводу русских букв. Как-то в проекте поставил в классе переменную «с» по-русски. Где-то час убил, чтобы понять, в чём ошибка и проект в другой части кода ругается на как бы ту же самую переменную c, которая уже на английском. Добавьте в топик к русским буквам в качестве примера.

kciray 30 дек 2013 в 09:38

Добавил, спасибо

sphinks 30 дек 2013 в 08:52

Знаете, вот вопросы насчет каких тонкостей языка я понимаю, но вопросы с опечатками, аля как с 201l — убивать готов. Это бред, а не тонкий вопрос, вопрос на остроту зрения. Я не первый раз встречаю этот вопрос, но каждый раз когда его встречаю, негодую и не понимаю зачем его несут в массы. В IDE это проблема решается подсветкой синтаксиса, но вы поймите, что есть впечатлительные люди, которые возьмут этот вопрос на собеседование и напечают на бумаге без подсветки и еще специально шрифт подберут, чтобы ну прям совсем… Вот если бы я оказался на собеседовании с таким вопрос, я бы от досады, что у меня спрашивают вопросы не столько по делу, сколько картинки «найди 10 отличий», начал бы ругаться, причем сильно.

kciray 30 дек 2013 в 09:45

Эти вопросы составлены не для проверки уровня знаний, а для предостережения от ошибок. Например, мораль вопроса про 201l такова, что всегда надо использовать заглавную L, иначе могут быть такие вот проблемы.

Если нужно, я могу добавить в начале статьи предупреждение о том, что запрещаю использовать эти вопросы на собеседованиях.

TrashMind 30 дек 2013 в 12:37

А скинте, пожалуйста, схему подсветки все-таки… На первый взгляд кажется удобной =)

kciray 30 дек 2013 в 15:30

drive.google.com/file/d/0BwTdIuGuk1gxYUVTcy0yc1lkc2c/edit?usp=sharing

TrashMind 31 дек 2013 в 08:51

спасибо!

farewell 30 дек 2013 в 14:46

Мне кажется, людей, которые убивают читаемость код посредством использования подобных финтифлюшек, нужно превентивно сжигать огнём.

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

Тем не менее, достоинства материала это не умаляет. Спасибо автору, провёл 5 минут с интересом и удовольствием.

kciray 3 янв 2014 в 13:34

Вот ведь интересное явление — статью на данный момент добавило в закладки 430 человек (!!!), и с каждым днём добавляет всё больше. Я пролистал 5 страниц хаба Java, и все статьи, которые были там — по количеству добавлений в закладки ниже этой статьи. Неужели статья получилась действительно удачной?

strangeraven 4 янв 2014 в 11:28

да, статья получилась удачной
спасибо

Colwin 13 янв 2014 в 07:28

Не знал только про объявление методов в виде short() [] {… }
Это во всех версиях Java работает? :-)

А про русские буквы в идентификаторах — обычно ошибаются только в букве «c», т.к. на клавиатуре для обоих языков одна и та же клавиша. На остальные можно нарваться, IMHO, только в результате обфускации кода.

kciray 14 янв 2014 в 19:28

Должна во всех. Но эта форма хороша для переменных, а для методов лучше использовать другую
short[] func() {…}

Colwin 9 мар 2016 в 11:52

Все, кроме 3, ответил корректно.
Уже потом про P в HEX-формате вспомнил )

kciray 9 мар 2016 в 13:23

Молодцы) Мало кто настолько хорошо знает язык

Зарегистрируйтесь на Хабре, чтобы оставить комментарий