Java дайджест #18: ожидание Java 9, G1 — сборщик мусора по умолчанию, почему убили log4j 1

Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!)

Countdown to Java 9 Release Date.

Что-то вроде планов

(!) JEP 269: Convenience Factory Methods for Collections. На мой взгляд, более разумное решение чем расширение языка.

Case for Defaulting to G1 Garbage Collector in Java 9.

High Level Plans for Spring 4.3 and 5.0 Announced at SpringOne2GX.

Groovy and Grails Plans Announced at SpringOne2GX.

Что-то вроде новостей

Вышел OpenJPA 2.4.

Вышел Log4j 2.4.

Вышел Gradle 2.7.

Вышел Ratpack 1.0.0.

Почитать и посмотреть

Casting In Java 8 (And Beyond?)

Lightweight Java servers and developer view on the App Server. Довольно неплохое сравнение Java-серверов.

Build and Release Scala/Java Gradle Project in GitLab Using Jenkins to Artifactory. Какие еще базворды тулы забыли?

Hashmap Performance Improvements in Java 8.

Блог со ссылками по теме Java для десктопов.

Java 8: Composing functions using compose and andThen.

Why do I get message «CodeCache is full. Compiler has been disabled»?

Интервью о EOL Log4j 1.

How to use Java 8 Functional Programming to Generate an Alphabetic Sequence. Задачка интересная, но вот решать ее используя фичи Java 8, на мой взгляд, странно.

«Инсайдеры» в Oracle говорят что мы все умрем... Снова.

Why you shouldn’t use the double brace initializer. Напоминание о том что магии не существует.

JSF Showcase. Коллекция ссылок по JSF.

Разное

winterbe/streamjs — порт стрим АПИ для Javascript.

cxxr/better-java — если вы хипстер, но хотите писать на джава, то вам сюда.



Предложения и пожелания все еще принимаются или через завсклад и товаровэд администрацию ДОУ, или через твиттер @_silverwolf. Также можно оставлять комментарии в специально выделенной теме на форуме.


← Предыдущий выпуск: Java дайджест #17
Следующий выпуск: Java дайджест #19

LinkedIn

36 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Кто-то сравнивал vertx.io и ratpack.io ?

Collection initializers
Range initializers
Multiline strings
String templating (Groovy Strings)

Питання риторичне, звісно. Але невже настільки складно додати у синтаксис мови підтримку простих, але зручних фіч? Ніхто не відміняє того факту що JEP 269 хороший і потрібний. У чому проблема зробити ще один крок?

Питання риторичне, звісно. Але невже настільки складно додати у синтаксис мови підтримку простих, але зручних фіч?
Ну это как раз не риторическое, ибо это можно узнать разобравшись с исходниками и посмотрев архив обсуждений по тем же лямбдам.
Вопрос в том: Зачем? :)

Наявність таких фіч полегшить написання зокрема тестів. Це перше що у голову приходить.

Наявність таких фіч полегшить написання зокрема тестів. Це перше що у голову приходить
А теперь давайте второе :)
Collection initializers
Range initializers
Multiline strings
String templating (Groovy Strings)
Приведите примеры когда вам именно нужны эти фичи в языке, а не просто как библиотечные вызовы (по типу JEP 269, Guava, Mockito, Hamcrest, etc.). Мне и правду интересно, ибо сугубо из моего опыта там где например хочется использовать для тестов Multiline strings или String templating это как раз ухудшает архитектуру кода (проще написать тест на плохой код).
Груди для тестов конечно же крут, но его крутость совсем в другом: в его динамической природе.

Можете коротко розказати, про що йшлось в тих обговореннях?

Можете коротко розказати, про що йшлось в тих обговореннях?
Помимо объективных моментов с потенциальными перформанс проблемами. Не всегда есть возможность сгенерить универсальный код для той или иной конструкции (банально лямбды в первых ревизиях были просто анонимными классами). Там много чего обсуждалось.
Есть и более субъективные проблемы:
«Зеленые абизянки» вкладывают одно знаяение в ->, а «красные абизянки» считают что правильно использовать => вместо ->, а «трейтья равная половина» имеет свое особое мнение.

Дякую. «Третя рівна половина» була проти лямбд взагалі, напевно: декілька разів зустрічав думку, що лямбди мають негативний вплив «на надійність софту» і «на реалізацію крупних проектів».

Бо прості і зручні фічі в Java з’являються раз на 15 років. Благо, try-with-resources маєм. До того приходилось писати всякого роду сурогати CloseableProcessor<t> чи використовувати Closer. А так, із списку хіба collection initializers було б непогано мати і, можливо, string interpolation, якщо я правильно розумію «string templating».

Спасибо за линку на пост о том, что магии не существует.
Буду этот пост теперь неистово кидать во всех быдлокодеров, которые не хотят понимать, что каждый раз, когда они юзают double brace initialization где-то в мире умирает не один, а целая дюжина котят! И это там ещё не упомянуто о том, что происходит при попытке сравнения коллекций, созданных и наполненных таким образом! Зла не хватает! За такое нужно отрезать конечности, ИМХО!

А что происходит при сравнении коллекций заполненых таким образом? Извините, возможности проверить сейчас нету

Блин, не удалось сразу найти это в старом коде, чтобы нормально описать с примером.
В общем, проблема заключается в следующем. Я несколько месяцев назад натыкался в проекте на ситуацию, когда в тесте нужно было сравнивать мапы, представляющие собой состояние заданного объекта. У объекта был класс toMap(), писанный не мной, который возвращал мапу, созданную с помощью double brace initialization, вторую мапу я создавал и заполнял сам непосредственно перед сравнением, в результате при сравнении вылетало ClassCastException, т.к. класс мапы, созданной с помощью double brace initialization имел привязку к классу объекта из которого она была создана и никак не хотел приводиться к классу обычной джавовской мапы. Мне пришлось переписывать метод toMap(), избавляясь от создания анонимного класса.

Владимир, Вы несколько преувеличиваете вредность {{}} инициализации.
1. Весьма удобно для успользования при тестах.
2. По поводу переписывания toMap() - может было бы проще использовать new HashMap( mapWithNiceDoubleBraceInitializatoin ) и дальше сравнивать ? ;)
3. Для в продакшен коде действительно лучше не использовать. И не отлько по тем причинам которые указал автор

1. Весьма удобно для успользования при тестах.
В общем да, но сугубо из личного опыта: вынести подобную инициализацию в метод — улучшает читабольность в разы.
1. Весьма удобно для успользования при тестах.
Я стараюсь писать так, чтобы у тех, кто будет пользоваться моим кодом было как можно меньше с ним проблем. Double brace initializaion, имхо, костыль, который читается конечно легко, но может привести к проблемам. Да и куча анонимных классов не радует, особенно если таких конструкций 20+, то количество SomeClass$n.class файлов не радует глаз, да и класслоадер, наверное, тоже не очень рад этому.
может было бы проще использовать new HashMap( mapWithNiceDoubleBraceInitializatoin ) и дальше сравнивать ?
Проще — да, эффективнее — нет, ибо после меня опять кто-то мог бы на эту проблему наскочить и сидеть потом инвестигейтить, что же это за хрень такая, что не сравниваются мапы.
в продакшен коде действительно лучше не использовать
Лучше вообще не использовать. Привычка делать исключения и использовать вредные подходы потом приводит к появлению в продакшене такого кода рано или поздно.

1. Вероятно у Вас есть куча времени разглядывать скомпиленные классы.
2. Предложенное мною решение — 1 строка, Вами — переписывание метода, результат — одинаков. Где-то тут обитают любители самописных аллокаторов пямяти под C++, они весьма эффективны в растрате времени .
3. Лучше не использовать, звучит как — не надо пользоваться ножем, им можно порезаться.
Для всяких подходов и технологий есть область применимости.

Лучший ДОУ дайджест :)

“Инсайдеры” в Oracle говорят что мы все умрем... Снова.
Java Довго буде в топі і мейнстрімі, але Oracle хоче вийти з гри і можливо інвестувати в нову мову програмування (яку?)
Java Довго буде в топі і мейнстрімі, але Oracle хоче вийти з гри і можливо інвестувати в нову мову програмування (яку?)
Когда речь заходит об Оракл и клауде довольно часто упоминают Node.js ...

Лучшее — враг хорошего. И во что бы они не инвестировали, это будет дауншифтом. Что реально стоило бы делать — это что-то из надстроек и монетезировать их. Благо на java много чего уже превратилось в денежку.

А ещё есть метод просто притормозить, посмотреть чего сотворят конкуренты — и слизать. Ну или совсем уж жуткий рецепт, на который они не пойдут никогда: услышать чего хотят сами кодеры и реализовать это не через жопу.

Треба Паламарчука попросити накидати статтю 10 варіантів розвитку Java в найближчому майбутньому :)

Мені от дивно чому Oracle контролює Java. Вона вже давно переросла те щоб її контролювала одна компанія, я б навіть сказав це уже суспільне надбання як інтернет :)

Називати статичні методи, в яких публічна видимість, просто «of», «create» чи «newInstance» — дикий моветон хіба за винятком однієї фундаментальної речі як Optional.of. Double brace initializer не став би нікому рекомендувати до використання взагалі.

Називати статичні методи, в яких публічна видимість, просто «of», «create» чи «newInstance» — дикий моветон хіба за винятком однієї фундаментальної речі як Optional.of
Почему? И как бы назвать правильно?

Зокрема, через клеші при статичному імпорті методів з однаковими іменами.

Зокрема, через клеші при статичному імпорті методів з однаковими іменами.
Статик импорты удобны для использования сборищь общих алгоритмов, типа Math (неправильное ООП :) ). Основная их задача — это убрать шум в случаях когда название класса не несет логической нагрузки.
В нашем случае же мы имеем порождающие статик методы, класс является их неотемлимой частью. Дополнительный бонус еще и более ООП подход, так как мы классу посылаем сообщении создать свой инстанс.

Я все ж би не розглядав статичний імпорт просто як синтаксичне спрощення для класів типу Math. LinkedHashSet.of із запропонованого JEP 269 має свій аналог в Google Guava під виглядом newLinkedHashSet(), і чудово імпортується без клешів поряд, скажімо, із newTreeSet(). Щоправда, наскільки мені відомо, деякі код-конвеншени забороняють використання статичних імпортів, і тоді дублювання імені класу в назві відповідного фекторі-метода справді виглядає жахливо (+ синтаксичне підсвічування статично імпортованих методів читається не так зручно, як підсвічування окремо назви класу і назви його метода).

LinkedHashSet.of із запропонованого JEP 269 має свій аналог в Google Guava під виглядом newLinkedHashSet(),
А когда добавят NewLinkedHashSet (или например CoolConcurrentSet)? А если у этого нового класса будет конструктор основанный на каком-то специфическом классе, то у вас ваше собрание методов должно знать о каком-то специфичном классе который нужен только в одном конкретном случае.

Так Sets же із Guava покриває лише основні реалізації і спроектований лише для того, щоби найбільш використовувані сети можна було наповнювати зручним способом (а не використовувати той же double brace initializer), і змусити Java 6- компілятор вивести типи подібно до diamond-operator в Java 7. Якщо CoolConcurrentSet заслужить такої поваги — можливо, й потрапить туди. Хоча навіщо, якщо міг би існувати static-import-friendly CoolConcurrentSet.coolConcurrentSet(...).

щоби найбільш використовувані
От только при разработке платформы задача стоит не только покрыть наиболее используемые, но и сделать консистентное АПИ. Помимо того, на данный момент, таких методов будет по 7 штук на класс (например см cr.openjdk.java.net/...util/ArrayList.html#of-T )
навіщо, якщо міг би існувати static-import-friendly CoolConcurrentSet.coolConcurrentSet(...).
Еще раз:
В нашем случае же мы имеем порождающие статик методы, класс является их неотемлимой частью.
Выбор где-то такой: Или неудобно использовать со статик импортами, или неудобно использовать как метод класса. Кто-то один будет в проигрыше :) А теперь печальная часть: есть много людей (называющих себя джава программистами) которые не в курсе о существовании статик импортов.
UPD.
Помимо того статик импорты так же подвержены коллизиям:
Пример который причиняет мне боль docs.mockito.googlecode.com/...html#any(java.lang.Class и hamcrest.org/...html#any(java.lang.Class
То есть потенциально “новое АПИ” будет конфликтовать по крайней мере с гуавой, есть подозрение что совпадение имен могло стать причиной появления там класса docs.guava-libraries.googlecode.com/...mon/base/MoreObjects.html

Ми, по ходу, говоримо дещо про різні речі. Я лише кажу, що статичні імпорти унікально іменованих методів справді зручні у використанні, хоча і мають свої недоліки. Залишимо це справою звички.

підкажіть, чому дабл брейс — моветон?

Я не казав, що double brace initializer — моветон, але справді вважаю, що він таким є, оскільки використовується для імітації деякої поведінки, яка доступна, наприклад, в C# (Collection initializers), або може бути досягнута тими ж фекторі-методами чи іншим зручним API (включно з builder-патерном). Крім того, механізм double brace initializer не працює із класами, які оголошені final-класами, оскільки сам вимагає породження анонімного класу лише для сурогатної ініціалізації об’єкта, у якого просто немає зручного API, яке може навіть бути ефективнішим, ніж послідовні операції над об’єктом. Крім того, у деяких випадках, створення таких класів інколи провокує помилки, які важко відслідкувати (наприклад, при серіалізації сам стикався з таким у Google GSON).

з усім згоден. Стало цікаво, а можна детальніший приклад коли важко відслідкувати помилку в даблбрейс?

На жаль, не можу демонструвати реальний приклад, і випадок з Google GSON у мене вже давно був. Проте, наскільки я пам’ятаю, тоді я завтикав щось із тайп-адаптерами чи тайп-токенами, і зав’язався на конкретний клас ArrayList. Не подумавши/забувши/не знаючи наслідків, об’єкт вирішив ініціалізувати через double brace initializer. Відповідно, прямий маппінг для об’єкта, породженого таким чином класу, не працював. Щось таке.

підкажіть, чому дабл брейс — моветон?
В статье по ссылке это как раз и описано :)

+1.
Имеющий уши — да увидит!

Подписаться на комментарии