В каком порядке указываются модификаторы?
Правила применения модификаторов поля описаны в JLS 8.3.1:
🔘 Нельзя указывать один модификатор дважды;
🔘 Нельзя использовать несколько модификаторов доступа одновременно.
Порядок указания вообще свободный, но обычно используется следующий:
@Аннотации, доступ,
🔘 Те же требования, что и к полю;
🔘 Совместно с abstract кроме аннотаций можно использовать только protected или public;
🔘 native метод не может использовать strictfp.
И так же не требуется, но рекомендуется использовать такой порядок:
@Аннотации, доступ,
Правила применения модификаторов поля описаны в JLS 8.3.1:
🔘 Нельзя указывать один модификатор дважды;
🔘 Нельзя использовать несколько модификаторов доступа одновременно.
Порядок указания вообще свободный, но обычно используется следующий:
@Аннотации, доступ,
static final transient volatileТребования для модификаторов метода находятся в JLS 8.4.3:
🔘 Те же требования, что и к полю;
🔘 Совместно с abstract кроме аннотаций можно использовать только protected или public;
🔘 native метод не может использовать strictfp.
И так же не требуется, но рекомендуется использовать такой порядок:
@Аннотации, доступ,
abstract static final synchronized native strictfp👍20
Что будет в результате компиляции и выполнения данного кода?
Anonymous Quiz
43%
1
34%
2
5%
Ошибка выполнения
18%
Ошибка компиляции
👍22😱5❤2🥱1
Что такое короткое замыкание логического оператора?
Логические операторы || и && лево-ассоциативны, то есть их параметры вычисляются слева направо. Если первое значение оказалось true в || или false в && – конечный результат уже предрешен, он будет тем же. В этом случае происходит так называемое «короткое замыкание» (short-circuiting) – оставшийся второй аргумент не вычисляется за ненадобностью.
Эту особенность иногда удобно эксплуатировать, например для проверки на null в одну строку:
Вдобавок доступен оператор «исключающее или» ^. Он почти никогда не используется для булевых параметров, потому что абсолютно эквивалентен более интуитивно понятному !=. Другие битовые операторы для логических аргументов недоступны.
Логические операторы || и && лево-ассоциативны, то есть их параметры вычисляются слева направо. Если первое значение оказалось true в || или false в && – конечный результат уже предрешен, он будет тем же. В этом случае происходит так называемое «короткое замыкание» (short-circuiting) – оставшийся второй аргумент не вычисляется за ненадобностью.
Эту особенность иногда удобно эксплуатировать, например для проверки на null в одну строку:
return param != null && param.getBoolMember();Но иногда такая ситуация влечет за собой неожиданные плавающие баги, если второй аргумент – не переменная, а функция с побочным эффектом. Для этой ситуации введены версии операторов без короткого замыкания: | и &. Это логические вариации «битового и» и «битового или».
Вдобавок доступен оператор «исключающее или» ^. Он почти никогда не используется для булевых параметров, потому что абсолютно эквивалентен более интуитивно понятному !=. Другие битовые операторы для логических аргументов недоступны.
👍21🔥4❤1
Дайте точную оценку по времени данному алгоритму.
Anonymous Quiz
30%
O(n)
30%
O(100 * n)
7%
O(log(n))
30%
O(n* n)
4%
O(1)
🤨24👍12😱5🤯3⚡1
Как узнать, является ли A подтипом B?
В Java доступны три способа проверки совместимости типов. Функционально они ничем не отличаются, применяются для разных наборов аргументов. В порядке убывания быстродействия:
instanceof – бинарный оператор, самый быстрый и самый используемый. Если есть экземпляр A и можно указать B явно, выбирать надо его. Если A (точнее тип хранящей экземпляр A переменной) и B не из одной цепочки наследования – экземпляр точно не может быть подтипом B и компиляция упадет с ошибкой inconvertible types.
Class::isInstance – метод принимает параметром объект типа A. Его стоит выбрать, когда экземпляр A в наличии, но B – неизвестный на этапе компиляции тип. То есть, для переменных A a и Class bClass, можем проверить bClass.isInstance(a).
Class::isAssignableFrom – принимает Class<A>. Единственное, что остается, если экземпляра A нет. bClass.isAssignableFrom(aClass).
Есть еще четвертый способ – имея экземпляр типа A привести его к B. Если типы были несовместимы, приведение выбросит ClassCastException. Это во всех смыслах плохой способ, построению логики программы на исключениях нет оправдания.
В Java доступны три способа проверки совместимости типов. Функционально они ничем не отличаются, применяются для разных наборов аргументов. В порядке убывания быстродействия:
instanceof – бинарный оператор, самый быстрый и самый используемый. Если есть экземпляр A и можно указать B явно, выбирать надо его. Если A (точнее тип хранящей экземпляр A переменной) и B не из одной цепочки наследования – экземпляр точно не может быть подтипом B и компиляция упадет с ошибкой inconvertible types.
Class::isInstance – метод принимает параметром объект типа A. Его стоит выбрать, когда экземпляр A в наличии, но B – неизвестный на этапе компиляции тип. То есть, для переменных A a и Class bClass, можем проверить bClass.isInstance(a).
Class::isAssignableFrom – принимает Class<A>. Единственное, что остается, если экземпляра A нет. bClass.isAssignableFrom(aClass).
Есть еще четвертый способ – имея экземпляр типа A привести его к B. Если типы были несовместимы, приведение выбросит ClassCastException. Это во всех смыслах плохой способ, построению логики программы на исключениях нет оправдания.
👍29❤2🔥2
Что будет в результате компиляции и выполнения данного кода?
Anonymous Quiz
28%
Вывод в консоль Hello и завершение работы программы StackOferflowError
27%
Вывод в консоль Error
25%
Ошибка компиляции
21%
Вывод в консоль Hello и Error
👍21
Как скопировать массив?
Object.clone() и System.arraycopy(). Нативные способы копирования, самые быстрые из возможных. Унаследованный от базового класса clone() копирует весь массив без лишних аргументов. arraycopy(), наоборот, максимально гибкий – позволяет копировать часть массива и указывать массив, в который копировать.
Arrays.copyOf(), Arrays.copyOfRange() и все их перегрузки. Утилитарные методы, которые дают более специализированные способы копирования. Внутри все используют System.arraycopy().
Копирование через стрим. Arrays.stream(sourceArray).toArray(). Удобно когда нужно встроить дополнительные промежуточные операции.
Сторонними библиотеками. Обычно обеспечивают дополнительные удобства, такие как проверка корректности параметров, приведения типов, и прочие. Пример – класс SerializationUtils из Apache Commons.
Все перечисленные способы создают поверхностную копию – оба массива в итоге ссылаются на одни и те же объекты. Лучший способ создать глубокую копию – реализовать ее вручную. Сначала оператором new создается пустой массив нужного размера, затем в цикле заполняется копиями элементов. Stream API здесь может дать удобный интерфейс реализации, и оптимизировать копирование с помощью многопоточности.
Самый быстрый, но ужасный по эффективности способ глубокого копирования массива без реализации копирования отдельных элементов – сериализация+десериализация. Сложно придумать оправдание такому плохому способу для продакшна, но этот метод вполне подходит для реализации быстрого прототипа, или для тестового кода.
Object.clone() и System.arraycopy(). Нативные способы копирования, самые быстрые из возможных. Унаследованный от базового класса clone() копирует весь массив без лишних аргументов. arraycopy(), наоборот, максимально гибкий – позволяет копировать часть массива и указывать массив, в который копировать.
Arrays.copyOf(), Arrays.copyOfRange() и все их перегрузки. Утилитарные методы, которые дают более специализированные способы копирования. Внутри все используют System.arraycopy().
Копирование через стрим. Arrays.stream(sourceArray).toArray(). Удобно когда нужно встроить дополнительные промежуточные операции.
Сторонними библиотеками. Обычно обеспечивают дополнительные удобства, такие как проверка корректности параметров, приведения типов, и прочие. Пример – класс SerializationUtils из Apache Commons.
Все перечисленные способы создают поверхностную копию – оба массива в итоге ссылаются на одни и те же объекты. Лучший способ создать глубокую копию – реализовать ее вручную. Сначала оператором new создается пустой массив нужного размера, затем в цикле заполняется копиями элементов. Stream API здесь может дать удобный интерфейс реализации, и оптимизировать копирование с помощью многопоточности.
Самый быстрый, но ужасный по эффективности способ глубокого копирования массива без реализации копирования отдельных элементов – сериализация+десериализация. Сложно придумать оправдание такому плохому способу для продакшна, но этот метод вполне подходит для реализации быстрого прототипа, или для тестового кода.
👍15🔥3
Можно ли поймать Error?
Технически, Error как и любой другой Throwable можно поймать в блок catch. Такой код абсолютно валидный и скомпилируется без проблем.
На практике, согласно спецификации, значение исключения типа Error – необрабатываемая ошибка, ловить которую нет смысла.
Более того, выброс исключения подтипа VirtualMachineError означает, что JVM находится в сломанном состоянии. Дальнейшая работа непредсказуема: OutOfMemoryError приводит к невозможности создания новых объектов, StackOverflowError теряет фреймы стека вызова, и так далее.
Так как ловить Error не нужно, объявление её в секции throws сигнатуры метода необязательно. Как и RuntimeException, Error – разновидность unchecked exception.
Технически, Error как и любой другой Throwable можно поймать в блок catch. Такой код абсолютно валидный и скомпилируется без проблем.
На практике, согласно спецификации, значение исключения типа Error – необрабатываемая ошибка, ловить которую нет смысла.
Более того, выброс исключения подтипа VirtualMachineError означает, что JVM находится в сломанном состоянии. Дальнейшая работа непредсказуема: OutOfMemoryError приводит к невозможности создания новых объектов, StackOverflowError теряет фреймы стека вызова, и так далее.
Так как ловить Error не нужно, объявление её в секции throws сигнатуры метода необязательно. Как и RuntimeException, Error – разновидность unchecked exception.
🔥17👍13
Чем отличается Closeable от AutoCloseable?
Интерфейс AutoCloseable представляет объект-хранилище некоего ресурса, пока тот не закрыт. В единственном его методе close() объявляется логика закрытия этого ресурса. Пример – дескриптор открытого файла (ObjectOutputStream).
Особенность этого интерфейса в том, что его применение позволяет использовать объект в языковой конструкции try-with-resource. Всё это появилось в Java версии 7.
До Java 7 уже существовал похожий интерфейс – Closeable. Смысл его точно такой же. Он всё еще доступен в стандартной библиотеке для обратной совместимости, но в новом коде рекомендуется использовать AutoCloseable. Чтобы экземпляры старого Closeable тоже можно было использовать в try-with-resource, новый интерфейс был добавлен его родителем.
Проблема старого интерфейса Closeable была в узости типа исключений, которые может выбрасывать close(). Ковариантность позволила расширить тип в базовом интерфейсе AutoCloseable с IOException до Exception.
Еще одно отличие – контракт метода close(). Старый Closeable требует его идемпотентности, тогда как новый AutoCloseable разрешает методу иметь побочные эффекты.
Интерфейс AutoCloseable представляет объект-хранилище некоего ресурса, пока тот не закрыт. В единственном его методе close() объявляется логика закрытия этого ресурса. Пример – дескриптор открытого файла (ObjectOutputStream).
Особенность этого интерфейса в том, что его применение позволяет использовать объект в языковой конструкции try-with-resource. Всё это появилось в Java версии 7.
До Java 7 уже существовал похожий интерфейс – Closeable. Смысл его точно такой же. Он всё еще доступен в стандартной библиотеке для обратной совместимости, но в новом коде рекомендуется использовать AutoCloseable. Чтобы экземпляры старого Closeable тоже можно было использовать в try-with-resource, новый интерфейс был добавлен его родителем.
Проблема старого интерфейса Closeable была в узости типа исключений, которые может выбрасывать close(). Ковариантность позволила расширить тип в базовом интерфейсе AutoCloseable с IOException до Exception.
Еще одно отличие – контракт метода close(). Старый Closeable требует его идемпотентности, тогда как новый AutoCloseable разрешает методу иметь побочные эффекты.
👍18🔥1
Что будет в результате компиляции и выполнения данного кода?
Anonymous Quiz
41%
Пустой вывод в консоль
25%
Ошибка компиляции
27%
Вывод в консоль - true
7%
Ошибка исполнения
👍18
Как Java выбирает перегруженный метод?
Метод может быть перегружен различными параметрами – в классе могут существовать несколько разных методов с одинаковым названием. При вызове такого метода выбор конкретного варианта происходит на этапе компиляции (раннее связывание). В деталях алгоритм выбора перегруженного метода описан в спецификации.
Выбор происходит в два шага. На первом выбирается одна из трех фаз – множество подходящих методов.
1. Методы, в которые переданные параметры подходят по типу либо как есть, либо с применением расширения (upcasting) примитивов или ссылочных типов, исключая vararg-параметры.
2. Если в фазе 1 подходящих методов не нашлось, к ее условиям добавляются возможность боксинга/анбоксинга параметров. Обратите внимание, в комбинации работает только боксинг+расширение, но не наоборот.
3. Если и для фазы 2 нет удовлетворительных сигнатур, к условиям поиска подключаются vararg-параметры.
В случае, когда ни один метод не нашелся ни в одной фазе, компиляция завершается ошибкой.
Когда в фазе имеется несколько подходящих методов, используется наиболее специфичный среди них (но только в рамках данной фазы!).
Метод A считается более специфичным чем B, когда типы параметров одного метода – подтипы типов параметров другого. То есть любые возможные значения аргументов A подошли бы и для B, но не наоборот.
В условии специфичности говорится о типах параметров метода, а не о типах передаваемых значений. Так что боксинг/анбоксинг не учитывается, и метод с параметром int не считается более специфичным, чем с параметром Object (в отличие от Integer). Хотя, целое число можно передавать и как Object, и как Integer. Подробное объяснение.
Когда среди методов невозможно выделить один наиболее специфичный, происходит ошибка компиляции.
Метод может быть перегружен различными параметрами – в классе могут существовать несколько разных методов с одинаковым названием. При вызове такого метода выбор конкретного варианта происходит на этапе компиляции (раннее связывание). В деталях алгоритм выбора перегруженного метода описан в спецификации.
Выбор происходит в два шага. На первом выбирается одна из трех фаз – множество подходящих методов.
1. Методы, в которые переданные параметры подходят по типу либо как есть, либо с применением расширения (upcasting) примитивов или ссылочных типов, исключая vararg-параметры.
2. Если в фазе 1 подходящих методов не нашлось, к ее условиям добавляются возможность боксинга/анбоксинга параметров. Обратите внимание, в комбинации работает только боксинг+расширение, но не наоборот.
3. Если и для фазы 2 нет удовлетворительных сигнатур, к условиям поиска подключаются vararg-параметры.
В случае, когда ни один метод не нашелся ни в одной фазе, компиляция завершается ошибкой.
Когда в фазе имеется несколько подходящих методов, используется наиболее специфичный среди них (но только в рамках данной фазы!).
Метод A считается более специфичным чем B, когда типы параметров одного метода – подтипы типов параметров другого. То есть любые возможные значения аргументов A подошли бы и для B, но не наоборот.
В условии специфичности говорится о типах параметров метода, а не о типах передаваемых значений. Так что боксинг/анбоксинг не учитывается, и метод с параметром int не считается более специфичным, чем с параметром Object (в отличие от Integer). Хотя, целое число можно передавать и как Object, и как Integer. Подробное объяснение.
Когда среди методов невозможно выделить один наиболее специфичный, происходит ошибка компиляции.
👍23❤1🔥1
Что будет в результате компиляции и выполнения данного кода?
Anonymous Quiz
45%
Вывод в консоль - true
17%
Вывод в консоль - false
30%
Ошибка компиляции
8%
Ошибка во время исполнения
🤔14👍13
Для чего используются аннотации?
Удобно рассмотреть случаи применения аннотаций с точки зрения возможных значений их свойства RetentionPolicy:
SOURCE – аннотация присутствует только в исходном коде, но не вовлечена в компиляцию. Можно разделить их на две категории:
Первая – аннотации для программиста, а не для программы. Это всевозможные маркеры. Они добавляют аннотируемым элементам некоторую специальную семантику. Более формализованный вариант документации. Примеры – @Immutable и @ThreadSafe из Hibernate.
Вторая категория – инструкции для инструментов разработки. Примеры этой категории, @SuppressWarnings и @Override могут влиять на предупреждения и ошибки компиляции. IntelliJ IDEA умеет понимать @Nullable и @NonNull из Spring Framework, и предупреждать о возможных NullPointerException.
CLASS – самое экзотическое, но при том стандартное значение. Аннотация попадает в байткод .class-файла, но игнорируется загрузчиком классов. В результате такая аннотация недоступна для рефлекшна. Используется для сторонних инструментов, обрабатывающих байткод, например для обфускаторов.
RUNTIME – самое ходовое значение. Цель снабжается метаинформацией, доступной во время выполнения программы. Сама по себе аннотация всё так же не добавляет нового поведения. Для практической пользы runtime-аннотации в программе должен быть исполнен некоторый код процессинга, который прочитает метаинформацию инструментами Reflection API. Такой механизм широко используется во множестве популярных фреймворков: Spring, Hibernate, Jackson.
Удобно рассмотреть случаи применения аннотаций с точки зрения возможных значений их свойства RetentionPolicy:
SOURCE – аннотация присутствует только в исходном коде, но не вовлечена в компиляцию. Можно разделить их на две категории:
Первая – аннотации для программиста, а не для программы. Это всевозможные маркеры. Они добавляют аннотируемым элементам некоторую специальную семантику. Более формализованный вариант документации. Примеры – @Immutable и @ThreadSafe из Hibernate.
Вторая категория – инструкции для инструментов разработки. Примеры этой категории, @SuppressWarnings и @Override могут влиять на предупреждения и ошибки компиляции. IntelliJ IDEA умеет понимать @Nullable и @NonNull из Spring Framework, и предупреждать о возможных NullPointerException.
CLASS – самое экзотическое, но при том стандартное значение. Аннотация попадает в байткод .class-файла, но игнорируется загрузчиком классов. В результате такая аннотация недоступна для рефлекшна. Используется для сторонних инструментов, обрабатывающих байткод, например для обфускаторов.
RUNTIME – самое ходовое значение. Цель снабжается метаинформацией, доступной во время выполнения программы. Сама по себе аннотация всё так же не добавляет нового поведения. Для практической пользы runtime-аннотации в программе должен быть исполнен некоторый код процессинга, который прочитает метаинформацию инструментами Reflection API. Такой механизм широко используется во множестве популярных фреймворков: Spring, Hibernate, Jackson.
👍18
Что будет в результате компиляции и выполнения данного кода?
Anonymous Quiz
20%
-2
32%
-1
20%
0
12%
1
4%
2
12%
Ошибка во время компиляции (Invalid Syntax)
👍20🌚3
Зачем нужно ключевое слово assert?
assert – не то же самое, что методы вроде assertTrue() из тестовых библиотек. Это зарезервированное ключевое слово, унарный оператор.
Этот оператор ничего не возвращает, а принимает проверяемое утверждение типа boolean. Если значение оказывается false, проверка утверждения считается проваленной и выбрасывается AssertionError. Это похоже на сокращенную запись пары if и throw, с фиксированным типом исключения.
В Java до версии 4 слово assert не было ключевым. Поэтому для обратной совместимости механизм проверки утверждений выключен по умолчанию – логика программы никогда не должна полагаться на assert!
Включается флагом -ea или -enableassertions команды java. Можно указывать конкретные классы и пакеты в которых включить. Есть противоположный флаг -da (-disableassertions), эти флаги можно использовать в комбинации.
Assertion-ы используются в основном для дополнительной проверки инвариантов состояния объекта и для подстраховки в коде, который не должен никогда вызываться. Выброшенный AssertionError обычно означает ошибку программиста.
Дополнительно у оператора assert есть синтаксис передачи параметра detailMessage в конструктор AssertionError:
assert – не то же самое, что методы вроде assertTrue() из тестовых библиотек. Это зарезервированное ключевое слово, унарный оператор.
Этот оператор ничего не возвращает, а принимает проверяемое утверждение типа boolean. Если значение оказывается false, проверка утверждения считается проваленной и выбрасывается AssertionError. Это похоже на сокращенную запись пары if и throw, с фиксированным типом исключения.
В Java до версии 4 слово assert не было ключевым. Поэтому для обратной совместимости механизм проверки утверждений выключен по умолчанию – логика программы никогда не должна полагаться на assert!
Включается флагом -ea или -enableassertions команды java. Можно указывать конкретные классы и пакеты в которых включить. Есть противоположный флаг -da (-disableassertions), эти флаги можно использовать в комбинации.
Assertion-ы используются в основном для дополнительной проверки инвариантов состояния объекта и для подстраховки в коде, который не должен никогда вызываться. Выброшенный AssertionError обычно означает ошибку программиста.
Дополнительно у оператора assert есть синтаксис передачи параметра detailMessage в конструктор AssertionError:
assert 2*2==5 : "two times two is not five!";👍17❤2