Использование @hide в javadoc

Не раз встречался с аннотацией @hide в Javadoc. Известно что эта аннотация запрещает доступ к методу после релиза (доступ всё так же можно получить через рефлексию).
У меня появилась необходимость объявить интерфейс публичным для доступа из другого package, но при этом не дать возможность его использовать конечному пользователю. Есть ли какая нибудь возможность воспользоваться этой аннотацией или аналогом с подобным функционалом?
Исходя из ответа, это реализовать невозможно, но так как ответ был дан в 2014 году, есть надежда, что положение дел изменилось.

Ответ

Вы неправильно понимаете @hide. На ваш код @hide не оказывает никакого влияния вообще (как до релиза, так и после - чтобы это не значило в вашем вопросе). @hide используется только при генерации android.jar - библиотеки с заглушками.
Что касается проблемы видимости:
Скрыть публичный интерфейс нельзя. Возможно, получится все реализации интерфейса перенести в тот же пакет что и сам интерфейс. Это решит проблему видимости. Можно оставить видимость package и везде где нужен экземпляр класса использовать рефлексию Class.forName(...) Если у вас есть доступ к процессу компиляции, то можно для написания кода использовать "нерабочую" jar с заглушками, а в момент компиляции подменять на полноценный jar со всеми файлами.
P.S. Публичный интерфейс это даже хорошо. Вдруг кому-то понадобится написать его собственную реализацию данного интерфейса.

Пояснения к пункту 4 :
Если вы делаете публичную библиотеку, то хотите чтобы сторонние программисты видели только некоторые функции и класс, или хотите скрыть реализацию функций и ресурсы и т.д.. С помощью public/private/protected скрыть всё что вы хотите невозможно. Поэтому иногда используют метод под названием stub.jar он же dummy code. Этот метод является основой подхода "Skeleton programming".
Заключается он в том, что в проект стороннего программиста вместо вашей библиотеки добавляется stub.jar - это библиотека из которой вырезана реализация методов, ресурсы, скрытые классы и методы - всё то, что сторонний программист не должен видеть. Такой jar можно написать самому или сгенерировать чем-нибудь типа Stubber. Кончено такой jar неработоспособен - там только заглушки.
Зачем это нужно - сторонний программист не видит ваши скрытые классы, алгоритмы шифрования и т.д., но при этом он может писать, компилировать, и тестировать свой код так как-будто использует вашу библиотеку.
Чтобы получить готовый продукт нужно перед компиляцией подменить stub.jar на рабочую библиотеку. Как это сделать зависит от вашей системы сборки. Можно подменять руками - удалять старый jar и добавлять новый, можно использовать системы сборки типа Gradle например так:
task replaceStubs() { delete fileTree(dir: 'libs' , include: '**/*_Stub.jar') copy { from `MyRelaseLibsFolder` into `libs` } }
P.P.S. Есть субъективное ощущение что это не то что вам нужно