Сайт https://openjdk.org заработал

Немного не про Java. Как наглядно объяснить разницу между разными типами JOIN'ов одной картинкой.

В следующей версии IDEA (2022.2) при изменении размера шрифта будет всплывать индикатор размера шрифта, а также можно будет изменять шрифт глобально для всех Editor'ов (через Alt+Shift+. / Alt+Shift+,)
#IntelliJIDEA

В Java 19 наконец-то появятся методы, которые создают HashMap и HashSet с достаточным размером, чтобы туда поместилось n-ое количество элементов. Это будут следующие статические методы:

• HashMap.newHashMap(int)
• HashSet.newHashSet(int)
• LinkedHashMap.newLinkedHashMap(int)
• LinkedHashSet.newLinkedHashSet(int)

Да, у HashMap есть конструктор HashMap(int initialCapacity), но это не то же самое: этот конструктор создаёт лишь хеш-таблицу с нужной ёмкостью, а не с ожидаемым количеством элементов. Таблица расширится, если будет достигнут предел заполняемости (load factor), который по умолчанию равен 75%. Другими словами, если на пальцах, то HashMap.newHashMap(n) == new HashMap(n / 0.75).

#java19

Заработало перенаправление с https://openjdk.java.net на https://openjdk.org. https://openjdk.org теперь окончательно стал первичным доменом.

Примеры (кликните, вас должно перенаправить):
• https://openjdk.java.net/jeps/425
• https://bugs.openjdk.java.net/browse/JDK-4511638
• https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html

Алексей Шипилёв немного раскритиковал исходный код Loom, пока пытался портировать его на 32-битную архитектуру:

"Текущий код нуждается в значительной чистке, рефакторинге и (пере-)документации для того, чтобы нормально портировать и отлаживать его".

Другой разработчик, который портирует Loom на ppc64le, тоже пожаловался и сказал, что не успеет полностью портировать к выходу JDK 19.

С другой стороны, для того чтобы виртуальные нити удовлетворяли спецификации, необязательно, чтобы они были по-настоящему виртуальными. Если они будут отображаться на нити ОС, то этого будет достаточно и такая реализация будет формально соответствовать спецификации.

Таким образом, похоже, что в JDK 19 виртуальные нити будут по-честному работать только на x86_64 и AArch64, а остальные архитектуры будут делать вышеупомянутый fallback.

#loom

У какого класса в Java больше всего конструкторов? Если вам зададут такой вопрос, то можете смело отвечать java.lang.String — точно не ошибётесь. Ведь у String целых 18 конструкторов! Из них публичных 15. Давайте рассмотрим их все и попробуем понять, почему их так много.

На самом деле всё становится предельно ясным, если разбить конструкторы String на группы. Я условно выделил четыре:

1. Полезные
2. Условно-бесполезные
3. Deprecated
4. Конструкторы из StringBuilder/StringBuffer

Разберём каждую группу в отдельности.

Конструкторы из StringBuilder/StringBuffer

Это:
• public String(StringBuffer buffer)
• public String(StringBuilder builder)

Ничего сверхъестественного. Эти конструкторы вызываются в методах StringBuilder.toString() и StringBuffer.toString(). Сами конструкторы на практике практически никогда не используются, так как есть вышеупомянутые toString().

Полезные

Полезные — это конструкторы, которые иногда есть смысл использовать. Это:
• public String(char[] value)
• public String(char[] value, int offset, int count)
• public String(int[] codePoints, int offset, int count)
• public String(byte[] bytes)
• public String(byte[] bytes, int offset, int length)
• public String(byte[] bytes, String charsetName)
• public String(byte[] bytes, Charset charset)
• public String(byte[] bytes, int offset, int length, String charsetName)
• public String(byte[] bytes, int offset, int length, Charset charset)

Здесь конструкторы, которые конвертируют из char[]/byte[]/int[] в String + перегрузки с offset/length и Charset. Такие преобразования часто бывают нужны на практике, поэтому и группа называется «полезные». Не знаю, есть ли смысл подробно останавливаться на каждом конструкторе отдельности. Мне кажется, всё предельно понятно из сигнатур.

Я бы только отметил, что конструкторы String(byte[] bytes) и String(byte[] bytes, int offset, int length) используют default charset, коим в Java 18 стал UTF-8. До этого в Java charset определялся из локали. Более подробно можно почитать в JEP 400.

Условно-бесполезные

Условно-бесполезные – это два конструктора:
• public String()
• public String(String original)

Так как в Java все строки иммутабельные, то на практике эти конструкторы вызывать не имеет смысла, что написано и в их джавадоках:

Note that use of this constructor is unnecessary since Strings are immutable.

Бывают, правда, редкие исключения (поэтому группа и называется «условно-бесполезные», а не «бесполезные»). Например, когда для логики приложения необходимо использовать identity класса String. Identity-операции, напомню, это операторы == и synchronized, а так же System.identityHashCode().

Пример: вам надо логически выделить несколько разных пустых строк. Например, нужно отличать пустую строку от нулевой строки, но вы не хотите или не можете использовать null для второго случая (боитесь NPE, например). Тогда вы создаёте отдельный объект static final String NULL_STRING = new String(). Это довольно сомнительное решение, но тем не менее встречается в реальном коде, причём даже в самой стандартной библиотеке Java.

Другое исключение — это сама JVM, которая иногда должна выделять новые объекты String. Например, в спецификации Java написано (JLS 15.18.1), что оператор + на строках всегда обязан возвращать новый объект String (почему так написано в JLS – никто не знает, но спецификацию надо соблюдать). Поэтому если вы вызываете str + "", то Java не имеет права просто вернуть str, а вынуждена вызвать new String(str).

#string

Deprecated

Два deprecated конструктора String — это:

• public String(byte[] ascii, int hibyte)
• public String(byte[] ascii, int hibyte, int offset, int count)

Это два конструктора из античных времён, которые задепрекейтили ещё аж в Java 1.1. Они конвертируют массив байт в строку, но позволяют указать 8 верхних бит символов.

Эти конструкторы не стоит использовать, потому что они не делают ничего такого, чего нельзя сделать с помощью нормальных конструкторов, принимающих byte[] или char[].

Однако эти конструкторы немного используются в самой стандартной библиотеке, поскольку работают немного быстрее ближайших аналогов. Например, один из этих конструкторов используется в новой реализации Double.toString() в Java 19, которая стала во много раз быстрее предыдущей. Но надо понимать, что подобные оптимизации люди применяют не от балды, а тщательно проверив и убедившись через бенчмарки, что код действительно становится быстрее. И выигрыш там, скорее всего, совсем микроскопический.

В практическом коде же, если вам надо эффективно сконвертировать массив латинских символов в строку, то не надо выпендриваться и нужно просто вызвать new String(bytes, StandardCharsets.ISO_8859_1). Это будет почти то же самое по скорости, но будет выглядеть чисто и понятно.

Как видите, с конструкторами String всё довольно просто.

🤯 Данный код является валидным кодом на Java 19+ и компилируется.

Почему так:
1. Первый When – это имя класса.
2. Второй when – имя переменной (имеет тип When).
3. Третий when – это новое ключевое слово в Java 19, которое является контекстно-зависимым.
4. Четвёртый when – это имя переменной, которая была объявлена (см. пункт 2).
5. Пятый when() – метод класса When, возвращающий boolean.
6. Шестой when() – метод текущего класса.

#java19

New candidate JEP: 431: Sequenced Collections

https://openjdk.org/jeps/431

Introduce new interfaces to represent collections with a defined encounter order. There are uniform APIs for accessing first and last elements, and for processing elements in reverse order.

#jep #java20

JetBrains Fleet перешёл в стадию Public Preview. Его уже можно установить через JetBrains Toolbox.

⚡️ GraalVM CE переезжает в OpenJDK.

Пока никаких деталей нет кроме тех, что указаны в твите:

• Переезжает только GraalVM Community. GraalVM Enterprise, скорее всего, будет продолжать продаваться отдельно. В GraalVM EE больше оптимизаций, чем в GraalVM CE.
• GraalVM JIT и Native Image будут частью OpenJDK.
• GraalVM будет иметь тот же релизный цикл и модель лицензирования, что и OpenJDK (впрочем, у GraalVM CE и так был GPL v2, так что непонятно, что поменяется).

#graalvm

Про недавно опубликованную уязвимость в Apache Commons Text: https://www.securitylab.ru/analytics/534471.php.

TLDR: уязвимость действительно есть, но не настолько суровая, как Log4Shell. Но на всякий случай лучше обновить Commons Text до 1.10.0 (который кстати тоже остаётся уязвимым, но в меньшей степени).

На сайте Грааля вышел более подробный пост про вхождение GraalVM в состав OpenJDK. Особо ничего нового там нет. Много воды. Разве что сказано, что вхождение запланировано на 2023 год.