> There are rather a lot of libraries out there that access private > members via reflection. I posit that almost all such libraries break > without an easy way to fix the problem, if there is no way to use > reflection to access non-exported members.
I agree with Reinier that there are situations where it makes sense to bypass module encapsulation and the existing access rules. Encapsulation is a good thing, but unless it is needed for security, Java should not be totally rigid about it. 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 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
