OSGi, модульность Java и Jigsaw

Итак, по вчерашнему утру я понятия не имел, что такое 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?

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

И, как разработчик, мне также интересно узнать, что такое мои решения, без OSGi.

Кроме того, Примечание: Я знаю, что это не вопрос типа "чистого программирования", но прежде чем некоторые из вас согнут из-за формы, я хотел бы указать (опять же, для запись), что я намеренно поставил этот вопрос на СО. Это потому, что у меня нет ничего, кроме самого уважения к моим сослуживцам, и я ищу архитектурный ответ от некоторых из "Богов ИТ", которые я вижу каждый день здесь.

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

int x = 9;

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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