Hi, I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage.
The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? Tom Von meinem iPhone gesendet > Am 26.05.2016 um 02:43 schrieb Mandy Chung <mandy.ch...@oracle.com>: > > > >> On May 25, 2016, at 3:38 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> >> wrote: >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8131888 >> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >> >> This adds support for the javafx.embed.swt package back into the JDK, which >> will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar >> (final location is TBD). > > The approach to have javafx.swt be an automatic module that can access > org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I > wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? > They both have the same module name “javafx.swt”. > > I skimmed through the change. There are several System.err.println calls > that I assume are debugging code to be removed. e.g. > > FXCanvas.java > 247 System.err.println("FXCanvas class successfully initialized”); > 294 System.err.println("FXCanvas: FX platform is > initlialized”); > > PlatformImpl.java > 308 System.err.println("FXCanvas: no permission to access > JavaFX internals"); > 309 ex.printStackTrace(); > > I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. > Happy to see StackWalker be useful in this case. The check to compare the > class name with “javafx.embed.swt.FXCanvas” to derermine whether qualified > exports should be added. You can consider checking the caller's module name > as a starter. I know you are planning to look into the integrity check as a > follows up. > > ModuleHelper.java > 57 // ignore > > This deserves to be an InternalError. This is temporary until FX is > transitioned to be built with JDK 9. > > Otherwise, look fine to me. > Mandy
