Hi Kevin, Agreed that a little documentation goes a long way.
Might it be an idea to support launching a JavaFX application through service binding at a later stage? Sander > On 24 Feb 2016, at 03:07, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > > Actually, I don't see any problem here, other than that we will need to > document that if you want to launch a modular javafx application, you need to > export the package containing your main class. This is an extension of what > is needed today, which is that the class be public. If you use FXML, then the > same thing would apply to any class that you want FXML to access. > > -- Kevin > > > David Hill wrote: >> On 2/23/16, 3:37 PM, Sander Mak wrote: >>> Hi, >> >> Sander, >> we may not have tested Jigsaw with the path you are trying to take here. >> >> Certainly the common path of a class extending Application will launch >> properly, and I have been trudging through our test cases working on some >> odder paths. What I have not been doing in these paths is dealing with a new >> module, though I would think that would behave similarly to the unnamed >> module. >> >> It could be that your added complexity here has not been properly dealt with >> in our FX code. >> >> Do you have a "simple" test case that shows this error? >> >> Looking at the exception I see a lot of stuff going on, and it is hard to >> see the root right away. >> >> With modules, we have to add read edge code in certain spots when our code >> has to reach out of the module to a module it does not already know about. >> >> This is the hint here: >> >> (in module javafx.graphics) cannot access class >> javamodularity.easytext.gui.Main (in module javamodularity.easytext.gui) >> >> Our FX module javafx.graphics cannot see into your module. >> >> The question becomes one of where, and order of operations. >> >> Dave >> >> >>> >>> When trying to run a module with a main class that extends >>> javafx.application.Application, the following exception is thrown by the VM: >>> >>> Exception in thread "main" java.lang.RuntimeException: Unable to construct >>> Application instance: class javamodularity.easytext.gui.Main >>> at >>> com.sun.javafx.application.LauncherImpl.launchApplication1(javafx.graphics@9-ea/LauncherImpl.java:926) >>> >>> at >>> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$140(javafx.graphics@9-ea/LauncherImpl.java:220) >>> >>> at java.lang.Thread.run(java.base@9-ea/Thread.java:804) >>> Caused by: java.lang.IllegalAccessException: class >>> com.sun.javafx.application.LauncherImpl (in module javafx.graphics) cannot >>> access class javamodularity.easytext.gui.Main (in module >>> javamodularity.easytext.gui) because module javamodularity.easytext.gui >>> does not export javamodularity.easytext.gui to module javafx.graphics >>> at >>> sun.reflect.Reflection.throwIllegalAccessException(java.base@9-ea/Reflection.java:465) >>> >>> at >>> sun.reflect.Reflection.throwIllegalAccessException(java.base@9-ea/Reflection.java:456) >>> >>> at >>> sun.reflect.Reflection.ensureMemberAccess(java.base@9-ea/Reflection.java:98) >>> >>> at >>> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(java.base@9-ea/AccessibleObject.java:370) >>> >>> at >>> java.lang.reflect.AccessibleObject.checkAccess(java.base@9-ea/AccessibleObject.java:362) >>> >>> at >>> java.lang.reflect.Constructor.newInstance(java.base@9-ea/Constructor.java:435) >>> >>> at >>> com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$146(javafx.graphics@9-ea/LauncherImpl.java:838) >>> >>> at >>> com.sun.javafx.application.PlatformImpl.lambda$runAndWait$160(javafx.graphics@9-ea/PlatformImpl.java:351) >>> >>> at >>> com.sun.javafx.application.PlatformImpl.lambda$null$158(javafx.graphics@9-ea/PlatformImpl.java:320) >>> >>> at java.security.AccessController.doPrivileged(java.base@9-ea/Native >>> Method) >>> at >>> com.sun.javafx.application.PlatformImpl.lambda$runLater$159(javafx.graphics@9-ea/PlatformImpl.java:319) >>> >>> at >>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(javafx.graphics@9-ea/InvokeLaterDispatcher.java:96) >>> >>> >>> This can be solved by adding a (qualified) export in the module-info of the >>> module I'm trying to run (inspired by the helpful error message, nice!): >>> >>> exports javamodularity.easytext.gui to javafx.graphics; >>> >>> However, that's not really a satisfactory solution. Looks like LauncherImpl >>> also needs to setup a readability relation on-the-fly, with the caveat that >>> the class extending Application must always be exported by the application >>> developer for this to work. Is this the solution we can expect, or are >>> there any other plans for this situation? >>> >>> >>> Regards, >>> Sander >> >>
