Private APIs not usable in Java 9?

[Mike Hearn]

I guess a good place to start would be to eliminate usage of private APIs
from scene builder. I understand that it doesn't seem to be supported any
more but it'd be extremely weird and embarrassing for Oracle if the UI
builder tool broke on Java 9 given all the work that went into it.
On 9 Apr 2015 9:54 am, "Jonathan Giles" <jonathan.giles at oracle.com> wrote:

> For what it is worth, investigations are underway in relation to UI
> control skins and behaviors. It's too early for anything definitive to
> announce, but it is not inconceivable that com.sun.javafx.scene.control.skin
> may become javafx.scene.control.skin, more or less (with a lot of work
> cleaning up, etc).
>
> In terms of behaviors, some investigations are already underway in
> RT-21598, but these too are only early, and fall under the bigger project
> of getting UI controls and CSS APIs into a jigsaw-friendly form for JDK 9
> (which is a huge undertaking, and community support will be useful and
> sought at the appropriate time).
>
> Thanks,
>
> -- Jonathan
>
> On 9/04/2015 5:39 p.m., Tom Schindl wrote:
>
>> 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
>>>>>
>>>>>
>>
>