Private APIs not usable in Java 9?

Thu Apr 9 13:00:52 UTC 2015

> I guess a good place to start would be to eliminate usage of private APIs
> from scene builder.

Agreed. I noted the needed to fix SceneBuilder in a comment in 
https://javafx-jira.kenai.com/browse/RT-40184 (wherein I said I would 
file a new JIRA, but hadn't done that yet). Jonathan has already 
generated the list of internal APIs from SceneBuilder, and can add it to 
the new JIRA I just filed:

https://javafx-jira.kenai.com/browse/RT-40486

-- Kevin

Mike Hearn wrote:
> 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
>>>>>>
>>>>>>
>>>>>>             