A way to opt out of access restrictions on non-exported members.
alex.buckley at oracle.com
Tue Nov 24 00:24:34 UTC 2015
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
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
> 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?
More information about the jigsaw-dev