Пакеты разделения в плоскости Java

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

Вы спрашиваете, потому что рассматриваемый пакет является Вашим, не сторонний код?

Легким примером было бы веб-приложение с сервисом и слоями персистентности как отдельные пакеты OSGi. Интерфейсы персистентности должны были бы быть совместно использованы обоими пакетами.

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

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

Разделение пакетов через банки, вероятно, не является прекрасной идеей. Я предлагаю делать все пакеты в банках изолированными (помещенный "Sealed: true" в основном разделе декларации). Изолированные пакеты не могут быть разделены между банками.

В случае OSGi рассматривают классы с тем же именем пакета, но другим загрузчиком класса, как будто они находятся в различных пакетах.

Откуда берутся разделенные пакеты

Разделенные пакеты (в OSGi) возникают, когда используется заголовок манифеста Require-Bundle (как я полагаю, в манифестах Eclipse ). Require-Bundle называет другие пакеты, которые используются для поиска классов (если пакет не Import ). Поиск происходит до поиска собственного пути к классам пакетов. Это позволяет загружать классы для одного пакета из экспорта нескольких пакетов (возможно, разных jar-файлов).

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

• если класс (в пакете) предоставляется более чем одним пакетом, то вы в беде.

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

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

Что происходит в «стандартной Java»

В стандартной Java, без причудливых загрузчиков классов, у вас есть путь к классам, и порядок поиска классов для загрузки в банках (и каталогах) фиксирован и четко определен: что Вы получаете то, что получаете. (Но тогда мы отказываемся от управляемой модульности.)

Конечно, у вас могут быть разделенные пакеты - на самом деле это довольно распространено - и это показатель плохой модульности. Симптомами могут быть неясные ошибки времени компиляции / сборки, но в случае нескольких реализаций классов (одна замещает остальные в одном пути к классам) это чаще всего вызывает неясное поведение во время выполнения, из-за несколько иной семантики.

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

Это мало чем отличается от старой пословицы базы данных: «если вы запишите то же самое» информация в двух местах, очень скоро она уже не будет прежней ». Наша проблема в том, что «довольно скоро» обычно недостаточно.

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

Это мало чем отличается от старой пословицы базы данных: "если вы записываете одну и ту же информацию в двух местах, очень скоро она перестанет быть прежней ». Наша проблема в том, что «довольно скоро» обычно недостаточно.

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

Это мало чем отличается от старой пословицы базы данных: "если вы записываете одну и ту же информацию в двух местах, очень скоро она перестанет быть прежней ». Наша проблема в том, что «довольно скоро» обычно недостаточно.