Private APIs not usable in Java 9?

[Tom Schindl]

Hi,

in SWT on JavaFX (most likely NOT a common useage of JavaFX):
-------------------------------------------------------------
I had to reside to private-API when it comes to:
* text calculations where there is no public API for things like
  FontMetrics, TextLayout, ...
* For some of the direct drawing code I had to use com.sun.javafx.geom.*
* For some operations I had to access the com.sun.glass.ui.Robot &
  com.sun.glass.ui.Application
* I had to get access to the VirtualFlow

To implement custom controls e.g. CodeEditor:
---------------------------------------------
* com.sun.javafx.scene.control.skin.BehaviorSkinBase
* com.sun.javafx.scene.control.behavior.KeyBinding
* com.sun.javafx.css.converters.InsetsConverter
* com.sun.javafx.css.converters.PaintConverter
* com.sun.javafx.scene.text.HitInfo

So to summerize the most lacking API is in the font/text rendering space
and to get public access to VirtualFlow would be a nice to have!

Tom


On 08.04.15 18:44, Phil Race wrote:
> 
>>  it's not strictly JFX-only.
> 
> Its not remotely FX only, in fact I could argue FX is not so affected,
> as being relatively new it does not have 20 years of accumulation
> of people using internal APIs that the larger JDK does, often dating from
> when there were no suitable public APIs. There still remains some
> of that with sun.misc.Unsafe as pointed out which will indeed be
> inaccessible in modular mode. But the FX list isn't really the place
> for that discussion. The jigsaw-dev is the appropriate list. FX
> is simply bound by the rules that are set there.
> 
> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
> transition.
> 
> Also remember FX is open source. You can propose patches !
> If there are specific APIs that are missing from FX that are suitable
> to be *supported* public APIs then those could be considered here (this
> list).
> 
> -phil.
> 
> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>> 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 lesspain.de>
>> 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
>>>
> 


-- 
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