Комментарии 17
еще интересно зависит ли результат от Java -компилятора (от IDE)
Если имеется в виду «результат» как ответ на вопрос, например, «скомпилируется ли данный код», то, вообще говоря, да: это зависит от компилятора, потому что всякий компилятор привязан к конкретной версии Java, вот почему код с новейшими фичами попросту не скомпилируется на древних версиях.
Но отметим, что наши сертификационные экзамены совершенно строго «заточены» под 11-ю версию (причем об этом, конечно же, объявлено открыто), поэтому вопросы категорически не будут содержать что-то чересчур новое.
Что касается IDE, то они никак не влияют на результат (за исключением экзотических ситуаций, но такие ситуации на экзамене гарантированно не встретятся).
Опечатка в статье про пул интов:
"от -128 до 1270 " - тут лишний ноль
А в целом статья очень полезная, спасибо.
String five = "5";
Boolean boo = Boolean.valueOf(five); // строка X
На экзамене предполагается, что человек помнит все особенности реализации методов и их поведений на память?
Причём, это довольно странное поведение. Это что-то на уровне PHP/JS, которые когда парсят целое число, отбрасывают символы отличные от чисел в конце строки. Скорее всего, это следствие обратной совместимости, также как и, например, метод boolean Boolean::getBoolean(Strng name). getBoolean считывает значение из системных свойств и парсит его, хотя казалось бы, почему обёртка примитивного типа должна этим заниматься?
И да, и нет. Как всегда в жизни, увы-увы :((
В Java 4000+ классов, в каждом по доброму десятку методов, поэтому никто не требует полного знания.
Но рассматриваемый случай особенный: речь идет про т.н. «классы-оболочки», которые крайне популярны и полезны. Вот их надо бы знать на память, причем и тут объем совсем не такой большой. В частности, в каждом из них есть по 3 метода, которые и называются примерно одинаково, и работу выполняют похожую. Метод из примера, т.е.valueOf() по принятой конвенции ВСЕГДА принимает подстилающий примитив, а вовсе не строковый литерал, как в задаче. Для работы со строковыми литералами есть другой метод, parseXXX(), где XXX может означать Int, Boolean и проч. А можно еще взять конструктор, который умеет работать и так, и эдак… Одним словом, есть единый подход, эдакая конвенция, знание которой стократно облегчает жизнь кодера и позволяет ему делать меньше ошибок.
Так что в данном конкретном случае… Да, тут конвенцию надо знать наизусть, ничего не попишешь. Вообще говоря, Java-кодер средней руки должен неплохо знать специфику нескольких сотен классов и, соответственно, их методов. C’est la vie…
Захотелось пройти этот квест, может быть есть где-то онлайн с аввтоматической выпиской сертификата?
К сожалению, пока сертификация доступна только в офлайн-формате. Но мы обязательно донесем до коллег интерес и к онлайн-формату.
А как это в офлайн-формате происходит?
Вот здесь довольно подробно расписан весь процесс: https://ibs-training.ru/certification/java/rules/
Вообще говоря, Java-кодер средней руки должен неплохо знать специфику нескольких сотен классов и, соответственно, их методов.
Почему то к этому очень хочется добавить:
"И не задавать лишних вопросов синьорам-архитекторам, потому что он должен в первую очередь помнить что он всего лишь кодер средней руки"
А еще:
Да, тут конвенцию надо знать наизусть, ничего не попишешь
Интересно что у вас за бизнес модель: вы продаете знания наизусть кодеров средней руки?
Некоторые кодеры с помощью практических методов проверки кодовых конструкций для конкретного (но в принципе любого) компилятора способны без всякого знания наизусть решать (кодить) любые задачи которые имеют решения, и доказать невозможность решения для тех задач для которых решения не существует, например, по причине неправильной постановки задачи.
Получается вы отбираете тех кто способен зазубрить наизусть, а не тех кто способен решать задачи. Одно другого конечно не исключает, но все таки выглядит как сомнительный подход.
С нашей бизнес-моделью все в порядке, мы всего лишь следуем устоявшейся, канонической практике. Точно такой же подход принят и у Oracle: в частности, сигнатуры популярных методов надо знать. Как и всякую материальную часть своей предметной области. Тем более в классах из пакета java.lang.
java.lang является предметной областью для тех кто пишет компилятор java, вроде как Oracle как раз имеет свой java-компилятор. Вы же не пишете свой java компилятор?
Для тех кто пишет работу с базами данных (например) предметной областью является база данных, а язык на котором пишутся эти базы данных является одним из возможных инструментов.
И Понятно что с бизнес моделью все хорошо, тот кто придумал что другие должны знать наизусть, может грести деньги лопатой за проверки этого наизусть!
Поведение Boolean.valueOf() это не особенность реализации, а задокументированное в JavaDoc поведение:
Returns a Boolean with a value represented by the specified string. The Boolean returned represents a true value if the string argument is not null and is equal, ignoring case, to the string «true». Otherwise, a false value is returned, including for a null argument.
Читать JavaDoc используемых классов и методов крайне полезно. Иначе могут быть неприятные сюрпризы.
Предлагается не читать, а знать наизусть.
Вероятно, это экзамен, подготовка к которому описана в книгах OCP study guide. Там есть примеры вопросов. Часто предлагается поработать компилятором. В нормальной ситуации IDE и JavaDoc часть вопросов делает бесполезными. Но есть интересные вопросы на понимание.
Предположим, нам дали два целых числа, но не примитивы, а Integer-объекты…