Results of review of private JavaFX API for consideration to make public in JDK 9

Tue Aug 11 20:11:07 UTC 2015

Yes. And we will certainly need to use this for our own unit testing, 
too. Details are tbd, but you will be able to use it for testing.

I note that this is only for testing purposes, although standalone apps 
will be able to make use of it as well (no such provision will be made 
for applets or web start apps). As with today using internal packages is 
not supported and is discouraged, except for testing.

-- Kevin

Benjamin Gudehus wrote:
>> would there be a command line switch in Java 9 that would grant TestFX
>>     
> access to internals?
>
> A command line switch like this would be great.
>
> On Mon, Aug 10, 2015 at 3:54 PM, <ngalarneau at abinitio.com> wrote:
>
>   
>> TestFX is a great tool.
>>
>> If needed for Testing (not release), would there be a command line switch
>> in Java 9 that would grant TestFX access to internals?
>>
>>
>> Neil
>>
>>
>>
>>
>> From:        Benjamin Gudehus <hastebrot at gmail.com>
>> To:        jonathan.giles at oracle.com,
>> Cc:        "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
>> Date:        08/07/2015 05:51 AM
>> Subject:        Re: Results of review of private JavaFX API for
>> consideration to make        public in JDK 9
>> Sent by:        "openjfx-dev" <openjfx-dev-bounces at openjdk.java.net>
>> ------------------------------
>>
>>
>>
>> Hi Jonathan,
>>
>> thanks for the summary!
>>
>>     
>>> pull up your sleeves and work with us to get the API into a shape where it
>>>       
>> is good enough to commit to as public API
>>
>> I'd like to help with the public API for profiling and performance tracking
>> (mainly PulseLogger, maybe PerformanceTracker).
>>
>>     
>>> These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil,
>>>       
>> and com.sun.javafx.application.PlatformImpl. As most of these classes are
>> just a collection of self-contained methods, it is quite likely that a
>> number of these methods will find public API alternatives in a new class
>>
>> Sounds good. TestFX has a dependency to
>> com.sun.javafx.application.ParametersImpl to provide the ability to test
>> multiple different `Application`s. It currently depends on private fields
>> and methods of internal classes.
>>
>>     
>>> Robot: A good API to make public, but not a small API, so the scope is
>>>       
>> possibly too great for JDK 9.
>>
>> The headless testing feature in TestFX has dependencies to
>> com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the
>> AWT robot, the "normal" testing mode needs no access to the internal APIs.
>>
>> The screenshot feature in headless testing depends on
>> com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels.
>>
>> Additionally we also need access to com.sun.glass.ui.PlatformFactory in
>> order to activate Monocle on desktop systems.
>>
>> --Benjamin
>>
>> On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles <jonathan.giles at oracle.com>
>> wrote:
>>
>>     
>>> Hi all. In April of this year a discussion began when news broke that
>>>       
>> with
>>     
>>> JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while
>>> back I posted a request to openjfx-dev for people to send me their JDeps
>>> output so that it could be analysed and used to inform our decisions
>>>       
>> around
>>     
>>> which API we should try to promote into public API. The response was very
>>> useful (and I should note: its too late now, please don't send me anymore
>>> JDeps files), and I believe we have the beginnings of a plan on how to
>>>       
>> move
>>     
>>> forward.
>>>
>>> Before I outline the plan, please note that this discussion would ideally
>>> _not_ devolve into a feature requests discussion. What we are wanting to
>>> talk about today is simply API that exists in the com.sun.* package
>>> namespace which we can conceivably bring out of this namespace for JDK 9.
>>> Developing new API is expressly out of scope (unless it is related to
>>> simplifying or wrapping the com.sun.* API).
>>>
>>> Another important point - UI control skins and a lot of very useful CSS
>>> API are being made public under JEP 253 [2]. A lot of the skin code has
>>> already been cleaned up, simplified, documented, etc, and will be merging
>>> into a repo very soon. I'll also post a separate post about JEP 253 soon.
>>>
>>> So, what does my JDeps analysis show (ignoring UI Controls and CSS usage,
>>> which has been largely resolved by JEP 253)? I can sum it up in the
>>> following categories:
>>>
>>> == 'Toolkit' API ==
>>> A lot of people use a small amount of API from Toolkit, such as the API
>>> for nested event loops, to fire a pulse, and to add / remove pulse
>>> listeners. Based on this analysis, the current thinking is to add API
>>>       
>> into
>>     
>>> the javafx.application.Platform class to enable the first two use cases
>>> above (nested event loops and pulse firing). The third use case needs
>>>       
>> more
>>     
>>> engineering effort, and is a far less common use case, so isn't being
>>> considered for JDK 9.
>>>
>>> == 'Traversal' API ==
>>> This API lives in com.sun.javafx.scene.traversal, and is quite useful
>>>       
>> when
>>     
>>> writing custom controls to ensure that keyboard traversal puts the focus
>>>       
>> in
>>     
>>> the right node at the right time. My ControlsFX open source project is a
>>> common (ab)user of this API, so I have a vested interest in making this
>>> public. Having said this, the API is actually in quite good shape, and it
>>> is possible with just a little JavaDoc work it could make the move into
>>> javafx.scene.traversal.
>>>
>>> == 'Collections Event' API ==
>>> There exists classes in com.sun.javafx.collections that are quite useful
>>> if you create your own custom ObservableList implementation and want to
>>> fire events at certain times. In my analysis there are only two projects
>>> using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent
>>> point is that this code is quite easy to reproduce, so, whilst I would
>>>       
>> like
>>     
>>> to see this API public, it doesn't seem to make sense for JavaFX 9.
>>>
>>> == 'Utils' API ==
>>> There exists three classes that are quite commonly used by people for the
>>> various utility methods contained within. These classes are
>>> com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and
>>> com.sun.javafx.application.PlatformImpl. As most of these classes are
>>>       
>> just
>>     
>>> a collection of self-contained methods, it is quite likely that a number
>>>       
>> of
>>     
>>> these methods will find public API alternatives in a new class (although
>>> there are no plans to move all the methods over!).
>>>
>>> == Miscellaneous API ==
>>> Finally, there are a few classes that popped up quite frequently. Here is
>>> the list, and my thoughts on what to do with them:
>>>
>>> 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness -
>>>       
>> not
>>     
>>> a likely candidate for JDK 9.
>>> 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX -
>>>       
>> not
>>     
>>> a likely candidate for JDK 9.
>>> 3) Robot: A good API to make public, but not a small API, so the scope is
>>> possibly too great for JDK 9.
>>> 4) PerformanceTracker: Same as Robot - good, but API might require more
>>> time than is available for JDK 9.
>>>
>>> == What about other private API ==
>>> If I've stated that an API you use isn't likely to make the cut for 9,
>>> there is another option: pull up your sleeves and work with us to get the
>>> API into a shape where it is good enough to commit to as public API. I
>>> should note that you shouldn't just dive in and do this - ping us and let
>>> us know first, so we can sync up and make sure the plan is feasible (and
>>> not overlapping). Because any large chunk of work would require moving
>>> through the JEP process, it is unlikely that anything other than small
>>> tweaks would be acceptable. One such example might be the
>>> PerformanceTracker.
>>>
>>> == Where to from here? ==
>>> The first milestone is to get JEP 253 into the main repo. That should
>>> hopefully be done before the end of August. Once that is done, focus can
>>> shift to the areas identified in this email. In the mean time, if there
>>>       
>> is
>>     
>>> any community feedback, please get it in ASAP so it can be included in
>>>       
>> the
>>     
>>> consideration.
>>>
>>> [1]
>>>
>>>       
>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html
>>     
>>> [2] http://openjdk.java.net/jeps/253
>>>
>>> Thanks!
>>> -- Jonathan
>>>
>>>       
>>
>>
>> NOTICE *from Ab Initio: This email (including any attachments) may
>> contain information that is subject to confidentiality obligations or is
>> legally privileged, and sender does not waive confidentiality or privilege.
>> If received in error, please notify the sender, delete this email, and make
>> no further use, disclosure, or distribution. *
>>     