×Закрыть

Java дайджест #9

Java дайджест #9

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

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

Light-Weight JSON API дропнули из JDK 9. Есть мнение, что Jigsaw может поломать IDE. И больше информации об изменениях, связанных с JDK 9, произошедших за последние месяцы.

Вышел Android Studio 1.0 на базе платформы IntelliJ IDEA. И всем Android-разработчикам рекомендуют переходить на нее.

JetBrains выпустила Xodus — мегакрутую (по их словам) встраиваемую БД. Обновила TeamCity до версии 9.0 (если кто не знает, то это лучший CI-сервер).

И Upsource — тул для ревью кода. Сразу же немного яду: он не работает с svn:externals, и моя ненавидеть ихняя за это.

Вышел Spring Boot 1.2.0. Если кому-то нечем заняться и есть желание познакомиться со Spring Boot, можете поучаствовать в конкурсе.

Вышли Hibernate Search 5.0.0.Final и Hibernate OGM 4.1 Final (как я понял, это первый релиз). Теперь благодаря OGM вы сможете работать с вашей NoSQL БД через Hibernate! Разве это не то, о чем вы всегда мечтали?

Вышел JUnit 4.12

Вышел Groovy 2.3.9 и первый релиз — кандидат для 2.4.

Вышел Restlet 2.3

Вышло минорное обновление RxJava 1.0.4. Так же вышел Reactive Streams v1.0.0.RC1

Догадываюсь, что всем пофиг, но всё же AsciidoctorJ появился в GVM.

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

Аннотации потихоньку превратились в месиво не слабее чем XML.

(!) Java Doesn’t Suck — You’re Just Using it Wrong Ожидать чего-то хорошего от статьи с таким названием не приходится, но в этой есть разумный посыл.

Интересная подборка Java-ресурсов.

(!) Invokedynamic 101

JVM Thread Pooling Trends. Обзор популярных способов работы с concurrency в Java-мире.

Сравнение разных способов компрессии данных.

(!) Текущее состояние проекта Valhalla.

Мысли про on heap и off heap.

Looking into the Java 9 Money and Currency API (JSR 354)

Кто помнит, сколько шлака вылезло при переименовании вендора Java с Sun на Oracle? Ох, представляю, какое веселое будет обновление на 9-ку.

Обсуждение на HN про то, как можно налажать, не читая доку.

Latest Jackson integration improvements in Spring. Не знаю, почему это важно и зачем я это сюда добавил, но, возможно, кому-то будет интересно.

Avatar 2.0 — where to next? Еще одно напоминание о Nashorn. Очень обидно, что эта штука не выстреливает. Кстати, в 8u40 обещают улучшения для Nashorn.

Немного про альтернативные JVM-языки.

Топ 5 событий 2014 и предсказания на 2015-й. Слабовато, но, к сожалению, не нашел варианта лучше. Можете оставлять свои мысли по этому вопросу в комментариях.

Для тех, кто не следит за ThoughtWorks Radar.

Список встреч JUG.ua за 2014 год.

(!) И под конец (года) интересное и короткое интервью с Todd Montgomery.

Разное

googlei18n/libphonenumber — библиотека для работы с телефонными номерами (не только в Java).


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


← Предыдущий выпуск: Java дайджест #8
Следующий выпуск: Java дайджест #10: что будет с Groovy, Java 8 все ближе и ближе

LinkedIn

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

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

А як щодо асинхронного API до JetBrains Xodus?

Что именно вы подразумеваете под «асинхронным API»?

Теперь благодаря OGM вы сможете работать с вашей NoSQL БД через Hibernate! Разве это не то, о чем вы всегда мечтали?

Лично я мечтаю о том, что Hibernate исчезнет с лица земли.

Точно! Тогда можно будет писать тонны г-кода. Кто за него платить-то будет?

Точно! Тогда можно будет писать тонны г-кода. Кто за него платить-то будет?
Не понял ни суть высказывания, ни то «вы за меня или за медведя».

Суть в том, чем же господин-автор комментария, собрался заменять Hibernate? Видимо, ему платят за тот самый код

Суть в том, чем же господин-автор комментария, собрался заменять Hibernate?
Как вариант ebean, mybatis, jooq, __jdbc__. Или использовать nosql БД. Еще есть такой список en.wikipedia.org/...g_software#Java
Но тут важно понимать задачу с которой работаете. Есть задачи для которых хибер таки хорош (сохранение среднего мутного дерева объектов), есть задачи для которых он очень тяжелый (те где модели простые), есть задачи где он создает много гемору (работа с большими объемами данных и обширными связями).
.
Момент № 2. Чисто с философской точки зрения хибер — это таки говнокод, ибо примешивает фрейворк к вашей бизнес-логике; а если вы все равно поместили его за DAO, то от него пользы не так уж и много (вполне заменяется jdbc + небольшой набор утилит)

Мечтатель мечтает покончить со всеми ORM сразу. Не мешайте ему.

Беда любой (возможно за исключением mybatis, но он не совсем ORM) ORM в том, что вместо программирования доменной модели или persistence layer мы занимаемся программированием ORM. Ну и разумеется эпичные танцы вокруг дерева объектов, которое не совсем дерево на самом деле, а просто куски дерева подгруженные во время «живой» сессии и нужно помнить, что конкретно ты подгружал иначе... LIE.
Заменить Hibernate можно jdbc. И, в целом, это сделать совсем не сложно, если следуя опыту светлой стороны использовать в качестве модели DTO, желательно максимально плоские. Если все-таки нужно дерево объектов, то java.sql.ResultSet парситься в дерево довольно легко, эту обязанность можно возложить на сами объекты модели (чем и занимаеться mybatis по большому счету). Так что количество гонокода прямо пропорционально кривизне извилин архитектора.
С другой стороны выбросить Hibernate из существующего проекта очень сложно. Но это не означает что он хорош.
P.S. Да, я тот самый архитектор который заюзал хибер в проекте с «большим объемом данных и обширными связями». Я тут точно знаю о чем говорю :)

А вас ORM не устраивает или JPA? Или все же конкретно Hibernate? Если Hibernate то есть неплохая альтернатива в лице EclipseLink. А по поводу ORM и JPA не могу ничего хорошего предложить :(

Точно! Тогда можно будет писать тонны г-кода. Кто за него платить-то будет?
Код доменной модели зависимый от технлогии хранения данных это и есть самый настоящий говнокод.

Кто же мешает делать модель независимой. Способ хранения обїектов модели — личное дело каждого. Если претензия к модели, то при чем здесь Хибер. В CQRS и Axon вообще агрегаті, но оно не мешает персистить в базу через ORM

Кто же мешает делать модель независимой

Недостаток квалификации, костность, чсв
В CQRS и Axon вообще агрегаті, но оно не мешает персистить в базу через ORM
Я смотрю ты не видишь леса за деревьями.
Domain и application layer должны быть независимы от фремворка. Хранение данных это деталь реализации. Если ты поставил JPA аннотации на свою модель, то она уже зависима от persistence слоя. И если бы ты хоть одно более-менее сложное приложение написал , то знал бы что согласно domain-driven принципам домен и логика приложения (реализация use-case’ов) должны независимы от какого-либо слоя. Это persistence слой должен быть зависим от них.

Слышу звон, да не знаю где он, как говориться.

p.s.

Способ хранения обїектов модели — личное дело каждого
Никто не мешает сделать домен независимым от hibernate, но тогда придеться делать преобразования между доменом и ентитями, вследствии чего плюсы хибернейта станут слишком незначительными.

С чего это вдруг код без Hibernate — говнокод? Смотря как писать.

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