OSGi, Java Modularity и 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?

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

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

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

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

int x = 9;

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

93 голоса | спросил IAmYourFaja 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 21 Sep 2011 14:54:28 +0400 2011, 14:54:28

3 ответа


0

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

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

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

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

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

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

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

ответил Neil Bartlett 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 21 Sep 2011 17:06:47 +0400 2011, 17:06:47
0

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

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

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

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

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

ответил SteveD 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 21 Sep 2011 15:54:12 +0400 2011, 15:54:12
0

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

  

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

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

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

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

ответил forty-two 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 22 Sep 2011 00:27:15 +0400 2011, 00:27:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132