Что произойдёт, если в блоке инициализации возникнет исключительная ситуация?

Для нестатических блоков инициализации, если выбрасывание исключения прописано явным образом требуется, чтобы объявления этих исключений были перечислены в throws всех конструкторов класса. Иначе будет ошибка компиляции. Для статического блока выбрасывание исключения в явном виде, приводит к ошибке компиляции.

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

Какое исключение выбрасывается при возникновении ошибки в блоке инициализации класса?

Если возникшее исключение - наследник RuntimeException:
• для статических блоков инициализации будет выброшено java.lang.ExceptionInInitializerError;
• для нестатических будет проброшено исключение-источник.
Если возникшее исключение - наследник Error, то в обоих случаях будет выброшено java.lang.Error. Исключение: java.lang.ThreadDeath - смерть потока. В этом случае никакое исключение выброшено не будет.

Cryptomator

Мультиплатформенное прозрачное шифрование ваших файлов в облаке на стороне клиента

Stars: 9346
Forks: 751
https://github.com/cryptomator/cryptomator

Может ли статический метод быть переопределён или перегружен?

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

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

В целом, к статическим полям и методам рекомендуется обращаться через имя класса, а не объект.

Могут ли нестатические методы перегрузить статические?

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

Можно ли сузить уровень доступа/тип возвращаемого значения при переопределении метода?

• При переопределении метода нельзя сузить модификатор доступа к методу (например с public в MainClass до private в Class extends MainClass).
• Изменить тип возвращаемого значения при переопределении метода нельзя, будет ошибка attempting to use incompatible return type.
• Можно сузить возвращаемое значение, если они совместимы.
Например:

public class Animal {

public Animal eat() {
System.out.println("animal eat");
return null;
}

public Long calc() {
return null;
}

}
public class Dog extends Animal {

public Dog eat() {
return new Dog();
}
/*attempting to use incompatible return type
public Integer calc() {
return null;
}
*/
}

Spring Boot 2. Лучшие практики для профессионалов (2020) PDF

Хотите повысить свою эффективность в разработке корпоративных и облачных Java-приложений?
Увеличьте скорость и простоту разработки микросервисов и сложных приложений, избавившись от забот по конфигурации Spring.
Используйте Spring Boot 2 и такие инструменты фреймворка Spring 5, как WebFlux, Security, Actuator, а также фреймворк Micrometer, предоставляющий новый способ сбора метрик.
В этой книге: настройка и использование Spring Boot 2; работа с нефункциональными требованиями с помощью Spring Boot Actuator; разработка веб-приложений с помощью Spring Boot 2; постоянное хранение данных с использованием JDBC, JPA и баз данных NoSQL; обмен сообщениями с помощью JMS, RabbitMQ и WebSockets; краткое знакомство с проектами Spring Cloud; тестирование, микросервисы и развертывание в облачной среде с использованием Spring Boot 2; расширение Spring Boot путем создания своего собственного «стартового набора» и добавления функциональности @ Enable.

Возможно ли при переопределении метода изменить: модификатор доступа, возвращаемый тип, тип аргумента или их количество, имена аргументов или их порядок; убирать, добавлять, изменять порядок следования элементов секции throws?

При переопределении метода сужать модификатор доступа не разрешается, т.к. это приведёт к нарушению принципа подстановки Барбары Лисков. Расширение уровня доступа возможно.

Можно изменять все, что не мешает компилятору понять какой метод родительского класса имеется в виду:

• Изменять тип возвращаемого значения при переопределении метода разрешено только в сторону сужения типа (вместо родительского класса - наследника).
• При изменении типа, количества, порядка следования аргументов вместо переопределения будет происходить overloading (перегрузка) метода.
• Секцию throws метода можно не указывать, но стоит помнить, что она остаётся действительной, если уже определена у метода родительского класса. Так же, возможно добавлять новые исключения, являющиеся наследниками от уже объявленных или исключения RuntimeException. Порядок следования таких элементов при переопределении значения не имеет.