Wayne, This also affects Eclipse ICE. We just invested a substantial effort to redevelop some of our 3d graphics tools to use JavaFX instead JME3 (IP issues) and we used the FXCanvas to do it.
Tom, Tony McCrary and I spoke off thread about how we could deal with this. One possible solution is to make a custom FXCanvas implementation if enough public API is available in JavaFX. We also depend on GEF and I had hoped that we could move to GEF4 when it is ready. Tony did this work for us and I'm sure he would be open to helping find a solution. I'm also willing to dedicate time and funding to fix this too. Jay On Nov 18, 2015 2:27 AM, "Alexander Nyßen" <[email protected]> wrote: > Hi Tom, Wayne, > > I have not checked all parts of GEF/GEF4 yet (it’s on my list for today), > but I am definitely worried already. You are right, Tom, the Eclipse > UI-integration of GEF4 relies on FXCanvas (i.e. the JavaFX-provided > SWT-integration). If FXCanvas was not available in an Java9-context that > would literally break our neck (and that of all our adopters, except those > that build standalone graphical applications and don’t rely on the > JavaFX-SWT-integration). It would also break all others that rely on > integrating JavaFX with SWT in an Eclipse/OSGi-context. > > Regards > Alexander > > Am 17.11.2015 um 23:11 schrieb Tom Schindl <[email protected]>: > > Hi Wayne, > > Thanks for running jdeps I've fixed most of the none public API useages > and we are working with the OpenJFX-Team to make the other necessary > APIs public in Java9 as well and will reside to reflection to switch > between Java8 and Java9 APIs. > > The biggest problem although is the JavaFX-SWT-Bridge which is going to > be a nightmare. I'm not sure we as the e(fx)clipse team have the > resources to fix the problems like we did it for all of you in Java8 > where you don't have to worry about all the mess. > > For those not familiar with it: FXCanvas allows to embed JavaFX into an > SWT application (similar to the SWT_AWT-Bridge). It is shipped as part > of the JRE/JDK but is *NOT* on the classpath because FXCanvas itself is > a subclass of SWT-Canvas. > > In Java7/8 e(fx)clipse simply creates an URLClassLoader who has the > SWT-Bundleclassloader as its parent and making FXCanvas available to you > through AdapterHooks. > > Now in a Java9 world we have the situation that we have a Java9-Module > who has a dependency on SWT which runs in the unnamed module. > > I've created a bug [1] but as of today I'm clueless how to address this > chicken and egg problem and as said above I currently don't have cycles > to look into this in my spare time. > > I've talked to the OpenJFX-Team at JavaOne and they see the problem with > FXCanvas (in an OSGi-Env) and want things to work as smooth in Java9 as > it does in Java7/8 but require my help. > > What worries me is that we have to work with Oracle on the API but > without having the time to investigate the whole situation we are lost > and time is ticking. > > Anyone relying on FXCanvas should be worried as well. If FXCanvas is not > available in Java9 e(fx)clipse will loose some of its advanced features > (like automatic preview of FXML-Files, Gradient-Dialogs) which is bad > but does not break our neck but other projects might be useless without > it (GEF4 if not mistaken!). > > As our runtime does not require SWT at all the missing FXCanvas is not a > problem for the area BestSolution is putting its resources on. > > Tom > > [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428 > > On 16.11.15 22:24, Wayne Beaton wrote: > > Greetings folks! > > I just posted a blog entry [0] regarding my initial experiences using > JDK 9 Early Access with Project Jigsaw [1] with Neon. > > By way of background, Jigsaw is the project that's bringing modularity > to Java. The modularity implementation imposes restrictions on > visibility that have a direct impact on code that uses internal code. In > the past you may have had to deal with severe scolding over the use of > internal packages, but with the current EA bits, this sort of use > results in runtime exceptions. > > The download comes with a handy tool named jdeps that--among other handy > services--will scan Java code for soon-to-be illegal access of JDK > internals. > > The good news is that both the Mars and Neon repositories show that we > have very few violations in Eclipse project code. > > The very good news is that the Neon M2 and M3 builds both seems to run > just fine on the current JDK 9 + Jigsaw builds. Unless you use the > SWT_AWT bridge, that is... Unfortunately, jdeps only noticed a problem > that I think shouldn't really a problem, but in the process of > investigating, I noticed that SWT_AWT does a Class.forName(...) lookup > that results in what the Jigsaw team will regard as a legitimate violation. > > My initial investigations suggest that e(fx)clipse and Scout are taking > the biggest hit. I don't know enough about JavaFX to make a particuarly > intelligent assessment, but it looks to me like what should be the > entire public API is showing up as inaccessible. Riena gets an > honourable mention with one test case that uses an internal API. I've > attached the reports generated from the Mars and Neon repositories. > > Pay heed to my comment about Class.forName(...) above. You may have to > test your code directly. You should probably do that anyway. > > Wayne > > [0] > > https://waynebeaton.wordpress.com/2015/11/16/eclipse-ide-on-jdk-9-early-access-with-project-jigsaw/ > [1] https://jdk9.java.net/jigsaw/ > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318 > -- > Wayne Beaton > @waynebeaton > The Eclipse Foundation > EclipseCon Europe 2015 <http://www.eclipsecon.org/europe2015> > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > -- > Dr. Alexander Nyßen > Dipl.-Inform. > Principal Engineer > > Telefon: +49 (0) 231 / 98 60-202 > Telefax: +49 (0) 231 / 98 60-211 > Mobil: +49 (0) 151 / 17396743 > > http://www.itemis.de > [email protected] > > itemis AG > Am Brambusch 15-24 > 44536 Lünen > > Rechtlicher Hinweis: > > Amtsgericht Dortmund, HRB 20621 > > Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens > Trompeter, Sebastian Neus > > Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, > Jennifer Fiorentino > > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
