Какой, по вашему мнению, самый важный релиз в истории Java, который наибольшим образом продвинул язык и платформу?
(Считаем, как будто STS-релизов вообще не было и выходили только LTS-релизы, содержащие в себе все нововведения из предшествующих STS)
(Считаем, как будто STS-релизов вообще не было и выходили только LTS-релизы, содержащие в себе все нововведения из предшествующих STS)
Anonymous Poll
14%
Java 5 (generics, annotations, enum, autoboxing, enhanced for-loop)
2%
Java 7 (try-with-resources, diamond, switch over strings, multicatch, nio2)
75%
Java 8 (lambdas, streams, default methods, java.time)
2%
Java 11 (modules, var, compact strings, launch single-file source programs)
2%
Java 17 (switch expr, text blocks, records, pm for instanceof, sealed, zgc, shenandoah)
5%
Java 21 (pm for switch/records, loom, sequenced collections, generational zgc)
В исходном коде java.lang.String обнаружили интересный баг, причиной которой является race condition в конструкторах строк, принимающих массивы (byte[], char[] или int[]). Эксплуатируя это состояние гонки, можно получить строки с забавными свойствами, например, что "hello world" не начинается с "hello" или что "foo" не равен "foo". Можно даже получить пустую строку, которая не равна "".
Race condition в конструкторе очень простой и заключается в том, что входной массив читается дважды в разные моменты времени (см. картинку). За то время, пока одно считывание закончилось и началось второе, содержимое массива может поменяться из другого потока.
Багу подвержены все версии JDK, начиная с Java 9 (в которой появились компактные строки). На данный момент неизвестно об уязвимостях, вызванных данных багом. Но кажется, что такие уязвимости со временем появятся, ведь сравнение строк очень частая операция (например, сравнение паролей). В багтрекере OpenJDK баг завели, но сделали приватным, что может намекать, что баг действительно может иметь последствия для безопасности.
Мне очень любопытно, как этот баг будут исправлять. Избежать многократного чтения массива можно путём создания временной копии. Но это сильно просадит производительность при создании строк. На такое явно не пойдут. Скорее всего, будут придумывать другие более изощрённые алгоритмы.
#string
Race condition в конструкторе очень простой и заключается в том, что входной массив читается дважды в разные моменты времени (см. картинку). За то время, пока одно считывание закончилось и началось второе, содержимое массива может поменяться из другого потока.
Багу подвержены все версии JDK, начиная с Java 9 (в которой появились компактные строки). На данный момент неизвестно об уязвимостях, вызванных данных багом. Но кажется, что такие уязвимости со временем появятся, ведь сравнение строк очень частая операция (например, сравнение паролей). В багтрекере OpenJDK баг завели, но сделали приватным, что может намекать, что баг действительно может иметь последствия для безопасности.
Мне очень любопытно, как этот баг будут исправлять. Избежать многократного чтения массива можно путём создания временной копии. Но это сильно просадит производительность при создании строк. На такое явно не пойдут. Скорее всего, будут придумывать другие более изощрённые алгоритмы.
#string
✍10👀10🤔7😁6👍3❤1🔥1
Начиная с Java 22, предлагается выдавать предупреждения при использовании JNI. Выглядеть это будет как-то так:
В какой-то из будущих версий Java предупреждение уже будет полностью заменено на исключение IllegalCallerException. Так что для приложений, использующих JNI, флаг
Про полное удаление JNI пока речи не идёт.
Напомним, что в OpenJDK много лет разрабатывается альтернатива JNI — Foreign Function & Memory API (FFM). В той же Java 22 она выйдет из состояния preview и станет стабильной частью Java. FFM является более безопасной, чем JNI, и при её использовании флаг
#java22 #jni #ffm
WARNING: A restricted method in java.lang.System has been called
WARNING: System::load has been called by com.foo.bar.Server in {an unnamed module, module com.foo.bar}
WARNING: Use --enable-native-access={ALL-UNNAMED, com.foo.bar} to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
Для подавления таких предупреждений надо будет запускать приложение с флагом --enable-native-access, где надо будет указать список модулей, которым разрешено загружать нативный код. Если в рантайме будет попытка загрузки из модуля не из списка, то уже будет вылетать IllegalCallerException.В какой-то из будущих версий Java предупреждение уже будет полностью заменено на исключение IllegalCallerException. Так что для приложений, использующих JNI, флаг
--enable-native-access уже будет обязательным.Про полное удаление JNI пока речи не идёт.
Напомним, что в OpenJDK много лет разрабатывается альтернатива JNI — Foreign Function & Memory API (FFM). В той же Java 22 она выйдет из состояния preview и станет стабильной частью Java. FFM является более безопасной, чем JNI, и при её использовании флаг
--enable-native-access можно будет не указывать и Java не будет выдавать предупреждения (за исключением ситуации, когда используется небезопасная часть FFM API — для неё всё будет аналогично JNI).#java22 #jni #ffm
🔥6👍5⚡1
В OpenJDK предложен новый проект Babylon. Он позволит доступаться до структуры Java кода не только во время компиляции, но и во время выполнения. Это позволит рантайму анализировать и трансформировать код, например, генерировать код на SQL (аналогично Expression Trees в C#, что открывает возможности для таких вещей как LINQ).
Про это также был доклад на JVM Language Summit.
#babylon
Про это также был доклад на JVM Language Summit.
#babylon
🔥10👍4🤯3🎉1🌚1🤨1
Плагин JPA Buddy к IntelliJ IDEA Ultimate стал полностью бесплатным
👍20🤮3💅1
Похоже, что в Java 22 безымянные переменные и паттерны выйдут из preview. Это будет первый случай, когда языковая конструкция пробыла в preview всего один релиз.
Ранее все языковые конструкции в preview были как минимум два релиза:
• switch expressions: два релиза (Java 12 и 13)
• text blocks: два релиза (Java 13 и 14)
• records: два релиза (Java 14 и 15)
• pattern matching for instanceof: два релиза (Java 14 и 15)
• sealed: два релиза (Java 15 и 16)
• pattern matching for switch: 4 релиза (Java 17, 18, 19 и 20)
• records patterns: два релиза (Java 19 и 20)
Ну и теперь unnamed variables and patterns: только 1 релиз (Java 21)
#java22
Ранее все языковые конструкции в preview были как минимум два релиза:
• switch expressions: два релиза (Java 12 и 13)
• text blocks: два релиза (Java 13 и 14)
• records: два релиза (Java 14 и 15)
• pattern matching for instanceof: два релиза (Java 14 и 15)
• sealed: два релиза (Java 15 и 16)
• pattern matching for switch: 4 релиза (Java 17, 18, 19 и 20)
• records patterns: два релиза (Java 19 и 20)
Ну и теперь unnamed variables and patterns: только 1 релиз (Java 21)
#java22
👍10🔥3🤯3✍1🤔1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁22❤9👍1
Вышла сразу пачка новых JEP'ов.
JEP 456: Unnamed Variables and Patterns
Безымянные переменные и паттерны станут стабильными в Java 22 после всего одного раунда превью.
JEP: String Templates (Final)
Шаблонные строки, похоже, тоже станут стабильными в Java 22.
JEP: Implicitly Declared Classes and Instance Main Method (2nd Preview)
Безымянные классы хотят переименовать в implicitly declared классы.
JEP 455: Primitive types in Patterns, instanceof, and switch (Preview)
Можно будет писать
JEP 457: Class-File API (Preview)
API для чтения, записи и трансформации Java class-файлов. Кстати, оно уже есть в Java 21, но в internal пакете
#java22
JEP 456: Unnamed Variables and Patterns
Безымянные переменные и паттерны станут стабильными в Java 22 после всего одного раунда превью.
JEP: String Templates (Final)
Шаблонные строки, похоже, тоже станут стабильными в Java 22.
JEP: Implicitly Declared Classes and Instance Main Method (2nd Preview)
Безымянные классы хотят переименовать в implicitly declared классы.
JEP 455: Primitive types in Patterns, instanceof, and switch (Preview)
Можно будет писать
if (obj instanceof int). Вангую, что тоже попадёт в Java 22.JEP 457: Class-File API (Preview)
API для чтения, записи и трансформации Java class-файлов. Кстати, оно уже есть в Java 21, но в internal пакете
jdk.internal.classfile. В Java 22 станет preview.#java22
🆒8🤯1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁18❤1😴1
microJUG
Виктор Кланг предложил добавить новый метод gather() в стримы. Это что-то вроде collect(), но ещё более общая операция, через которую можно будет реализовать все остальные. Эдакие коллекторы 2.0. Это наконец-то сделает стримы расширяемыми. #stream
Предложение в итоге вылилось в JEP 461: Stream Gatherers (Preview)
👍11🤔3💩2✍1🔥1
Вышел Spring 6.1 GA 🥳
Вместе с ним выходит Spring Boot 3.2, но это произойдёт 23 ноября, так что надо чуть-чуть подождать.
В релизе Spring 6.1 тонна всего нового, но главная фишка – это, конечно же, поддержка виртуальных потоков. Включаются они флагом
Ещё из интересного:
Новый интерфейс RestClient. Он синхронный, как и старый RestTemplate, но имеет современное удобное fluent API, похожее на WebClient, появившийся в Spring 5. Он не использует WebFlux, а значит не требует зависимости spring-webflux. Т.к. теперь есть виртуальные потоки, то синхронность уже не является проблемой и не вредит масштабируемости. RestClient, как и WebClient, разумеется, поддерживает декларативные HTTP-клиенты, созданные из интерфейсов с аннотациями @HttpExchange.
Новый интерфейс JdbcClient. Это современная альтернатива JdbcTemplate с fluent API:
Ещё появилась поддержка CRaC, поддержка
#spring
Вместе с ним выходит Spring Boot 3.2, но это произойдёт 23 ноября, так что надо чуть-чуть подождать.
В релизе Spring 6.1 тонна всего нового, но главная фишка – это, конечно же, поддержка виртуальных потоков. Включаются они флагом
spring.threads.virtual.enabled=true (требуется JDK 21+). С виртуальными потоками можно спокойно вызывать блокирующее API и ни о чём не беспокоиться.Ещё из интересного:
Новый интерфейс RestClient. Он синхронный, как и старый RestTemplate, но имеет современное удобное fluent API, похожее на WebClient, появившийся в Spring 5. Он не использует WebFlux, а значит не требует зависимости spring-webflux. Т.к. теперь есть виртуальные потоки, то синхронность уже не является проблемой и не вредит масштабируемости. RestClient, как и WebClient, разумеется, поддерживает декларативные HTTP-клиенты, созданные из интерфейсов с аннотациями @HttpExchange.
Новый интерфейс JdbcClient. Это современная альтернатива JdbcTemplate с fluent API:
Optional<Integer> value = client.sql("SELECT AGE FROM CUSTOMER WHERE ID = :id")
.param("id", 3)
.query(Integer.class)
.optional();Ещё появилась поддержка CRaC, поддержка
@HttpExchange аннотаций в MVC-контроллерах и многое другое. Подробный список можно посмотреть тут.#spring
❤18🎉9🥱1