Полезное улучшение в 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

Стюарт Маркс, например: https://youtu.be/NA-sB3zvluE

Помните, были такие сырые строковые литералы? Их хотели добавить в Java 12, но потом отказались от этой идеи.

Так вот, эту идею подхватил C# 11. Смысл очень похожий на Java 12: сырой строковый литерал может начинаться с любого количества кавычек (минимум 3), но должен и заканчиваться на то же самое количество. А между этими n-арными кавычками можно вставить любую чухню (главное, чтобы не было n кавычек подряд):

string raw = """"
   Hello, "John"!
""""

Но это ещё не всё. В C# ведь ещё есть строковая интерполяция ($"Hello, {name}!"). Как будут выглядеть сырые строковые литералы с интерполяцией?
А правило такое: количество долларов контролирует количество фигурных скобок, обрамляющих интерполяцию внутри литерала!

Например:

string name = "John";
string raw = $$"""
   Hello, {{name}}!
   My {name} is {{{name}}}
"""

Эта строка превратится в:

Hello, John!
My {name} is {John}

Т.е. понимаете? Не только количество кавычек произвольное, но и количество долларов! Например, вот такой код является валидным кодом на C# 11:
$$$$$$$$$$$$""""""""""""""""
Hello
""""""""""""""""

Но это ещё не всё. Всё это безумие ещё добавляется к буквальным строковым литералам, которые начинаются с @". Т.е. в C# теперь есть 6 видов литералов: обычные, обычные с интерполяцией, буквальные, буквальные с интерполяцией, сырые и сырые с интерполяцией.

Теперь вы понимаете, почему в Java так тщательно продумывают новые фичи и неспешно их вводят?

Лучше уж мало фич, но без подобного синтаксического сумасшествия.

#csharp

В Java 21 появился долгожданный метод reversed(), который возвращает view коллекции с обратным порядком:

jshell> List.of(1, 2, 3, 4, 5).reversed()
$1 ==> [5, 4, 3, 2, 1]

Этот метод есть у любой коллекции, реализующей интерфейс SequencedCollection (List, Deque, Stack и т.д). Кстати, всё это уже есть в последнем билде JDK 21-ea+20, так что можно затестить.

#java21

Сергей Куксенко про виртуальные потоки: https://youtu.be/MOgynY7VIJI
#loom