Снижение потребления нативной памяти сборщиком G1 в Java 17 и Java 18. Расходы сократились на 35-40%.

Источник.

#java18 #g1

⚡️ На странице Oracle JDK уже появилась Java 18. Но интересно не это, а вот это предложение:

JDK 18 will receive updates under these terms, until September 2025 when it will be superseded by JDK 19

Что это значит, я пока не понял. На опечатку не похоже. Теперь все релизы будут LTS-ами что ли?

Ждём официальных постов/комментариев.

Update: больше похоже на MTS. Т.е. LTS вообще отменяется, а вместо этого все релизы станут MTS.

Update 2: похоже на опечатку на сайте. Наверное, хотели написать September 2022.

Update 3: опечатку исправили

Pattern matching for switch стало первой языковой конструкцией, которой не хватило два preview. В Java 19 будет третье preview. Неудивительно, ведь это очень сложная языковая фича с большим количеством краевых случаев.

В третьем preview предлагается заменить && в guarded patterns на when (расскажу подробней в еженедельном выпуске miniJUG).

#java19

Забавный факт.
Промежуток между выходом Java 9 и 18 – 4 года 6 месяцев.
Промежуток между выходом Java 6 и 7 – 4 года 7 месяцев.

Последствия JEP 400 в Идее

Вот такой рис продаётся в Индии. А почему не кофе то?

Нравится мне Идея. Вот какая ещё IDE вам подсветит, что вы неправильный протокол выбрали?

#юмор

⚡️ В Spring обнаружена критическая уязвимость, позволяющая злоумышленнику выполнить произвольный код. Уязвимости подвержены приложения при следующих условиях:
• JDK 9+
• Используется Apache Tomcat
• Используется WAR, а не jar
• Используются зависимости spring-webmvc или spring-webflux

Рекомендуется немедленно обновить версию Spring до 5.3.18 / 5.2.20.

#spring #vulnerability

В Java хотят вернуть грин треды!
А ещё ввести новую конструкцию try-without-resources.

Рубрика "Сомнительные советы из Интернета". Кстати, найдите ошибку.

🙏 Заключительная речь Себастьяна Дашнера на вчерашней конференции SnowOne

Замечали ли вы, что при отладке Java-приложений Step Over иногда может работать дико медленно? Ставите брейкпоинт на некоторой строке, потом шагаете по строкам, нажимая много раз F8, и бац, на каком-то из методов дебаггер тупо встаёт и долго не возвращается из метода. Иногда ждать приходится так долго, что проще убить процесс и начинать всё дебажить заново.

Некоторые могут начать винить в этом «кривую IDE», но это ограничение самой JVM. Абсолютно то же самое будет наблюдаться, если вы будете делать Step Over через jdb. Дело в том, что когда виртуальной машине шлётся команда StepRequest, то она полностью переключается в режим интерпретатора. Если метод большой и вызывает много-много других методов, то интерпретация может занять очень длительное время.

Какой выход из данной ситуации? Смириться, ведь это ограничение JVM. Но есть один простой трюк, который можно применять: использовать не Step Over (F8), а Run to Cursor (Alt + F9). Вы просто ставите мышь на следующую строку и нажимаете Alt + F9, потом опять на следующую строку и так столько раз, сколько нужно. Чуть-чуть неудобно, но если привыкнуть, то вполне рабочий вариант.

Кстати, вы можете спросить, а почему, например, IDEA так не делает по дефолту? Можно же бы было (просто) сделать так, чтобы IDEA автоматом ставила брейкпоинты на следующих строках, и всё бы летало? На самом деле, проблема в том, что в таком случае могут начаться проблемы с concurrency: какой-то поток может прийти в эту строку раньше, чем тот поток, на котором вы сейчас находитесь. А Step Over гарантировано продолжит работу в текущем потоке. Это безопаснее.

Думаю, можно бы было замутить какие-нибудь умные брейкпоинты с условиями, которые запоминали бы ID текущего потока, а потом вставало бы только, если ID совпадает. Но пока ни у кого руки не дошли.

P.S. Отладку ещё может сильно замедлять галочка “Show Method Return Values” в Debug View. Она отключена по умолчанию, но вы её могли случайно включить и забыть отключить.

#debug #intellijidea

На конференции SnowOne Иван Крылов прочитал полезный доклад «От Java 11 к Java 17». Правда в одном месте он сказал весьма странную вещь относительно hashCode(), на которую я бы хотел обратить внимание.

Во-первых, что если не переопределить hashCode(), то хеш-код объекта будет якобы получаться в результате хеширования адреса объекта, поэтому такой хеш-код будет плохого качества. Уж не знаю, почему Иван, который пол жизни занимается компиляторами и JVM, работал в Oracle и участвовал в разработке HotSpot, сказал такое :), но всё-таки важно опровергнуть сказанное.

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

По этому поводу Андрей Паньгин ещё в 2013 году написал статью на Хабре, где возмущался, что многие продолжают считать, что там используется адрес. Во всём была виновата старая документация к Object, где написано следующее:

This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.

(Но даже здесь, как видите, написано, что это “not required”)

Это предложение исправили лишь в Java 9:

The hashCode may or may not be implemented as some function of an object's memory address at some point in time.

В Java 12 решили упоминание адреса убрать совсем, оставив только ту часть, где написано, что возвращаются “distinc integers”.

Второе странное утверждение было в том, что hashCode() лучше переопределять и считать его на основе полей. Ну так это ведь от задачи зависит, разве нет? А если мне нужно сохранить identity? Тогда нужно использовать дефолтный hashCode(). Если же нужно отсутствие identity, то тогда надо переопределять и считать на основе полей. Логика абсолютно бинарная, тут нет никаких «лучше или хуже»: нужен identity – дефолтный хеш-код, не нужен identity – хеш-код на основе полей.

#hashcode

А давайте небольшой квиз, но без вариантов ответов.

Почему java.lang.String не станет value-классом?

Пишите свои ответы в комментах.

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

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

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

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

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

#string #valhalla

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

Сорец