Alan, thank you for your pointer.
The code shown in [1] currently needs to access Java 9 features (to test whether the module is exported), which might not be a possibility for Java libraries that have a baseline like Java 1.4 (the GA version of the Java bridge is at that level) or 1.6 (the current beta version of the Java bridge raises the baseline to 1.6, which depends on the deployed Java runtimes; businesses hardly update to a newer level for a proved and stable running application system, where Java developers love to be on the latest version). However, before turning to possible implementations that circumvent the problem that gets introduced by the current implementation of the Java 9 module system, the question would be first, whether such breaking effects can be inhibited by changing the current implementation. --- In my case it is possible to start to program around the problem one way or the other (maybe using JNI, which would be some last resort, of course), because I have access to the sourcecode and I would know the gory details of my own implementation. This possibility is not necessarily available if businesses employ legacy, third party, complex or closed Java libraries which break because of this. It may also not be possible to fix this current incompatibility if (like a large) company rules inhibit replacing deployed and proven installations, which would mean that deployment of Java 9 would be a problem there. --- 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. Such established and tested Java reflective code can be expected to be hit quite a lot in the wild, beating Java applications that might all of a sudden break because of this. (E.g. there may be use cases where this kind of reflectiveness is applied to situations where Java code runs under different versions of Java with a low baseline, where the code running on newer versions of Java uses reflection to adapt to/access features only available in newer versions.) --- To solve this centrally in the JRE (and not force existing, proven and legitimate code to break and then force it to be reprogrammed, retested and redeployed, if that option existed at all) would allow such Java code to remain compatible with the upcoming Java 9 as well. Maybe it is possible somehow for the new code supervising invoking methods (constructors, fields) via reflection to take this into account when seeing that a public method (constructor, field) is at hand and itself determining that an accessible public superclass/interface class that declares it is available and therefore allow the invocation as was the case in the past? ---rony P.S.: A wild/crazy idea would be to force objects returned from other modules somehow to be "boxed" to the defined return type, such that a getClass() in this situation would return solely the return type's class. So in our example such a speculative boxing would have to be applied by public method getDefaultToolkit() when returning an object from a module that is not known to be open for others at runtime. Some sort of a new ProxyBox... :) On 06.01.2017 09:24, Alan Bateman wrote: > On 05/01/2017 20:07, Phil Race wrote: > >> Sort of .. it depends whether you could use getDeclaredMethod instead. >> >> One question I have is, how would you update the code if you >> were given the instance "foo", and need to programmatically >> work out what is the correct super-type of Foo that exports >> the interface method "bar" ? >> >> i.e you don't have the string "java.awt.Toolkit" handy and >> need to infer it from the instance class. > There have been a couple of threads here (going back to 2015) on this topic. > Peter included a > method [1] in one threads to walk the superclasses and directly implemented > interface of each > class to find the accessible method. Rony's example might need someone like > this if the reference > to java.awt.Toolkit is not available. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009357.html >
