Private APIs not usable in Java 9?
kevin.rushforth at oracle.com
Wed Apr 8 16:37:00 UTC 2015
No, this is not a misunderstanding. There will be no access to any
classes in non-public packages in JDK 9 by applications for exactly the
reasons the region rep mentioned. For JavaFX this means that no
com.sun.javafx (or similar) packages will be accessible by applications
in JDK 9.
I note that this is not limited to JavaFX. It has already been discussed
on the awt list, for example (the java.awt.peer package will not be
exported). And you won't be able to use sun.* classes or internal
classes on Swing, etc.
Note that if you build your own JDK with FX you will be able to modify
classes for your own use to workaround problems, but you will no longer
be able to simply call into com.sun.javafx.SomeClass for a workaround.
There is a good possibility that the JDK will provide a -XX
"compatibliity" switch to relax module boundaries (when there is no
security manager present) in JDK 9 to ease the pain of transition, but
that will be a temporary stop-gap not a long-term solution.
Robert Krüger wrote:
> I hope this is not too off-topic, because although it came up in a JFX
> context it's not strictly JFX-only.
> Someone from our team recently had a chat with a high-ranking regional
> Oracle representative who gave a talk on the state of JFX. Our guy
> explained our situation (evaluating JFX to migrate our swing-based product,
> feeling it's in principle the right technology but still having
> show-stopping limitations like RT-36215) and the Oracle guy offered to
> relay our concrete questions to the right people, which he did.
> The answer we got contained one thing that really was a bit of a shock and
> I would like someone to either confirm this or clear up a misunderstanding.
> The statement was that private APIs will not be available in JDK 9 due to
> modularity restrictions. If that is the case and we no longer have the
> ability to build temporary workarounds using private APIs (which in our
> case is controllable as we ship the JRE with our product), I would probably
> have to stop any development going into the direction of JFX as we will
> probably have to use 9 at some point because many things now scheduled for
> 9 will not get fixed in 8 and we will most likely still need workarounds
> using private API, at least that's what my current experience with JFX
> tells me.
> Please tell me that this was a misunderstanding (maybe meant for the
> general case where one does not ship the JRE) or a non-engineering source
> that simply made mistake.
> Best regards and thanks in advance,
More information about the openjfx-dev