• Вышли обновления Java:
18.0.2.1, 17.0.4.1, 11.0.6.1 – вынужденные обновления, которые пришлось выпустить из-за критической регрессии в JIT-компиляторе C2, вызывающей креш JVM.
8u345 пришлось выпустить из-за другого критического бага в 8u342.
• Вышел первый релиз-кандидат Java 19.
• Вышел новый JEP 429: Extent-Local Variables (Incubator). В нём предлагается ввести новый класс ExtentLocal в качестве альтернативы существующему классу ThreadLocal.
Классы ThreadLocal и ExtentLocal похожи тем, что решают одну и ту же задачу: передать значение переменной в рамках одной нити (или дерева нитей) из одного места в другое без использования явного параметра. В случае ThreadLocal для этого вызывается метод set(), который кладёт значение переменной для данной нити, а потом метод get() вызывается из другого места для получения значения переменной. У данного подхода есть ряд проблем, например, неконтролируемая мутабельность (set() можно вызвать когда угодно и откуда угодно), неограниченное время жизни (переменная очистится, только когда исполнение всей нити завершится или когда будет вызван remove(), но про него часто забывают), высокая цена наследования (дочерние нити всегда вынуждены делать полную копию переменной, даже если родительская нить никогда не будет её изменять).
В отличие от ThreadLocal, ExtentLocal не имеет метода set(). Однажды ассоциированное с объектом ExtentLocal значение остаётся иммутабельным. Для этого используется метод where(). Кроме того, значение ассоциируется на ограниченный срок, который определяется длительностью метода run(). Как только исполнение метода run() заканчивается, значение отвязывается от объекта ExtentLocal. Поскольку значение не меняется, решается и проблема дорогого наследования: дочерним нитям не надо копировать значение, которое остаётся постоянным в течение периода жизни.
Пример использования ExtentLocal:
private static final ExtentLocal<Credentials> CREDENTIALS =
ExtentLocal.newInstance();
Credentials creds = ...
ExtentLocal.where(CREDENTIALS, creds).run(() -> {
...
Connection connection = connectDatabase();
...
});
Connection connectDatabase() {
Credentials credentials = CREDENTIALS.get();
...
}
Во многих случаях ExtentLocal будет являться предпочтительной заменой ThreadLocal. Однако когда иммутабельный подход неприменим для решения задачи, ThreadLocal может остаться предпочтительным.
• Вышел SLF4J 2.0. Это первое мажорное обновление фасада логирования спустя 17 лет после выхода первой версии. Новая версия теперь требует Java 8 и содержит новый Fluent Logging API. Кроме того, SLF4J API теперь использует механизм ServiceLoader для нахождения соответствующего логирующего провайдера. SLF4J 2.0 полностью обратно совместим с SLF4J 1.x, т.е. весь существующий код, использующий SLF4J API, не требует перекомпиляции. Однако при обновлении до второй версии потребуется соответствующее обновление бэкенда, иначе SLF4J API не сможет найти бэкенд и выдаст предупреждение.
Вместе с выходом второй версии SLF4J вышли Logback 1.3.0 и 1.4.0, которые поддерживают SLF4J 2.0. Различие между 1.3.0 и 1.4.0 состоит в том, Logback 1.4.0 требует Java 11 и использует пространство имён Jakarta EE (jakarta.*), в то время как Logback 1.3.0 работает на Java 8 и использует Java EE (javax.*).
• Вышла IntelliJ IDEA 2022.2. Теперь среда разработки использует JetBrains Runtime 17 вместо 11.
• Вышла Java Annotated Monthly от JetBrains за август.
• Вышел Helidon 3.0. Теперь фреймворк требует Java 17 и поддерживает спецификации MicroProfile 5.0 и Jakarta EE 9.1.
