модификатор доступа «уровень фреймворка»

Вот сценарий. Как создатель публично лицензированных API с открытым исходным кодом, моя группа создала инфраструктуру пользовательского веб-интерфейса на основе Java (так что еще нового?). Чтобы все было хорошо организовано, как и должно быть в Java, мы использовали пакеты с соглашением об именах. org.mygroup.myframework.x, где x означает компоненты, валидаторы, преобразователи, утилиты и т. д. (опять же, что еще нового?).

Теперь где-то в классе org.mygroup.myframework.foo.Bar — это метод void doStuff(), который мне нужен для выполнения логики, характерной для моего фреймворка, и мне нужна возможность вызывать его из нескольких других мест в фреймворке, например, org.mygroup.myframework .фар.Бу. Учитывая, что Boo не является подклассом Bar и не находится в одном и том же пакете, метод doStuff() должен быть объявлен общедоступным, чтобы Boo мог вызывать его.

Однако моя структура существует как инструмент, позволяющий другим разработчикам создавать более простые и элегантные RIA для своих клиентов. Но если com.yourcompany.yourapplication.YourComponent вызывает doStuff(), это может иметь неожиданные и нежелательные последствия. я буду предпочитаю, чтобы этого никогда не было допущено. Обратите внимание, что Bar содержит другие методы, которые действительно являются общедоступными.

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

[org.mygroup.myframework.*] void doStuff() { .... }

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

Учитывая, что этого мира не существует, какие еще хорошие варианты у нас могут быть?

Обратите внимание, что это мотивировано реальным сценарием; имена изменены, чтобы защитить виновных. Существует реальная структура, в которой в Javadoc можно найти общедоступные методы, прокомментированные как «ЭТОТ МЕТОД ЯВЛЯЕТСЯ ВНУТРЕННИМ ДЛЯ МОЕЙ ФРЕЙМОВОЙ, А НЕ ЧАСТЬ ЕГО ОБЩЕСТВЕННОГО API. НЕ ВЫЗЫВАТЬ!!!!!!" Небольшое исследование показывает, что эти методы вызываются откуда-то еще внутри фреймворка.

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

Обновление: пока не обижайтесь на двух ответивших, но я думаю, что вы промахнулись, или я не совсем правильно выразился. В любом случае позвольте мне попытаться осветить вещи. Проще говоря, как разработчики фреймворка должны были реорганизовать следующее. Обратите внимание, что это очень грубый пример.

package org.mygroup.myframework.foo;
public class Bar {
     /** Adds a Bar component to application UI */
     public boolean addComponentHTML() {
         // Code that adds the HTML for a Bar component to a UI screen
         // returns true if successful
         // I need users of my framework to be able to call this method, so
         // they can actually add a Bar component to their application's UI
     }

     /** Not really public, do not call */
     public void doStuff() {
         // Code that performs internal logic to my framework
         // If other users call it, Really Bad Things could happen!
         // But I need it to be public so org.mygroup.myframework.far.Boo can call
     }
}

Еще одно обновление: я только что узнал, что в C# есть модификатор доступа "internal". Так что, возможно, лучше было бы сформулировать этот вопрос так: «Как имитировать/эмулировать внутренний доступ в Java?» Тем не менее, я не ищу новых ответов. Наш босс в конце концов согласился с упомянутыми выше опасениями