Похоже, что 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

Количество вопросов по разным версиям Java на StackOverflow.
Java 8 находится в сильном отрыве от всех остальных версий и имеет больше вопросов, чем в сумме все остальные версии Java.
#java8

Виктор Кланг предложил добавить новый метод gather() в стримы. Это что-то вроде collect(), но ещё более общая операция, через которую можно будет реализовать все остальные. Эдакие коллекторы 2.0. Это наконец-то сделает стримы расширяемыми.
#stream

В исходном коде java.lang.String обнаружили интересный баг, причиной которой является race condition в конструкторах строк, принимающих массивы (byte[], char[] или int[]). Эксплуатируя это состояние гонки, можно получить строки с забавными свойствами, например, что "hello world" не начинается с "hello" или что "foo" не равен "foo". Можно даже получить пустую строку, которая не равна "".

Race condition в конструкторе очень простой и заключается в том, что входной массив читается дважды в разные моменты времени (см. картинку). За то время, пока одно считывание закончилось и началось второе, содержимое массива может поменяться из другого потока.

Багу подвержены все версии JDK, начиная с Java 9 (в которой появились компактные строки). На данный момент неизвестно об уязвимостях, вызванных данных багом. Но кажется, что такие уязвимости со временем появятся, ведь сравнение строк очень частая операция (например, сравнение паролей). В багтрекере OpenJDK баг завели, но сделали приватным, что может намекать, что баг действительно может иметь последствия для безопасности.

Мне очень любопытно, как этот баг будут исправлять. Избежать многократного чтения массива можно путём создания временной копии. Но это сильно просадит производительность при создании строк. На такое явно не пойдут. Скорее всего, будут придумывать другие более изощрённые алгоритмы.

#string