Всего месяц остался до первой фазы Rampdown, а в JDK 20 до сих пор нет ни одного JEP'а. Понятно, что в релиз не могут не попасть всякие вторые инкубаторы и восьмые превью. Т.е. однозначно будут:
• JEP 433: Pattern Matching for switch (Fourth Preview)
• JEP 432: Record Patterns (Second Preview)
• JEP 434: Foreign Function & Memory API (Second Preview)
• JEP XXX: Virtual Threads (Second Preview)
• JEP XXX: Structured Concurrency (Second Incubator)

А вот новые фичи что-то не подвозят. Для меня наибольший интерес представляет JEP 430: String Templates (Preview), и он сейчас в активной разработке. Надеюсь, что он всё-таки успеет.

Второй – JEP 431: Sequenced Collections, и он тоже пока в разработке.

Ещё может попасть JEP 429: Scoped values (Incubator). Раньше он назывался Extent-Local Variables.

Итого, будет где-то 5-8 JEP'ов. Релиз будет вполне полноценным.

Ну и не забывайте, что даже если в релизе нет вообще ни одного JEP'а, то в любом случае присутствуют тысячи мелких улучшений, оптимизаций, исправлений багов и т.д. Например, будет ещё большее сокращение потребляемой памяти у G1. Так что повод обновляться до Java 20 будет!

#java20

Первый коммит Илона Маска

А вы какой вариант предпочитаете?

Ну что, как вам новый дизайн Идейки? Заценили уже?
#IntelliJIDEA

Чё-то ржу

IntelliJ IDEA в 2004 году

Полезное улучшение в Java 19: отдельная страница поиска по JavaDoc'у. До Java 19 можно было вводить строку поиска только в выпадающем меню. А сейчас можно, например, скинуть коллеге ссылку со строкой запроса: https://docs.oracle.com/en/java/javase/19/docs/api/search.html?q=map%20copyof.
Кроме того, теперь можно искать по нескольким словам. Например, если ввести "map copyof", то JavaDoc найдёт все сигнатуры, где встречаются и map, и copyof.

#java19 #javadoc

Наткнулся на интересный репозиторий, где сравнивается производительность программы, написанной на Котлине, с различными вариантами компиляции: Kotlin/Native, GraalVM CE Native, GraalVM EE Native, Kotlin/Wasm (WebAssembly). Ну и, конечно же, производится замер на обычной JVM. Программа вычисляет и печатает первые 500 пар простых чисел-близнецов. Замеряется время сборки (компиляции) программы и время её выполнения. Результаты замера смотрите в комменте к этому посту или пройдите по ссылке на GitHub.

Время сборки ожидаемо самое маленькое у JVM (потому что компиляция в байткод). А вот что оказалось неожиданным, так это то, что JVM ещё и быстрее всех выполнила программу! Быстрее, чем натив – это вообще как?? Вот так. И в этом нет ничего удивительного. Всё-таки в HotSpot JIT было вложено более 20 лет усилий сотен программистов, и там очень мощные оптимизации. А Kotlin/Native и GraalVM Native – очень молодые технологии, да и разработчиков там работает меньше в разы.

Можно ли закапывать Kotlin/Native и GraalVM Native после этого? Конечно же, нет.

Во-первых, это всего лишь один частный пример. На других примерах картина может быть обратной. Например, для короткоживущих программ AOT почти всегда будет давать лучший результат. Если в этом конкретном примере взять итераций не 500, а поменьше (допустим, 20), то натив должен отработать гораздо быстрее, т.к. не будет тратить время на чтение JAR, верификацию байткода, интерпретацию, профилирование, компиляцию и т.д.

Во-вторых, посмотрите на память. JVM жрёт больше всех. Это может быть критично для вашей задачи, например, для микросервисов.

В-третьих, для запуска программы требуется JVM, которую нужно таскать с собой. А она довольно тяжёлая. И это часто неудобно (а иногда невозможно). Что проще: послать клиенту маленький экзешник 570 килобайт, который он просто тыкнет, или набор джарок с JVM и инструкцией, как запускать эти джарки и какие ключи указывать?

В-четвёртых, (shipilev mode on) будьте аккуратней с бенчмарками. Они часто врут, особенно на синтетических примерах. Нужно тестировать реальное приложение в реальных условиях (shipilev mode off).

P.S. Если интересно поподробней узнать, почему конкретно в этом примере Kotlin/Native уступает, можете почитать оригинальный тред (внимание, 2018-й год – тогда Kotlin/Native был ещё медленнее).

#kotlin #graalvm #native

Нашёл неплохую методичку по датам в Java. Сохраните в закладки.

Кстати, вы ж никогда не используете java.util.Date и java.util.Calendar? Правильно, этого не надо делать (только из-за совместимости).

Источник.

#datetime

Без комментариев

В следующей версии IntelliJ IDEA (2023.1) появится автодополнение опций JVM в Run/Debug Configurations.
В выпадающем списке будут показываться опции, которые применимы к конкретной версии JVM. То есть они не захардкожены в Идее, а вычисляются динамически для текущей JVM. То есть там будут не только стандартные опции, но и нестандартные (-X и -XX:)
#IntelliJIDEA

Похоже, что 32-битная версия Java всё: https://openjdk.org/jeps/8303167

Тагир написал книгу по Java!

Что-то в последнее время стало так много JEP'ов, что стало нереально держать их в голове одновременно (все эти пятые превью и 100500-е инкубаторы). Поэтому решил для себя составить таблицу, которая всегда была бы под рукой. А потом подумал: а почему бы её не сделать общедоступной?
Поэтому вот: https://minijug.ru/jeps.html
Таблица будет поддерживаться в актуальном состоянии.
Фидбек приветствуется.

Вышел тут пост про то, почему не надо использовать Alpine Linux. Рекомендую почитать и задуматься.
Если лень читать, то вкратце поинт такой: проблемы из-за небольших несовместимостей musl и glibc могут доставлять много хлопот, а выигрыш из-за маленького размера образа это никак не оправдывает.
#alpine