OSGi, Java Modularity и Jigsaw

Question

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

На самом деле это выглядит довольно круто,поэтому я хотел бы начать с заявления (для протокола), что я не против OSGi ни в каком отношении, и при этом это не какой-то вопрос «OSGi-bashing».

В концеСегодня кажется, что OSGi - по существу - обратилась к JSR 277 в модульности Java, которая признала, что существуют недостатки в спецификации файла 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.Это потому, что я испытываю только огромное уважение к своим коллегам-SOER, и я ищу ответ на уровне архитектуры от некоторых «Богов ИТ», которых я вижу здесь каждый день.

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

int x = 9;

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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