Посты канала Java Interview Review

clone

По умолчанию protected – потому что универсальной реализации нет, а вызов приведет к CloneNotSupportedException. Нужно писать свою реализацию, делать при этом ее public и добавлять классу интерфейс Cloneable. Подразумевается что этот метод делает «глубокое копирование», то есть поля-ссылки копи будут вести на копии полей оригинала. Это диктуется соглашением, по которому объект-клон не должен зависеть от оригинала.

По контракту клон должен быть другим объектом (!= оригиналу). Рекомендуется, чтобы все классы иерархии реализовывали Cloneable, реализация метода начиналась с super.clone() (если родитель не Object), а результат был equals и имел тот же класс что и оригинал.

Альтернативы (многие считают что более удобные) метода clone - конструктор копирования и паттерн factory method. Всё, что нужно знать о копировании объектов в Java можно найти в Effective Java Item 11.

#МетодыObject

equals, hashCode

Эти два метода придуманы для использования в Java Collections Framework и связаны общим контрактом, для соблюдения которого переопределять их необходимо вместе. Методы обязательно нужно переопределить чтобы эффективно использовать экземпляры как ключи в HashMap или HashSet. HashMap работает тем эффективнее, чем «лучше» распределение хэшей.

Контракт:
1. Если объекты equals, у них должны быть одинаковые hashCode (не обязательно наоборот – коллизии допустимы!)
2. equals должен быть отношением эквивалентности
3. Ничто не может быть equals(null)
4. equals и hashCode должны возвращать одни и те же значения для одного и того же объекта при каждом последующем вызове, даже если состояние объекта изменилось. Это делает реализацию для изменяемых (mutable) объектов крайне сложной.

По умолчанию equals сравнивает на ==. С умолчательным hashCode дела обстоят интереснее: он зависит от реализации JVM, и может быть неожиданным. Например в OpenJDK 7 это случайное число.

Подробная инструкция по переопределению этих методов описана в Effective Java Item 9 (больше деталей о волшебном числе 31 здесь).

#МетодыObject

getClass

Возвращает класс этого экземпляра. То есть результатом вызова .getClass() переменной типа Foo может быть как Foo.class, так и .class любого из его подклассов. Компилятор страхуется от ClassCastException в рантайме подменой возвращаемого типа метода на Class<? extends Foo>.

Подробнее об этом читайте на хабре.

#МетодыObject

Перечислите методы класса java.lang.Object

Этот вопрос используется, как способ начать разговор – по большинству методов можно уйти в обсуждении далеко вглубь. В первую очередь важно запомнить сигнатуры – не зная ответов на вопросы по этим методам, можно будет хотя бы рассуждать отталкиваясь от них. Также полезно открыть исходник и внимательно прочитать javadoc-документацию. Поступим как на интервью, и далее рассмотрим каждый из методов детально. Их список:

1. public final native Class<?> getClass()
2. public native int hashCode()
3. public boolean equals(Object obj)
4. protected native Object clone() throws CloneNotSupportedException
5. public String toString()
6. public final native void notify()
7. public final native void notifyAll()
8. public final native void wait(long timeout) throws InterruptedException
9. public final void wait(long timeout, int nanos) throws InterruptedException
10. public final void wait() throws InterruptedException
11. protected void finalize() throws Throwable

#МетодыObject

Что такое Java-модули?

Java Platform Module System (JPMS) – система модулей, появившаяся в Java версии 9. Она разрабатывалась под названием Project Jigsaw, и ожидалась еще с Java 7.

Модуль – группа связанных пакетов и ресурсов. Механизм модулей определяет видимость содержимого одних модулей для других. Скрытые модули недоступны ни для обычного использования в коде, ни даже для рефлекшна: Class.forName() выбросит ClassNotFoundException.

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

Модуль определяется файлом объявления module-info.java. Поговорим о его содержимом и о применении модулей вообще в будущих постах постах.

JVM может работать относительно модулей в трех режимах:

• Legacy mode – применяется, когда код компилируется в режиме совместимости с версиями Java 8 и меньше. Весь код работает как безымянный модуль, флаги для настройки модулярности не работают.

• Single module mode – когда не используется флаг --module-source-path. Структура проекта остается старой, файл module-info.java лежит в директории /src. Поэтому иметь несколько модулей в одном проекте не получится.

• Multi-module mode – каждый модуль находится в собственной директории. Общая корневая директория передается в --module-source-path. Полноценное использование JPMS.

#Модули

Как сделать код с арифметикой кроссплатформенным?

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

Во-первых, разберемся насколько сильно результатам позволено расходиться. В документации разных методов из Math эта величина выражается в единицах ulp (unit in the last place). Это то, насколько увеличится число, если его битовое выражение увеличить на 1 бит. Для разных чисел значение ulp будет различаться. Получить его можно методом Math.ulp(x).

Если объявленной точности не хватает, на помощь придет класс StrictMath. В нём находится примерно такой же набор инструментов как в Math, но с повторяемыми результатами, которые можно получить стандартизованными алгоритмами на C.

Для обычных языковых выражений вроде инициализаторов и операторов введено понятие свойства FP-strict. Выражения с этим свойством будут кроссплатформенным. Чтобы добавить свойство всем операторам, на методе используется модификатор strictfp (о котором мы уже упоминали).

#Язык

​Как работает инъекция прототипа в синглтон?

Раньше мы уже рассматривали различия скоупов singleton и prototype в Spring Framework. Допустим ситуацию, когда в singleton-компонент внедряется зависимость со скоупом prototype – когда будет создан её объект?

Если просто добавить к определению бина аннотацию @Scope(SCOPE_PROTOTYPE), и использовать этот бин в синглтоне через аннотацию @Autowired – будет создан только один объект. Потому что синглтон создается только однажды, и обращение к прототипу случится тоже однажды при его создании (при внедрении зависимости).

Примитивный способ получать новый объект при каждом обращении – отказаться от @Autowired, и доставать его из контекста вручную. Для этого нужно вызывать context.getBean(MyPrototype.class).

Воспользоваться автоматическим внедрением зависимостей можно через внедрение метода (паттерн «Команда»). Автовайрится не сам объект, а производящий его метод.

Более красивый декларативный способ – правильно настроить определение бина. В аннотации @Scope кроме самого scopeName доступен второй параметр – proxyMode. По умолчанию его значение NO – прокси не создается. Но если указать INTERFACES или TARGET_CLASS, то под @Autowired будет внедряться не сам объект, а сгенерированный фреймворком прокси. И когда проксируемый бин имеет скоуп prototype, то объект внутри прокси будет пересоздаваться при каждом обращении.

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

#Spring

Под каким типом хранить период времени?

В стандартной библиотеке современных версий Java для этих целей есть два класса:

Period – календарный период. Количество дней, месяцев и лет. Одним днем здесь считается день в терминах ZonedDateTime.

Duration – длительность времени. Количество наносекунд, секунд, минут, часов, и тоже дней. Здесь один день – ровно 24 часа.

Оба класса реализуют общий интерфейс TemporalAmount – период времени вообще. Оба иммутабельны, и как следствие, потокобезопасны. Любая модифицирующая операция вроде plusX() возвращает новый экземпляр с измененным значением.

Экземпляры обоих классов могут быть созданы из значений отдельных компонентов, из двух моментов времени методом between, или из строки. Строковое представление Duration: "P2DT3H4M", Period: "P1Y2M3D".

До Java 8 основным способом хранения периода были числовые примитивы. В этом подходе есть много недостатков, среди которых в первую очередь неограниченность значений и ненаглядность. Чтобы в Java 8+ получить период числом, используется метод between() нужного элемента енама ChronoUnit.

#Классы

Опишите синтаксис javadoc-комментария (2/2)

Комментарий состоит из двух частей: описание и блок тегов. Первый блок содержит всю информацию в свободной форме. Во втором находятся теги (ранее уже упоминали их). Каждый тег начинается с новой строки, через пробел за ним следует значение.

Один тег можно использовать в блоке описания – @link. Он не обязан быть на новой строке, обрамляется фигурными скобками, и при рендеринге превращается в <a> со ссылкой на другую страницу документации.

Среди всех тегов обязательными считаются только @param для каждого параметра метода, и @return для не-void методов. Они применимы только для методов. А теги @author и @version наоборот, используются только в документации классов. Остальные блочные теги можно использовать везде:

• @deprecated
• @exception (то же что @throws)
• @see
• @since
• @serial (то же что @serialField или @serialData)

Теги @author, @param, @throws и @see могут входить в один комментарий в нескольких экземплярах.

#Инструменты

Опишите синтаксис javadoc-комментария (1/2)

Javadoc-комментарии к классам и их членам заключаются между /** и */. С точки зрения синтаксиса Java это обычные многострочные комментарии, но вторая * позволяет различным инструментам воспринимать их как документацию API. Изначально для этого использовалась стандартная утилита javadoc, которая генерировала HTML-документацию, сейчас джавадок активно используется прямо в IDE.

До Java 1.4 каждая строка комментария обязана была начинаться со *. Сейчас это требование необязательное, но следовать ему всё ещё принято.

Первое предложение комментария принимается в качестве заголовка описания элемента. В HTML именно оно попадает на страницу индекса. Предложение заканчивается точкой с последующим разделительным символом.

В javadoc разрешено использовать HTML-теги. Фрагменты кода рекомендуется обрамлять тегом <code>, для списка с буллетами применяется <ul>, параграфы отделяются <p>. В документации библиотеки Reactor активно используются <img> с диаграммами.

#Инструменты