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

Tue Aug 11 18:52:29 UTC 2015

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