Comments 43
При чём здесь разработчики? Речь о заказчиках. А связано это, как правило, с большим объёмом легаси кода. Ну, такова вот жизнь…
Да не в этом дело. Заказчики. Новое ПО должно проходить серьёзный дорогостоящий аудит и кучу согласований. Зачем им это, если у них 15 лет всё работает как часы? Вы только представьте себе, что на продавливание новой версии явы у вас уйдёт год. Приблизительно. Может больше. За этт время выйдет 15 апдейтов и ещё более новая версия.
Повторяю. У них 15 лет система работает. Зачем менять? Потому что у кого-то зачесалось? Ну, пусть у кого зачесалось, оплатит эти работы. Делов-то. И, таки, да, шестой эксплорер тоже вполне может использоваться. Вы помните сколько лет после официальной "смерти" полуось использовалась в банкоматах? А может ещё где-то и осталась…
БОльшая часть энтерпрайзного софта не торчит наружу в понимании пхп-уеб-разработки, а безопасность там обеспечивается другими средствами.
А также обратите внимание на то, что я писал здесь. Если для вашего 15-летного приложения перечисленное действительно не важно — то пусть себе работает как есть. Главное понимание рисков и упущенных возможностей.
Повторяю. Разработчики здесь не при чём. Вообще.
Повторяю. В большой корпорации вопрос переезда на новую версию может занимать год и более. И это не просто написал бумажку и оно случилось (пусть и через год), это значит целый год вам нужно будет обоснованно доказывать с цифрами в руках неотложную необходимость всего этого. Год нервотрёпки и километровых переписок в которые вовлечены десятки человек. Зачем? Чтобы что? Чтобы там цифирька в версии сменилась?
Повторяю, "живой" проект — это вовсе не обязательно страничка с котиками и бложик в интернете. В "кровавом энтерпрайзе" 99% разработок не торчат наружу ни одним концом.
Добавляю, если заказчик упрётся в производительность, то он сам к вам придёт и сам всё сделает с версиями и апгрейдами.
Упущенная возможность? И что там упущено? Если вместо лямбд в приложении обычные анонимные классы — всё пропало, всё упущено? Смешно.
Риски? Это, скорее, с новыми версиями риски. У системы, которая 15 лет исправно работает риски известны более, чем хорошо.
Я могу себе представить аудит и безопасников более серьезных, чем банковские, но согласитесь, это все же не слишком типично )))
Попросят обновить чтобы что? Чтобы то, что стабильно и безопасно работало все 15 лет перешло в непонятное состояние, которое надо тестировать заново? Ну, должна же быть какая-то причина так сделать? Если была исправлена уязвимость, позволяющая организовать атаку на конкретную систему — да, это причина. А просто потому, что это более хипстерская версия — не, не покатит.
Ну т.е. я сформулирую еще раз — я никогда не видел, чтобы миграция на новую версию Java (или скажем Linux) тормозилась согласованиями. Как правило она тормозится потому, что это работа, и не маленькая. Как сама миграция, так и регрессионное тестирование на новой версии. Возможно я просто никогда не сталкивался с реальным аудитом.
Я не знаю в чём тут дело, но, одно время, когда часто названивали хантеры из люксофта и я на последующих собеседованиях спрашивал про стек технологий, я не помню случая, когда говорили про что-то свежее шестой явы. Может быть что-то изменилось, но ещё год назад было так. Ну, вот такова реальность. Про апдейты безопасности я уже говорил, большинство энтерпрайзного софта не торчит наружу и безопасность там обеспечивается другими мерами.
Тем не менее, я не видел, чтобы кто-то был против обновления. Даже если известные дырки в Java вас не коснулись — кто вам гарантирует, что завтра не найдут еще одну, которая коснется? При том что Java 7 уже два года как перестала поддерживаться — ну и кто эту дырку в Java 6 будет закрывать, если что? Это риск, и его все как правило понимают. Но все все равно упирается в трудозатраты.
В Jigsaw реализованы только структура пакета, проверка прав доступа во время компиляции и загрузки классов. При этом непосредственно инициация загрузки модуля и горячая замена будет возможна только через сторонние средства.
Jigsaw не исключает использование OSGi.А я такого и не утверждал.
Речь о том, что для многих сценариев того, что будет в Java 9 — достаточно.
Единственный пока положительный результат финализации JPMS — модуляризация JDK. За счет существенного усложнения всей модульной системы, поскольку модульность пришлось впиливать задним числом.
Это при всем том, что аналогичные концепции детально проработаны и реализованы в OSGi с незапамятных времен, а Enterprise OSGi существуют уже лет пять.
Модуляризация чего? Вашего приложения? Так оно и так состоит из либо EAR/WAR/JAR, которые вполне себе модули, либо из OSGI бандлов, которые тоже модули.
Контейнера? А зачем? Чтобы выпилить JTA, и собрать TomEE поменьше размером?
Вы можете реальные потребности озвучить?
EAR/WAR/JAR — это такая смешная модульность. В совокупности с иерархичными загрузчиками классов любой залетевший в нее дятел ведет к краху всего приложения. Начинать какой-то holy war не хочу, ничтоже сумнящиеся могут оценить количество вопросов на SO по [java-ee] + [classcastexception].
PS
У меня нет проблем с закрытием моих реальных потребностей. Это либо OSGi-контейнер, либо EAB/WAB в нормальном Java EE сервере вроде Websphere Liberty. Просто тот кровавый enterprise, в котором живет Java EE, привык следовать стандартам. Отсюда частая невозможность выбирать технологический стэк. OSGi — это не стандарт в мире Java EE и никогда им не будет. Но лично у меня нет сомнений, что JPMS пошагает в Java EE.
ClassCastException? Ну так эта… как бы это помягче… тут недавно была статья на хабре, где автор предлагал положить зависимости в lib/ext. Ну вы меня поняли? Если постараться — можно сломать все что угодно. Это не довод в общем случае.
Иерархия класс лоадеров в JavaEE требует минимального применения мозгов, причем (к большому сожалению) — включая знания о конкретном контейнере (и версии JavaEE тоже).
OSGi лежит внутри у многих вменяемых контейнеров, так что считать его «нестандартным» по мне так даже как-то странно. Всем кому он нужен, и кому его не хватает — он доступен как дополнение.
Скажем так — чтобы не обобщать зря: я просто никогда не видел такого кровавого энтерпрайза, как вы описываете. Вот смотрите — я в этом самом кровавом уже 12 лет с хвостиком. Где-то с 2009 мне попадается разработка на OSGI, причем раньше — голый Equinox, значительно хуже, чем это можно делать сейчас. А сейчас ни мне, ни в соседних проектах вообще никто слова не скажет, если я прикручу куда-то karaf, там где его еще нет.
Просто много куда дотянулись контрибьюторы, которым было не лень настроить мавеновский плагин org.apache.felix:maven-bundle-plugin для запуска bnd.
Там, конечно, всё равно надо писать кусок OSGi-specific конфигурации (Import-Package, DynamicImport-Package, Export-Package, Bundle-Activator, Embed-Dependency), но с bnd оно куда проще, чем то, что было раньше.
install wrap:mvn:groupId/artifactId/version
и все уже работает. Нет манифеста? Ну значит все экспортируется. Для случаев commons-lang этого более чем достаточно. Внутри у него видимо bnd.
файлы с расширением JAR (Java ARchive) ‒ обыкновенный ZIP-архив
Не совсем корректно. Там ещё есть специальный magic 0xcafe в первой zip entry и ограничены допустимые виды сжатия.
Замените слово «библиотека» на «наше приложение», разбейте приложение на модули — и вы получите возможность деплоить в том числе и в прод среди бела дня, по мере готовности. Т.е. вы поставили новую версию своего приложения, старую остановили (а возможно даже и не останавливали), запустили, проверили что все хорошо — и пошли пить чай.
У нас уже много лет оно живет в нескольких проектах вот таким вот образом. Сотни модулей, как минимум.
Кстати karaf сам по себе это не контейнер. У него внутри может быть Apache Felix либо Equinox.
А вот интересно, как вы все это пускаете в devmode? По стандартной схеме build-pack-deploy? Или плагин какой используете?
И мне кажется, не совсем аргументирована модульность приложения. Внутренне — да, имеет смысл для кода и тестов. Но с точки зрения деплоя лучше иметь единственный артефакт, нежели груду джарников.
Если необходима модульность, по-моему лучше будет разбить приложение на микросервисы и стартовать каждый в отдельной JVM/контейнере, как это делается сейчас. Единственный сценарий, который приходит на ум — платформа для деплоя различных приложений и микросервисов с разным циклом разработки. Что-то типа ESB или AppServer. Фактически там он в осносном и используется.
В моем случае это именно не приложение, а набор модулей, которые друг от друга сравнительно независимы. Каждый в отдельном контейнере? А ради чего? Ну т.е. это риторический вопрос, я и так знаю ради чего — я просто хочу заметить, что далеко не всегда то ради чего делают микросервисы, имеет место в жизни.
Да, согласен. В этом случае OSGi действительно помогает как единая платформа для деплоя, если имеется большое число более-менее независимых модулей.
Я сам не большой фанат контейнеров и микросервисов, поскольку в самой Java уже встроены неплохие средства виртуализации. Контейнеры сильно усложняют архитектуру и деплой и должны применяться только там, где это действительно необходимо, а не по зову моды. Также не имеет смысла искусственно дробить приложение на микросервисы, если у него единый функционал и цикл разработки.
Ну и кстати, вопрос: а чем все-таки лучше разбить на микросервисы? Ну вот чем лучше не разбивать, я попробую сформулировать:
* централизованная настройка (например, на 100 модулей у нас приходится порядка 20 разных баз данных, и в случае микросервисов мне бы пришлось настраивать url/логин
пароль в 20 разных непонятных местах, а так они в одном месте.
* централизованный мониторинг (одна копия JMX, и одна Hawtio консоль, откуда видно все).
* установка и управление из одного места
* один набор портов, торчащих наружу, для всех десятков web/rest сервисов. А точнее, один http порт и один https. И еще один набор сертификатов в одном месте.
* я выделил всем сервисам скажем 16Gb, и они там живут, потому что потребляют память как правило в разное время и по-разному. Не факт, что это хорошо, но тем не менее — 100 отдельным JVM пришлось бы тюнить параметры для каждой.
Кстати, для karaf артефакт — это в том числе и фича (см. выше с этом же посте), иначе говоря — такой xml с зависимостями.
Т.е. karaf просто умеет деплоить такие вот множества jar-ов, взаимосвязанные друг с другом. Например, вы можете написать, что вам нужна фича «spring-jms», например, которая установится вместе с вашим модулем, и притащит с собой транзитивные зависимости. Ну типа как maven, только в OSGI runtime. И делаются они, кстати, из pom.xml при помощи karaf maven plugin, не прилагая усилий.
Так что с точки зрения деплоя… для karaf это совершенно пофиг.
Модульные приложения на Java. Как?