Лучшая практика для контроля доступа к "внутреннему" пакету

Я пишу плагины Eclipse и экспортирую некоторые классы в качестве API, желая ограничить доступ к другим классам.

Я следую общей практике Eclipse по разделению этих классов на ".internal" subpackage.

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

Какова наилучшая практика для предотвращения или обескураживания пользователей моего API от использования этих классов в собственных целях? Есть ли автоматическая проверка?

Я признаю, что я использовал несколько внутренних классов Eclipse, когда у меня не было выбора:)

Уточнение: у меня есть аналогичная потребность с кодом без плагинов.

Ответ 1

Разве это не случай обновления META-INF/MANIFEST.MF в качестве проекта osgi плагина (если он еще не был?). Он должен выглядеть примерно так:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: My-plugin
Bundle-SymbolicName: com.mycompany.mypluginname
Bundle-Version: 1.0.0
Bundle-Vendor: MyCompany
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Service-Component: 
Import-Package: org.apache.log4j;version="1.2.14" (, separated etc)
Export-Package: com.mycompany.mypluginname.myapipackage;version="1.0.0"

И затем красиво опустить внутренний пакет. Платформа должна делать все остальное.

Кстати, вы затем используете Import-Package: в любых зависимых пакетах, плагинах и т.д., а не в зависимости от jar/project (который является старым, сочным способом, который не работает), поскольку вы находите).

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

Примечание. Как уже упоминалось в комментариях, вам не нужно запускать приложения в OSGi, чтобы получить эту "выгоду". Eclipse может скомпилировать этот код под ограничениями пакета OSGi, а ваш сборщик/сервер может работать в "незащищенном мире". например OSGi-манифестации ничего не навязывают третьим сторонам (которые хотят использовать .internal), но предоставляют "уведомления" и ограничения тем, кто их хочет.

Ответ 2

Для проектов плагинов. Используйте настройку Manifest, которую упоминает Стивен. (Вы также можете отредактировать это на странице "Время выполнения" редактора манифеста. Обратите внимание, что если вы хотите только разоблачить пакет для определенных плагинов, вы можете сделать это, используя

Export-Package: com.javadude.foo;x-friends:="com.javadude.fee"

Для проектов без плагинов. Используйте отдельные исходные папки для определения того, что экспортируется из вашего проекта.

Щелкните правой кнопкой мыши проект и выберите "Новая исходная папка" (возможно, назовите его "внутренний источник" )
Щелкните правой кнопкой мыши проект и выберите "Свойства"
Перейти к пути сборки Java
Перейдите на вкладку "Заказ и экспорт"
Снимите флажки с исходных папок, которые вы не хотите экспортировать.

В путь к классам ссылок на проекты будут добавлены только исходные папки, отмеченные в разделе "Заказ и экспорт".

Ответ 3

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

Необходимость внутреннего/пакетного доступа иногда указывает на сбой вашего API-дизайна, и вы не можете знать до тех пор, пока не будете долгое время.

Сделайте это общедоступным, назовите его InternalWhatever и живите с ним.