A way to opt out of access restrictions on non-exported members.

[Alex Buckley]

On 11/23/2015 9:58 AM, Alan Snyder wrote:
> My use case is a platform specific Swing look and feel. To work, it
> needs access to platform specific features of the AWT. I’m trying not
> to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK
> will be motivated to create a public API for all of the platform
> specific features that I need, or if they do, that the API will be
> available in a timely manner. I understand that my library will have
> dependencies on specific JDK versions as it does on specific platform
> versions.

I know there is considerable effort going into replacement public APIs 
for JavaFX -- see http://openjdk.java.net/jeps/253 from May and the 
openjfx-dev thread "Understanding the com.sun.* APIs being (ab)used by 
the community" from June -- you could inquire about equivalents on 
swing-dev.

Alex

> I was unpleasantly surprised to learn (via the recent Java One talks)
> that the module encapsulation rules apply to reflection, as I had
> understood that they did not.
>
> Using command line arguments as an escape mechanism is not a good fit
> for this use. The main reason is that it places a burden on all users
> of the library, both direct and indirect. Every application in which
> this library is used must define the appropriate command line
> arguments. The other reason is that the command line argument
> solution is too broad. Using reflection, each specific need to
> penetrate encapsulation is identified. Using the command line
> argument, entire packages are opened up.
>
> Which brings me to a question... How is native code access to classes
> and methods via JNI affected by module encapsulation?
>
> Alan
>