OSGi, модульность Java и Jigsaw
OSGi было просто какое-то модное слово, которое я продолжал видеть, появляясь снова и снова, и поэтому я, наконец, отложил некоторое время, чтобы освежить его.
на самом деле это кажется довольно крутым материалом, поэтому я хотел бы начать с заявления (для записи), что я не анти-OSGi ни в каком отношении, и это не какой-то вопрос "OSGi-bashing".
в конце концов, кажется, что OSGi имеет - по существу-адресовано JSR 277 на модульности Java, которая признала, что есть недостатки с JAR спецификация файла, которая может привести к разрешению пространства имен и проблемам с загрузкой классов в некоторых угловых случаях. OSGi также делает много других действительно интересных вещей, но из того, что я могу установить, это его самая большая ничья (или одна из них).
для меня-как довольно новый (уже несколько лет) разработчик Java EE, это абсолютно ошеломляет, что мы находимся в 2011 году и в настоящее время живет в эпоху Java 7, и что эти проблемы с загрузкой классов все еще присутствуют; особенно в корпоративных средах, где один сервер приложений может иметь сотни банок на нем, причем многие из них зависят от разных версий друг друга и все работают (более или менее) одновременно.
мой вопрос:
насколько я заинтересован в OSGi, и насколько я хочу начать изучать его, чтобы увидеть, где/если это может быть полезно для моих проектов, У меня просто нет времени сидеть и изучать что-то настолько большое, по крайней мере сейчас.
так что же делать разработчикам не OSGi, когда возникают эти проблемы? что Java (Oracle/Sun/JCP) решения в настоящее время существуют, если таковые имеются? Почему Jigsaw был вырезан из J7? Насколько уверено сообщество, что Jigsaw будет реализован в следующем году в J8? Можно ли получить Jigsaw для вашего проекта, даже если он еще не является частью платформы Java?
Я думаю, что Я спрашиваю здесь-это сочетание паники, интриги и лицевого бальзама. Теперь, когда я наконец понял, что такое OSGi, я просто не "понимаю", как что-то вроде Jigsaw заняло 20+ лет, чтобы воплотиться в жизнь, а затем, как это могло быть консервировано из выпуска. это просто кажется фундаментальным.
и, как разработчик, мне также любопытно, каковы мои решения, без OSGi.
и Примечание: я знаю, что это не "чистый Программирование" - типа вопрос, но прежде чем некоторые из вас получат ваши носы согнуты из формы, я хотел бы заявить (опять же, для записи), что я намеренно поставил этот вопрос так. Это потому, что у меня нет ничего, кроме крайнего уважения к моим собратьям SOers, и я ищу ответ на архитектурном уровне от некоторых из "богов этого", которые я вижу здесь каждый день.
но, для тех из вас, кто абсолютно настаиваю что так вопрос будет поддерживаться с некоторым кодом сегмент:
int x = 9;
(спасибо всем, кто может взвесить этот OSGi/Jigsaw/classloader/namespace/JAR hell stuff!)
3 ответа:
сначала понять, что основным вариантом использования лобзика является modularise JRE непосредственно. В качестве вторичной цели он будет предлагать модульную систему, которая может использоваться другими библиотеками и приложениями Java.
моя позиция такова:что-то вроде Jigsaw, вероятно, необходим только для JRE, но это создаст гораздо больше проблем, чем он утверждает, чтобы решить, если используется другими библиотеками Java или приложениями.
JRE-это очень сложный и особый случай. Это более 12 годы и ужасный беспорядок, пронизанный циклами зависимостей и бессмысленными зависимостями. При этом используется примерно 9 млн. разработчики и наверное миллиарды работающих систем. Поэтому вы абсолютно не можете рефакторинг JRE, если этот рефакторинг создает критические изменения.
OSGi-это модульная система, которая помогает вам (или даже сил вы) создать программное обеспечение, которое является модульным. Вы не можете просто посыпать модульность поверх существующей модульной базой. Превращение немодульной кодовой базы в модульную неизбежно требует некоторого рефакторинга: перемещение классов в правильный пакет, замена прямого инстанцирования с использованием разобщенных сервисов и так далее.
Это затрудняет применение OSGi непосредственно к кодовой базе JRE, но у нас все еще есть требование разделить JRE на отдельные части или "модули", чтобы можно было доставлять сокращенные версии JRE.
поэтому я рассматривайте головоломки как своего рода"крайняя мера " чтобы сохранить код JRE живым, разделяя его. Это делает не помогите коду стать более модульным, и я убежден, что он действительно увеличит обслуживание, необходимое для развития любой библиотеки или приложения, которое его использует.
наконец: OSGi существует, тогда как Jigsaw еще не существует и может никогда не существовать. Сообщество OSGi имеет 12-летний опыт разработки модульных приложений. Если вы серьезно заинтересованный в разработке модульных приложений, OSGi является единственной игрой в городе.
Это просто, если вы хотите сделать реальную компонентную разработку на Java сегодня, то OSGi-единственная игра в городе.
на мой взгляд, Jigsaw-это комбинация компромисса того, что выполнимо в JDK и предыдущих плохих отношениях между SUN и ребятами OSGi. Возможно, он будет поставляться с Java 8, но мы должны подождать и посмотреть.
OSGi не является панацеей, если вы работаете в типичной корпоративной среде, и вам нужно будет ознакомиться с тем, как работает загрузка классов поскольку ряд известных библиотек (глядя на вас, Hibernate) сделал предположения о видимости класса, которые больше не действительны внутри OSGi.
Мне нравится OSGi, но я бы не стал пытаться модифицировать его в существующую систему. Я бы также взвесил плюсы и минусы с точки зрения разработки greenfield - я бы рекомендовал посмотреть на продукты Apache или Eclipse, которые упрощают жизнь для OSGi, а не делать все это самостоятельно.
Если вы не делаете OSGi, то вам не повезло, если вы пришли с системой, которая имеет зависимости от разных версий одной и той же библиотеки - все, что вы можете сделать, это попытаться избежать проблемы, хотя необходимость нескольких версий библиотеки кажется мне "запахом" архитектуры.
Мне нравится, что вы используете фразу "угловые случаи" для описания текущей ситуации.
есть недостатки в спецификации файла JAR, которые могут привести к разрешению пространства имен и проблемам с загрузкой классов в некоторых угловых случаях
во всяком случае, с тех пор много лет я интересовался инструментами и методами, которые поддерживают создание и, что еще лучше, обеспечивают выполнение кода, который является более чистым, более развязанным, более последовательным и более доступным, чем то, что наверное, был бы результат и без них. Испытательный дизайн и Junit были такой комбинацией.
потратив пару месяцев на перемещение значительной части нашей кодовой базы в OSGi, я бы сказал, что OSGi является еще лучшим инструментом в этом отношении. И это действительно достаточная причина для перехода на OSGi. В долгосрочной перспективе это сэкономит вам много денег.
и, в качестве бонуса, это даст вам возможность сделать много интересных вещей. Представьте себе, во время демонстрации, плавно обновление модуля аутентификации без потери трафика для поддержки OAuth ... это вдруг радость снова создавать вещи!