Очень неспешный переход на Java 11 и основные выводы
В конце октября Oracle's Java Magazine и Synk опубликовали отличный доклад об экосистеме JVM. В ходе исследования было опрошено более 10000 разработчиков по всему миру относительно их выбора языков, платформ, инструментов, процессов и приложений JVM.
Ранее Zeroturnaround и JRebel выпускали подобные отчеты в прошлые годы. Eclipse Foundation также завершил исследование Java EE ранее в этом году. Исследования такого типа всегда в какой-то мере бывают предвзятыми, но при этом они дают достаточно хорошее представление о сообществе разработчиков.
В нашем случае этот отчет обеспечивает отличный снепшот и пищу для размышлений в части инструментов, которые используют разработчики Java. Определённо стоит прочитать его полностью. Вот некоторые самые интересные выводы.
Java 8 – доминирующая платформа
79% разработчиков Java разработчиков используют Java 8 в качестве основной платформы в продакшн, в то время как 8% используют Java 9 и 10. Кажется, что разработчики Java наконец-то отказываются от Java 7 (9%). Также интересно наблюдать, что примерно половина из опрошенных разработчиков, не использующих Java 8, используют более поздние версии (по 4% на 9 и 10).
Какую версию Java SE вы используете в продакшн для основного приложения?
Поскольку Java 11 является самой новой версией JDK, возникает вопрос: почему разработчики не переходят на более новые версии? Ответ, очевидно, кроется в новых циклах выхода релизов.
Релизные циклы
Когда Java 9 была выпущена ещё в 2017, многие беспокоились о том, какое влияние на развитие разработки окажут изменения как в архитектуре, так и в цикле выпусков релизов, который, как известно, предоставляет нам теперь новую версию каждые 6 месяцев.
«Я считаю, новый цикл является результатом многих лет медленных, осторожных и, вероятно, крайне затянутых релизных циклов, которые подвергались слишком большой критике из-за того, что важные или значимые новые функции не были выпущены в приемлемые сроки, — говорит Duncan Brown, технический директор Prometheus Software и региональный руководитель DZone, — Практически возникает такое чувство, что новый цикл как будто бы с избытком компенсирует то время и слишком далеко ушёл в другом направлении.»
На вопрос, как бы они отреагировали на новый цикл релизов, 30% опрошенных сказали, что они остановили бы выбор на системе «релиз за релизом», а 34% сообщили, что они бы предпочли выпуски с долгосрочной поддержкой (LTS), к которым относятся Java 7, 8 и 11.
Помимо комментариев по поводу цикла выпуска, D.Brown также сообщил:
“В век непрерывной интеграции и доставки ПО (CI/CD) и, потратив столько времени на релизы с важным функционалом и планированием, Oracle как будто бы в реальности не осознаёт, сколько на самом деле должен длиться приемлемый, более быстрый цикл релизов.“
В целом исследование показывает, что только 1 из 10 разработчиков хочет работать с самой последней версией JDK.
IntelliJ доказывает, что разработчики готовы платить за IDE
Многие разработчики работали с open-source инструментами и IDE для Java в течение длительного времени. Open-source заставил продавцов инструментов прилагать большие усилия, чтобы продавать IDE разработчикам. Следовательно, выглядит довольно неожиданно, что 32% разработчиков Java платят за IntelliJ IDEA. Это очень близко к аналогичной цифре — 38%, которые используют (бесплатный!) Eclipse. IntelliJ можно поздравить за то, что доказали, что разработчики согласны платить за их IDE!
В целом, согласно исследованию IntelliJ IDEA (45%) и Eclipse IDE (38%) были двумя ключевыми платформами IDE. Это не удивительно, поскольку и многие другие исследования показали, что IntelliJ опережает Eclipse два последних года. Apache NetBeans занял третье место, набрав 11%.
Gradle не лишил Maven трона
Несколько лет тому назад Gradle был «новым ребенком в инструментах сборки». Казалось, что импульс, с которым Gradle начал развиваться, заставит его превзойти признанного короля, Maven. Однако оказалось, что рост Gradle замедлился. Maven используют 60% разработчиков, а Gradle только 19%. Иногда действительно сложно заменить существующую технологию инфраструктуры. Небольшое смещение в пользу Gradle за последние годы достигнуто благодаря новой поддержке им Kotlin.
Какой инструмент для сборки вы используете в основном проекте?
GitHub не является королем репозиториев кода
В большинстве, а, возможно, и во всех open-source проектах используется GitHub. Поэтому несколько неожиданно, что на вопрос «Какой репозиторий для кода вы используете в основном проекте?» в качестве ответов Bitbucket и GitHub набрали по 25%, а на втором месте рядом с ними расположился GitLab (20%). Ответы включают как частные, так и публичные репозитории, поэтому результаты не являются чем-то специфичным для open-source. Это показывает, что у Bitbucket и GitLab дела идут действительно хорошо. Хорошо, что у GitHub есть серьёзная конкуренция.
Какой репозиторий вы используете в основном проекте?
Циклы выпуска программного обеспечения являются короткими
Трудно найти исследование, в котором бы спрашивали: “Как часто вы выпускаете новую версию вашего кода?” Следовательно, было интересно найти ответ в этом исследовании. Весьма неожиданные и внушительные 72% опрошенных заявляют, что они выпускают код по меньшей мере один раз в месяц. Гибкая разработка и DevOps определённо благотворно сказываются на уменьшении циклов релизов.
Как часто вы выпускаете новые версии своего кода?
+БОНУС(!)
А вы знаете, как часто вы релизите свой новый код?
Java EE и другое
Помимо вопросов, конкретно касающихся версий JDK, в рамках исследования также задавали вопросы о Java EE и многие другие.
В докладе указано, что 4 из 10 разработчиков не используют Java EE для своих основных приложений. Java EE 7 до сих пор остаётся наиболее востребованной версией (27%), однако Java EE 8 не сильно отстаёт (22%). Релиз Java EE 8 состоялся в сентябре 2017 года, поэтому выглядит весьма многообещающе, что спустя всего год эта версия стала почти самой популярной.
Какую версию Java EE вы используете для основного приложения?
Ну и конечно, стоит позаботиться и о тех 2%, кто борется за J2EE – версию, последний релиз которой был в 2003 году ;)
Оригиналы статей можно найти здесь и здесь.