> To turn back to the root cause: using reflection a public class from > java.desktop is loaded, one of > its public static methods gets employed and returns an object of the type of > that public > java.desktop class. Under the covers, however, an object gets returned which > got instantiated by > that java.desktop class from a class that resides in a module that is open to > java.desktop, but > closed to others. > > This action is not under control of the reflective code, it is the sole > responsibility of the > accessible public class' public method. Applying reflectiveness on that > object, like it has been > possible for many Java versions and years in the past, all of a sudden breaks > in this case with an > exception, that pre-Java-9 code could never have taken into account. The code > does nothing unusual > and respects the publicness of classes and its public members. > > So the current implementation of the module access rules to public (!) > methods of the returned > object/in place of an accessible public class/ may break existing, proven, > legitimate, reflective code.
Pre-java-9 code must still take accessibility into account, as the method might return a non-public implementation of the public API. Granted, previously it was easier to bypass this using setAccessible. Simple example of such a scenario: https://gist.github.com/anonymous/2c87d8a88b3c1a449b54deab4ec3fe88 /Michael
