Итак, правильного ответа по поводу String не прозвучало, поэтому озвучиваю его сам.

Были очень близкие ответы вроде того, что все привыкли, что String имеет identity, поэтому много кто на это завязался. Но в реальности таких людей на самом деле не очень много. Вот вы сами где-нибудь синхронизовались на строках в своих проектах или закладывались на то, что new String("hello") != "hello"? Я вот ни разу. Может, кому-то такое изменение и поломает логику, но если по-честному, то эти люди сами виноваты, что написали такой кривой код.

В другом озвученном ответе было то, что если String станет value-классом, то оператор == будет сравнивать объекты на основе полей, а в String есть поля, которые считаются лениво. Но это не является существенным препятствием, т.к. для String можно было бы кастомизировать поведение оператора == в виртуальной машине и просто не учитывать поля hash и hashIzZero (всё равно ведь оператор == теперь виртуальная функция, ну расширим табличку, добавив специальный случай для String).

Короче, все эти препятствия можно было бы худо-бедно обойти, но вот следующую проблему решить никак нельзя: оператор == больше не будет выполняться за константное время (ведь теперь строки придётся сравнивать по содержимому, а не просто сравнивать ссылки). В мире существует очень много кода, где строки сравниваются через ==. Весь этот код станет тормозить на длинных строках, потому что каждое сравнение станет O(N).

Разработчики JVM никогда не пойдут на изменение, результатом котором станет алгоритмическое замедление одной из базовых операций на одном из самых главных классов стандартной библиотеки.

#string #valhalla

Roadmap для разработчика Java в 2022 году. Узнали? Согласны?
Можно распечатать и повесить в кабинете.

Сорец

🥳 Ну всё, Loom теперь уже точно в Java 19, правда пока preview.

Роман Кеннке сообщил в рассылке, что проекту 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