Jay, please add your thoughts/concerns on Bug 482428.
If anybody else is impacted by this, please also add your comments on
the bug.
Wayne
On 18/11/15 07:57 AM, Jay Jay Billings wrote:
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]
<mailto:[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] <mailto:[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]
<mailto:[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 <http://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]
<mailto:[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
<tel:%2B49%20%280%29%20231%20%2F%2098%2060-202>
Telefax: +49 (0) 231 / 98 60-211
<tel:%2B49%20%280%29%20231%20%2F%2098%2060-211>
Mobil: +49 (0) 151 / 17396743
<tel:%2B49%20%280%29%20151%20%2F%20%C2%A017396743>
http://www.itemis.de
[email protected] <mailto:[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]
<mailto:[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
--
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
