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

Меньше всех набрал 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

Shenandoah попадёт в JDK 11.0.9. Релиз выйдет 20 октября 2020 года.
#shenandoah

В Java 16 появится метод Stream::mapMulti, очень похожий на Stream::flatMap.
Разница с flatMap:
• В mapMulti не будет создаваться новый стрим на каждом шаге, а значит будет меньше накладных расходов.
• В некоторых случаях императивный маппер удобнее, чем возвращение стрима.
#java16 #stream

Будут ли языковые изменения в Java 16?

В Java 16 принципиально новых языковых фич, скорее всего, не будет. Но будут небольшие изменения в существующих.

Во-первых, pattern matching for instanceof станет стабильной фичей (я крайне сомневаюсь, что будет третье превью, хотя на 100% это не исключено). Изменения будут следующими:
• Переменные паттернов не будут неявно final. Это сделает их согласованными с обычными переменными и параметрами методов/лямбд. То есть можно будет написать:
if (x instanceof String s) {
s = "abc"; // В Java 15 ошибка компиляции, в 16 - OK
}
• Предлагается запретить делать такие тесты, в которых тип выражения является подклассом типом паттерна. Например:
String x = "abc";
if (x instanceof String s) { // ошибка компиляции
...
}
Имхо, это плохое ограничение, и я против его введения (потому что будет несогласованность с обычным instanceof, где так можно делать).

Во-вторых, записи тоже станут стабильной фичей (и тоже третье превью маловероятно). Изменение будет только одно: предлагается разрешить объявлять статические члены во вложенных классах:
class A {
class B {
static void foo() { // OK
...
}
}
}
#java16 #records

Небольшое обновление: value-based классы будут помечаться новой аннотацией @​ValueBased. Также у этого предложения появился JEP.
#valhalla

Value-типы хотят переименовать во второй раз🤦‍♂️. Теперь это будут не inline-типы, а примитивные типы.
#valhalla

Вышла Guava 30. Пользуетесь Гуавой?
#guava

Inline-типы должны скаляризоваться. Но только в C2. И если там не интерфейс. И вообще это не точно.
#valhalla

Походу, они обосрались, и не включили Shenandoah в AdoptOpenJDK 11.0.9.
P.S. Shenandoah есть в Azul Zulu и, само собой, в редхатовской сборке.
#shenandoah

Починили
#shenandoah

А вот и JEP подъехал

Как позвать protected метод у класса в чужом пакете? Ловите простой трюк. Просто переопределяем метод в анонимном классе, и сразу же вызываем его на этом объекте:

new ClassWithProtectedMethod() {
@Override
protected void method() {
super.method();
}
}.method();

Заметьте, что метод даже не пришлось делать public.

В Java 16 появится метод Stream.toList(), который позволит конвертировать Stream в список. Сейчас это можно сделать с помощью Stream.collect(Collectors.toList()) и Stream.collect(Collectors.toUnmodifiableList()), однако toList() будет не только короче, но и эффективнее, поскольку не будет создавать никаких промежуточных массивов.

Кроме того, между всеми тремя способами есть различия:

• collect(Collectors.toList()) не гарантирует неизменяемость, позволяет нули (по факту возвращает ArrayList)
• collect(Collectors.toUnmodifiableList()) гарантирует неизменяемость, не позволяет нули
• toList() гарантирует неизменяемость, позволяет нули (по факту возвращает неизменяемый список)
#java16 #stream