OSGi, модульность Java и головоломка

Так что по состоянию на вчерашнее утро я понятия не имел, что такое OSGi. OSGi было просто модным словом, которое я постоянно видел, и поэтому я наконец нашел время, чтобы освежить его в памяти.

На самом деле это кажется довольно крутым материалом, поэтому я хотел бы начать с заявления (для протокола), что я ни в коем случае не против OSGi, и это не какой-то вопрос, касающийся OSGi.

В конце концов, похоже, что OSGi - по сути - обратилась к JSR 277 на Java Modularity, который признал, что есть недостатки в JARспецификации файлов, которые могут привести к проблемам разрешения пространства имен и загрузки классов в определенных угловых случаях. OSGi также делает много других действительно интересных вещей, но, насколько я могу судить, это его самая большая привлекательность (или одна из них).

Для меня - как довольно нового (уже несколько лет) разработчика Java EE, совершенно ошеломляюще, что мы живем в 2011 году и живем в эпоху Java 7, и что эти проблемы с загрузкой классов все еще присутствуют; особенно в корпоративных средах, где на одном сервере приложений могут быть сотни файлов JAR, многие из которых зависят от разных версий друг друга и все работают (более или менее) одновременно.

Мой вопрос:

Как бы я ни интересовался OSGi и как бы я ни хотел начать изучать его, чтобы увидеть, где / может ли он быть полезен для моих проектов, у меня просто нет времени, чтобы сесть и изучить что-то такое большое, по крайней мере сейчас.

Так что же делать разработчикам, не связанным с OSGi, при возникновении этих проблем? Какие решения Java (Oracle / Sun / JCP) существуют в настоящее время, если таковые имеются? Почему Jigsaw вырезан из J7? Насколько уверено сообщество в том, что Jigsaw будет реализован в следующем году в J8? Можно ли получить Jigsaw для своего проекта, даже если он еще не является частью платформы Java?

Думаю, я спрашиваю здесь комбинацию паники, интриги и фейспалма. Теперь, когда я, наконец, понимаю, что такое OSGi, я просто не понимаю, как что-то вроде Jigsaw потребовалось более 20 лет, чтобы воплотить в жизнь свои плоды, и как это могло быть исключено из выпуска. Это просто кажется фундаментальным.

И как разработчику мне также любопытно, какие у меня решения без OSGi.

Также обратите внимание : я знаю, что это не вопрос типа " чистого программирования ", но прежде, чем некоторые из вас сделают носы изогнутыми, я хотел бы заявить (опять же для протокола), что я намеренно задаю этот вопрос ТАК. Это потому, что я не испытываю ничего, кроме крайнего уважения к своим товарищам по SO, и я ищу ответ на архитектурном уровне от некоторых «богов ИТ», которых я вижу здесь каждый день.

Но для тех из вас, кто абсолютно настаивает на том, чтобы вопрос SO был подкреплен некоторым сегментом кода:

int x = 9;

(Спасибо всем, кто может взвесить этот адский OSGi / Jigsaw / classloader / namespace / JAR!)

Сначала поймите, что основной вариант использования Jigsaw - модульное построение самой JRE. В качестве вторичной цели он предложит модульную систему, которая может использоваться другими библиотеками и приложениями Java.

Моя позиция заключается в том, что что- то вроде Jigsaw, вероятно, необходимо только для JRE, но это создаст гораздо больше проблем, чем может решить, если будет использоваться другими библиотеками или приложениями Java.

JRE - очень сложный и особый случай. Ему более 12 лет, и он представляет собой ужасный беспорядок, пронизанный циклами зависимостей и бессмысленными зависимостями. В то же время его используют около 9 миллионов разработчиков и, вероятно, миллиарды работающих систем. Поэтому вы абсолютно не можете рефакторинг JRE, если этот рефакторинг вызывает критические изменения.

OSGi - это модульная система, которая помогает (или даже заставляет ) создавать модульное программное обеспечение. Вы не можете просто добавить модульность к существующей немодульной кодовой базе. Превращение немодульной кодовой базы в модульную неизбежно требует некоторого рефакторинга: перемещения классов в правильный пакет, замены прямого создания экземпляров использованием разделенных служб и т. Д.

Это затрудняет применение OSGi непосредственно к кодовой базе JRE, но у нас все еще есть требование разделить JRE на отдельные части или «модули», чтобы можно было доставить сокращенные версии JRE.

Поэтому я рассматриваю Jigsaw как своего рода « крайнюю меру », позволяющую сохранить код JRE в рабочем состоянии при его разделении. Это не помогает коду стать более модульным, и я убежден, что на самом деле это увеличит объем обслуживания, необходимого для развития любой библиотеки или приложения, которое его использует.

Наконец: OSGi существует, тогда как Jigsaw еще не существует и, возможно, никогда не будет. Сообщество OSGi имеет 12-летний опыт разработки модульных приложений. Если вы серьезно заинтересованы в разработке модульных приложений, OSGi - единственная игра в городе.

Это просто: если вы хотите заниматься реальной компонентной разработкой на Java сегодня, тогда OSGi - единственная игра в городе.

На мой взгляд, Jigsaw - это комбинация компромисса того, что выполнимо в JDK, и предыдущих плохих отношений между SUN и разработчиками OSGi. Возможно, он будет поставляться с Java 8, но нам нужно подождать и посмотреть.

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

Мне нравится OSGi, но я бы не стал пытаться модернизировать его до существующей системы. Я бы также взвесил все «за» и «против» с точки зрения разработки с нуля - я бы рекомендовал взглянуть на продукты Apache или Eclipse, которые упрощают жизнь OSGi, а не делать все это самостоятельно.

Если вы не используете OSGi, то вам не повезло, если вы придумали систему, которая зависит от разных версий одной и той же библиотеки - все, что вы можете сделать, это попытаться избежать проблемы, хотя вам потребуется несколько версий одной и той же библиотеки. библиотека мне кажется архитектурным «запахом».

Мне нравится, что вы используете фразу «крайние случаи» для описания текущей ситуации.

в спецификации файла JAR есть недостатки, которые могут привести к проблемам с разрешением пространства имен и загрузкой классов в определенных случаях

Как бы то ни было, на протяжении многих лет меня интересовали инструменты и методы, которые поддерживают создание и, что еще лучше, обеспечивают соблюдение кода, который является более чистым, более разделенным, более связным и более удобным в обслуживании, чем то, что, вероятно, было бы результатом без них. Test Driven Design и Junit были такой комбинацией.

Потратив пару месяцев на перенос значительной части нашей кодовой базы на OSGi, я бы сказал, что OSGi - еще лучший инструмент в этом отношении. И это действительно достаточная причина для перехода на OSGi. В конечном итоге это сэкономит вам много денег.

И, как бонус, это даст вам возможность делать много крутых вещей. Представьте себе, во время демонстрации, плавное обновление модуля аутентификации без потери трафика для поддержки OAuth ... внезапно снова становится радостью создавать вещи!