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
