On 06.01.2017 17:03, Michael Rasmussen wrote: >> 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. Agreed. > Simple example of such a scenario: > https://gist.github.com/anonymous/2c87d8a88b3c1a449b54deab4ec3fe88 This is a (nice, but totally) different example from the presented use-case, which pattern may be applied in many deployed Java applications that would unexpectedly break with the current implementation.
---rony
