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
cross-project-issues-dev@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev