Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] JDK 9 Early Access with Project Jigsaw


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.


On Nov 18, 2015 2:27 AM, "Alexander Nyßen" <nyssen@xxxxxxxxx> 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.


Am 17.11.2015 um 23:11 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:

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.



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

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 Beaton
The Eclipse Foundation
EclipseCon Europe 2015 <>

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Thomas Schindl, CTO EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Dr. Alexander Nyßen
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743 

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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top