Найбільша PHP конференція України, 1 червня: хто буде і чому варто відвідати?
×Закрыть

Java дайджест #40: Java 11, или Мы все умрем... снова

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

Java and money

(!) Кому не интересно читать все ссылки в этом разделе, просто идите сюда: adoptopenjdk.net

Несколько статей от Stephen Colebourne:

The future of Java and OpenJDK updates without Oracle support

Java Mission Control — Now serving OpenJDK binaries too!

Dudes and Dudettes, Things Just Got Better! от Marcus Hirt (лидер разработки JMC).

Обсуждение на ДОУ

Java Next

New Version of ByteBuddy Fully Supports Java 11

(!) Вышла Java 11

Proposed schedule for JDK 12

Entering the next phase of Project Valhalla

Value types, encapsulation, and uninitialized values

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

Spring Framework 5.1 goes GA

Spring Boot 2.0.5 и пока выходил это дайжест, еще и Spring Boot 2.0.6

(!) Introducing Spring Data JDBC

Вышел Javalin 2.0.0 и уже Javalin 2.3.0

(!) Вышел Flyway 5.2.0. Субъективно мне Flyway кажется более логичной и удобной системой миграции БД чем Liquibase. Но при этом второй вроде как более популярен. Отсюда вопрос: что вы используете для миграции БД и почему?

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

(!) Java release chains — Splitting features from security от Stephen Colebourne о том, как жить в условиях постоянно выходящих обновлений Java.

NetBeans Makes Progress at Apache. Да-да, не просто «еще жив», а еще и делает прогресс.

Decoding Clojure code, getting your feet wet. Интересный вариант для «расширения сознания».

JShell: A Comprehensive Guide to the Java REPL. Оказалось, что еще не все знают, что в джаве есть REPL.

JVM Ecosystem Report 2018

Разное

Arthas диагностик тул от ... Alibaba. У вас еще есть время забить на английский и начать учить китайский. И кстати, перед использованием проверьте настройку ваших фаерволов.


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


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

LinkedIn

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

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

Маловато новостей и статей, учитывая, что предыдущий дайджест выходил еще в июле

Spring data jdbc выглядит весьма интересно, часто хибернейты и прочие реализации jpa вообще не нужны, в тех же микросервисах часто оно вообще не надо и по идее можно при желании и с небольшим усилиями подменить на spring data jpa, если оно таки понадобится

Я использую Liquibase. Он лучше Flyway вот почему:
Его синтаксис xml позволяет каждому changeset прописать дополнительные атрибуты — надо ли его перезапускать при ошибке (или даже каждый раз), надо ли перезапустить при изменении и т.д. в Flyway всё это невозможно.

Слышал, что у flyway порядок выполнения файлов зависит от их имен. Те если есть 2 файла (fileNameA, fileNameB) с разными change set, первым выполнится файл fileNameA

Слышал, что у flyway порядок выполнения файлов зависит от их имен

И это не проблема с учетом того что имена файлов начинаются с VX__, где X — номер версии :)

Кмк это проблема, если достаточно много человек комитят в репозиторий с flyway

надо ли его перезапускать при ошибке (или даже каждый раз), надо ли перезапустить при изменении

Могли бы вы привести примеры того когда это действительно надо? Как-то хотелось бы не получать ошибок при миграции продакшн БД :)

У ликвибейса очень много функциональности, а у флайвея как раз достаточно функциональности (которая покрывает основные сценарии). За счет своей простоты флайвей оставляет меньше места для ошибки.

Лично для меня наиболее полезная фича ликвибейса — это как раз ХМЛ синтаксис, который помогает когда нужно выполнять простые миграции на разных СУБД.

Легко.
Допустим, был changeset «add NotNull constaint» для колонки X. И он успешно прошёл на всех дев- и тест- средах. А при установке на стэджинг (а может, и в продакшн) он упал, потому что там нашлась запись, в которой X = null. А на всех дев- и тест-средах не было такой записи.

Ну вот как теперь в Flyway разрулить эту ситуацию? Никак. Ручками в базе придётся исправлять.
А в LiquiBase как раз и можно прописать все эти атрибуты «runOnChange», условия и т.д.

Здесь я рассказывал про плюшки LiquiBase: www.youtube.com/watch?v=A3XoEp_3V88

P.S. XML синтаксис для меня как раз спорная фича. Таких проектов, где нужна была бы поддержка нескольких баз, крайне мало. А BD девелоперам, которые уже знают SQL, проще продолжать писать на SQL. Учить новый язык для них — лишняя обуза.

А при установке на стэджинг (а может, и в продакшн) он упал, потому что там нашлась запись, в которой X = null.

Этот случай я включил в

Как-то хотелось бы не получать ошибок при миграции продакшн БД

Если мы знали что в поле могут быть налы, то почему не указали дефолтное значение?
Если не знали, то проблема не в миграции, а в том что наш код теперь считает что налов быть не может.
Тут не очень понятно как помогает runOnChange. Типа выгребли проблему и потом дописали дефолтное значение?
Я видосик смотрел пару лет назад, надо будет таки пересмотреть.

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

Как только вы начали использовать какую-то H2/HSQL для тестов у вас сразу появляется 2 СУБД :)

Ну как. Нет, мы не знали, что могут быть null. Мы думали, что их не должно быть. Их и не было в тестовой среде. А вот в продакшине (куда у нас доступа нет, сами проверить не могли) они оказались. Какие-нибудь дурацкие записи десятилетней давности.

runOnChange помогает так, что на тест-средах, где этот changeset уже пробежал, он второй раз запускаться не будет. А на проде запустится. А до этого changeset мы добавим другой — который, скажем, удаляет эти левые записи. Или прописывает туда ненулевое значение.

P.S. Да, именно из-за H2 мы и используем XML синтаксис LiquiBase. Но так мало кто делает. Многие, например, считают, что тесты надо запускать на той же базе, что и приложение. Например, докер сейчас решает эту проблему.

Юзайте testcontainers вместо h2/hsql и будет вам счастье))

Юзайте testcontainers вместо h2/hsql

А что там с перформансом? Тесконтейнерс вроде как докер имеджи стартуют. Даже если нет, то явно не кусок кода в той же джвм.

да, работает через докер, но тесты гоняются достаточно быстро и гоняются на реальной базе, а не на непонятной H2.

но тесты гоняются достаточно быстро

Достаточно ... по сравнению с Х2 во сколько раз улучшение/ухудшение? Если у кого есть ссылки на хоть какие-то замеры или опыт, очень интересно было бы посмотреть.

и гоняются на реальной базе, а не на непонятной H2.

Вполне понятный код, как по мне. Что именно вы не поняли в Х2 :)
Проблема в том что «реальной» эта база будет только в случаее если у вас все в докере и используется ровно тот же имедж что и в продакшене.
Если нет, то из «реальности» мы вычитаем отличия железа, отличия сетевой инфраструктуры, отличие конфигурации.

Есть разные уровни изоляции от внешних зависимостей и разные виды/уровни тестов. Бывают случаи когда тестконтейнерс — самое оно, например когда у вас не сложная (в плане конфигурирования каждого сервиса) докеризированная инфраструктура.
Бывают случаи когда вы не контроллируете билд-агент и запустить там докер будет проблематично.
Бывают случаи когда у вас очень простая БД и Х2 достаточно с головой.
Бывают случаи когда сетап данных для тестов настолько сложный и тежеловесный что проще подныть БД на реальном сервере и тесты будут ходить туда (жертвуя изоляцией).

база в докере поднимается один раз перед тестами, качается один раз образ (да, занимает время), потом он переиспользуется.
Бывают разные ситуации, это понятно, но тестировать код на той же базе, что на проде и на H2 это не одно и тоже.
Если есть возможность запускать тесты на реальной базе, то использование H2 можно объяснить только историческим наследием.

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