Роман Кеннке сообщил в рассылке, что проекту Lilliput удалось достичь 64-битных заголовков в JDK (в обычной версии JDK они занимают 96 или 128 бит). Билды Лиллипута можно тестировать уже прямо сейчас.

Следующий шаг - заголовки размером 32 бит.

Кстати, если вдруг вам хочется иметь 64-битные заголовки в продакшене, то можете просто использовать 32-битную JDK.

#lilliput

Марк Рейнольд предложил переименовать домен openjdk.java.net в openjdk.org. Потому что родительский домен java.net сбивает с толку и вообще был закрыт в 2017 году.

🥳 Виртуальные треды попали в mainline JDK. И они уже присутствуют в ранней сборке JDK 19 build 22.
Так что уже можете скачивать и экспериментировать.

#loom #java19

Забавная ситуация наблюдается с релизом JDK 19: почти все JEP'ы в них либо превью, либо инкубатор. То есть будет много новых фич, но все они только для того, чтобы поиграться, но не для продакшена. Из стабильных только JEP 422: Linux/RISC-V Port, но я не думаю, что кто-то из читателей этого канала использует такую архитектуру. Все остальные JEP'ы нестабильные:

JEP 405: Record Patterns (Preview)
JEP 424: Foreign Function & Memory API (Preview)
JEP 425: Virtual Threads (Preview)
JEP 426: Vector API (Fourth Incubator)
JEP 427: Pattern Matching for switch (Third Preview)

Также возможно успеет попасть JEP 428: Structured Concurrency (Incubator), и он тоже инкубатор.

PS. Зато нас похоже ждёт вкусный LTS-релиз Java 21, где будет стабильный Loom, паттерн-матчинг и FFI.

#java19

Результаты опроса по версиям Java и языкам. Проценты красным и зелёным - относительно прошлого 2021 года.

Пара выводов. Во-первых, Java 8 впервые больше не самая популярная версия (в прошлом году она была чуть-чуть выше Java 11), а самая популярная теперь Java 11. Во-вторых, Java 17 приятно удивила и перегнала даже Java 8, отбросив ту на третье место.

#java8 #java11 #java17

🥳 Сегодня нашей любимой Джаве исполняется 27 лет. Её первая публичная версия вышла 23 мая 1995 года.

Сайт 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 всё довольно просто.