Alexander A. Sak, а где я говорил только о публичных полях? Я лишь, говорил, что private слишком огораживает разработчика, который хочет залезть во внутренности чужого класса. И сначала подумал о замене protected и private на internal, но потом пришел к выводу, что "дешевле" расширить extends до fork, который позволит расширить чужой класс и дать полный доступ к его кишочкам для работы на свой страх и риск. По крайне-мере это проще, чем делать форк, юзать рефлекш, аоп и прочие костыли.

mayton,
авторвооруженный шаблоном Fork сможет унаследовать java.lang.String
Можно наблюдать опыт JavaScript, там много чего делали со String, но в итоге сошлись на том, что расширять фундаментальные типы, даже банальным добавлением метода - плохой тон. И как-то живут себе, пишут код )

Понятно, что java это довольно консервативная платформа, но тем не менее у неё есть JVM, на которой можно запилить свой ЯП с блэк джеком и дамами легкого поведения )

забыл ник,
авторвся модель безопасности идет лесом
Тогда и рефлекшн нужно запретить, там ведь тоже можно сделать setAccessible(true). Но если модель безопасности можно настроить на запрет рефлекшн, то и fork можно запретить, если кому-то это нужно, так что ваш аргумент мимо кассы.

Alexander A. Sak,
авторТолько Питон.
И причем тут питон? Я же на форуме java...

забыл ник,
авторесли одному ленивому программисту это мешает
Лень - двигатель прогресса, еще один мимо кассы.

For All,
авторПлохому танцору тапочки жмут
Причем тут тапочки и плохой танцор? Отследите логику - мне нужно расширить некоторую функциональность класса, которую разработчик не предусмотрел или не смог допилить. Но при этом, мне не хочется делать форк или поддерживать его библиотеку. Потому что это сложнее, чем сделать наследование вот прям тут в IDE и получить полный доступ к пакетам классов, как своим.

mayton, нет, мне проще будет реализовать fork фичу в виде плагина для eclipse, правда я пока не знаю, где там копаться, чтобы расширить валидатор для таких конструкций:

mad_nazgul,

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

mad_nazgul,
авторРасширяйте, кто вам мешает?!
Не кто, а что мне мешает. А мешают мне приватные методы и поля, из-за которых приходится использовать Reflection. Как один из недавних примеров, невозможности предусмотреть всё - в Nashorn нельзя было получить доступ к ScriptObject, т.к. он был обернут в ScriptObjectMirror в приватном поле. И тут вы конечно с умничаете и скажете нефиг лезть внутрь. Но мне было удобнее работать со ScriptObject напрямую и я запилил Reflection обертку.

А недавно, спустя несколько месяцев, я увидел новый класс ScriptUtils (если не ошибся с названием), где появились методы wrap и unwrap, чтобы работать со ScriptObject напрямую. И заметьте мне такой метод был нужен несколько месяцев назад и очевидно не мне одному тоже.

Так что, как видите очень простой пример, когда разработчик не смог предусмотреть, то что будет нужно пользователю. При этом, если придерживаться вашей логики, то я должен ждать несколько месяцев, пока нужный доступ откроют официально. Либо пользоваться рефлекшн. Но рефлекшн в более сложных случаях - громоздок. Поэтому нужно альтернативное решение, например такое как fork внутри кода, с использованием фич из АОП.

Basil A. Sidorov, так и я сделал обертку, только использовал для этого reflection ) Это я просто привел как пример, того, что разработчики не знают, что нужно открыть для пользователя. Вообще, спор из интересного обменами мыслями, перешел в какое-то перепирание и не умение вчитываться, в то что я предлагаю.

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