Private APIs not usable in Java 9?

Mike Hearn mike at
Wed Apr 8 16:28:06 UTC 2015

sed -i 's/private/public/g' ;)

The whole notion of a strongly enforced private keyword is IMHO dumb when
not using sandboxing. The number of gross hacks that occur in an attempt to
work around overly strict enforcement of this stuff is crazy. The D
compiler has a special flag that disables visibility enforcement when
compiling unit tests, and that's a good idea, but why not go all the way
and just make accessing of private state a compiler warning a la deprecated?

I also need to use private JFX APIs. I think any real JFX app does, way too
much basic stuff relies on it. Heck, the number of popular Java libraries
that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back in
this regard then I will just write a simple tool that flips private->public
either at the source level or via bytecode editing, and see what happens :-)

On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger <krueger at> wrote:

> Hi,
> 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,
> Robert

More information about the openjfx-dev mailing list