Довольно жаркая дискуссия в данный момент происходит в рассылке OpenJDK. В январе Роман Кеннке, лидер проекта Shenandoah, работающий в RedHat, предложил бэкпортировать Shenandoah GC в JDK 11, чтобы пользователи могли продолжать пользоваться LTS-релизом, но при этом иметь возможность использовать Shenandoah. Несколько дней назад он выкатил патч с готовностью применить его к JDK 11.
Несколько человек (из Microsoft, Alibaba, Amazon) уже поддержали изменение, однако Джил Тен из Azul высказался с критикой такого серьёзного изменения (там 42к строк!). Он сказал, что стабильность превыше всего, и зрелость JDK 11 не должна нарушаться добавлением новых фич, какими классными бы они не были. Если кому-то сильно надо, то можно использовать STS-релизы, в которых есть Shenandoah (14, 15), или подождать следующего LTS-релиза Java, который выйдет всего через 18 месяцев. Роман же заверяет, что всё будет на мази, Shenandoah очень стабилен и готов к production, протестирован большим количеством пользователей и т.д. Джил же продолжает стоять на своём.
Такие вот дела.
#shenandoah

Удивительные, конечно, вещи творятся в мире OpenJDK. Microsoft (!) вот предложил прототип аллокации объектов на стеке для JVM. Говорят, что это поможет сократить количество выделяемых объектов в куче на 15%.

Java будет выдавать предупреждения при попытке засинхронизоваться на классах, которые являются кандидатами в inline-типы. Это Integer, Double, Long, Version, Optional, LocalDate, LocalTime, ProcessHandle и другие. Предупреждение будет как во время компиляции, так и во время исполнения. Кроме того, конструкторы обёрток примитивных типов станут deprecated for removal. Всё это, скорее всего, произойдёт в Java 16.
#java16 #valhalla

Многие спрашивают: почему в Java нету оператора sizeOf? Похоже, он появится. Вышел новый черновик JEP от Шипилёва: Low-level Object layout introspection methods
#шипилёв

Очень интересный выпуск подкаста Generic Talks с Иваном Углянским в гостях. Ребята обсуждают сборщики мусора в Java/Go и разбираются, почему в этих двух языках всё устроено довольно по-разному. Почему, например, в Go GC не двигает объекты и почему в нём нет поколений. Оказывается, что в Go далеко не всегда всё так радужно, как это принято считать.
Вообще, я считаю, что дискуссии получаются более живыми, когда в них участвуют специалисты из конкурирующих областей.
#go

⚡Shenandoah всё-таки был бэкпортирован в JDK 11!
#shenandoah

Вы меня простите, но это уже какая-то порнография.
#amber #records

Хочу выяснить, какая самая вредная Java-библиотека. Библиотека, которая постоянно наносит урон разработчикам, усложняет им жизнь, привносит сложность в проекты. Создаёт больше проблем, чем решает. Для этого я создал опрос в Твиттере. Будем выбирать среди 16 библиотек:
• Commons Lang
• Hibernate
• Lombok
• Jackson
• Guava
• slf4j
• Xerces
• Protobuf
• Guice
• log4j
• JUnit
• MyBatis
• JAXB
• Mockito
• Gson
• Commons Collections
16 библиотек разделены на 4 дивизиона. Голосование по первому дивизиону уже закончено, там победил Hibernate. Голосование по второму, третьему и четвёртому дивизиону открыто. У кого есть Твиттер, переходим и голосуем.

Выявим самую ужасную библиотеку! 👺💪
#hibernate #xerces #guice #jaxb #guava

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

package foo; // exported by module

public class Point {
int x, y;
}

Чтобы избавиться от предупреждения, нужно будет явно объявить конструктор:

package foo;

public class Point {
int x, y;
public Point() {
}
}
#java16

Вышел новый JEP 389: Foreign Linker API (Incubator). Его цель добавить в Java инструментарий, который является более безопасным, простым и быстрым, чем существующий JNI. Вангую, что первая реализация попадёт в Java 16. Кстати, на эту тему Владимир Иванов делал подробный 2-часовой доклад на JUGNsk. Рекомендую посмотреть, если кто ещё не видел.
#java16 #panama

Итак, четыре самых ужасных и вредных Java-библиотеки выбраны. Это Hibernate, Xerces, Guice и JAXB. Теперь нужно выбрать одну. Голосование здесь.
#hibernate #xerces #guice #jaxb

Голосование закончено. "Победил" Hibernate.
#hibernate

Давайте обсудим результаты.

Меньше всех набрал Guice. ИМХО, эту библиотеку теперь уже просто мало кто использует, потому что почти везде Spring или Java EE, где есть свой dependency injection. Вообще я не очень большой любитель dependency injection через аннотации. Не понимаю, почему нельзя просто использовать статические методы, которые возвращают сервисы. Скажем, есть сервис XYZService и у него есть реализация XYZServiceImpl. Тогда я просто вызывают метод XYZService.get(), который возвращает мне инстанс XYZServiceImpl. Вот и весь dependency injection. Причём работает такой подход всегда, не только в контексте фреймворка.

Xerces. Это одна из тех магических библиотек, которые по-моему никто никогда не использует напрямую, но она присутствует почти в любом проекте. Очень часто она вызывает конфликты в зависимостях и странные ошибки в рантайме вроде NoClassDefFoundError. Вопрос на SO про "Xerces Hell" набрал 739 лайков. Масла в огонь подливает ещё тот факт, что Xerces также присутствует в самом JDK во внутреннем пакете com.sun.org.apache.xerces.internal.jaxp. Посмотрите в свой проект. Если вы видите там xml-apis, xerces, xercesImpl, xmlParserAPIs, то это и есть Xerces, просто в различных своих ипостасях.

JAXB — это ещё одна библиотека, которая связана с XML. Больших проблем у пользователей JAXB, насколько я знаю, не было. До тех пор, пока JAXB не решили выпилить из JDK. С этого момента начался адок. Масла в огонь ещё подлил ребрендинг Java EE в Jakarta EE, в рамках которого JAXB переименовали в Jakarta XML Binding. Всё это вызвало проблемы при миграции проектов с Java 8 на последние версии Java.

Теперь про Hibernate, за который проголосовало большинство. Hibernate я использовал много лет назад и относительно недолго. У нас был проект, в котором было огромное количество таблиц (300+), и по моим воспоминаниям Hibernate неплохо так упрощал разработку. Не представляю, как можно было вообще без него обойтись в проекте такого масштаба. Проблемы, конечно, были. Самая главная из них - было очень трудно контролировать производительность SQL-запросов, которые генерировал Hibernate. Когда в запрос вовлечён десяток сущностей с нетривиальными отношениями, то итоговый SQL может быть таким, что без бутылки разобраться, почему он тормозит, почти нереально. В итоге тестеры постоянно жаловались, что вроде бы не очень сложная веб-страница открывается десятки секунд. И в этом то и проблема Hibernate: он слишком просто и быстро позволяет "колбасить" новые сущности. Если вчера вы вроде всё контролировали в своей схеме, то сегодня пришёл джуниор, добавил 5 новых таблиц и 17 новых отношений, навесил аннотаций, и сегодня у вас всё начало тормозить. Hibernate — это слишком мощный инструмент, который нельзя доверять простым смертным. With great power comes great responsibility.
#hibernate #xerces #guice #jaxb

3️⃣🗓🔥 https://www.youtube.com/watch?v=zCvCjyADHSQ
#барух #юмор

Переход JDK на Git и GitHub официально завершён. Теперь репозиторий открыт для контрибьюторов: можно делать пулл-реквесты.
#skara

Первый пулл-реквест на GitHub был интегрирован в JDK 16. На странице пулл-реквеста видно, как всё грамотно автоматизировано, и как автор и ревьюер с помощью команд могут управлять процессом. Большая часть работы при этом совершается ботами.
#java16 #skara