Разделение пакетов в простой Java

Question

У OSGi есть проблема с разделенными пакетами, т.е.тот же пакет, но размещенный в нескольких пакетах.

Есть ли какие-либо крайние случаи, когда разделение пакетов может создать проблемы в простой Java (без OSGi)?

Просто любопытно.

Answer 1

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

Так что в простой Java это обычно не проблема, пока вы не начнете использовать какую-нибудь среду, использующую загрузчики классов.Обычно это происходит при загрузке компонентов.

Answer 2

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

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

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

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

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

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

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

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

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

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

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

Answer 3

Разделение пакетов по банкам, вероятно, не лучшая идея.Я предлагаю делать все упаковки внутри баночек запечатанными (поставить "Sealed: true" в основном разделе манифеста).Запечатанные упаковки нельзя разделить по банкам.

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

Answer 4

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

Answer 5

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

Простым примером может служить веб-приложение со слоями обслуживания и персистентности в виде отдельных пакетов OSGi.Интерфейсы персистентности должны быть общими для обоих пакетов.

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

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