Почему Sun изобретает другую модульную систему, когда все стандартизировали OSGi?

Question

Sun прилагает много усилий для модульной JDK в форме Jigsaw , а также намекает на то, что этот формат должен быть предпочтительным для других разработчиков Java. Единственный известный игрок, который использует это, - NetBeans (и производные приложения).

С другой стороны, отрасль стандартизировалась вокруг OSGi, причем все основные поставщики приложений основывали свои среды выполнения на модульной платформе, даже собственную Sun Glassfish. Существует даже порт NetBeans для использования OSGi в качестве модульной системы вместо собственных модулей NetBeans. Даже Maven работает над тем, чтобы стать OSGi Runtime.

Это просто NIH, лицензирование или другая причина?

Answer 1

Цитирование http://blogs.oracle.com/mr/entry/jigsaw:

OSGi вообще не интегрируется с Язык Java, однако, был построен на платформе Java SE, а чем изнутри.

Эта последняя проблема может быть исправлена. солнце планирует теперь работать напрямую с OSGi Alliance, так что будущая версия OSGi Framework может полностью использовать функции JSR 294 и тем самым добиться более тесной интеграции с языком.

(...)

Если и когда будущая версия Java SE Platform включает в себя специальный модульная система, то Sun обеспечит означает перенести Jigsaw модули до этот стандарт. Тем временем мы будем активно искать пути, в которых взаимодействовать с другим модулем системы, и в частности с OSGi.

Answer 2

Логическое обоснование проекта Jigsaw и его связь с OSGi были изложены командой Jigsaw в Java Posse Podcast 259 .

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

По крайней мере, это мое взятие из того, что я прочитал .

Answer 3

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

Смотрите эту запись в блоге

Answer 4

Ознакомьтесь с интервью JavaPosse с Марком Рейнхольдом на эту тему.

Answer 5

Одна функция отсутствует в OSGi . не поддерживает модули, которые являются подмножествами пакетов . экспорт выполняется на уровне пакета .

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

Однако с годами этот стиль развития может привести к неожиданному соединения между API - и между их реализации - ведущие в свою очередь увеличить время запуска и память след. Тривиальная командная строка Программа «Здравствуй, мир!», Например, сейчас загружает и инициализирует более 300 отдельные занятия, около 100мс на недавнем настольном компьютере, несмотря на еще больше героических инженерных усилий такие как обмен данными класса. Ситуация еще хуже, конечно, для больших приложений.

Редактировать: я был неправильно . OSGi поддерживает разделенные пакеты .