Thanks, I will ! :-) Sent from my iPad
> On 11 août 2015, at 00:33, Jonathan Giles <[email protected]> wrote: > > It is likely that these classes will be included as part of JEP 253 (in > subproject 3), so they will likely become public API. Javadoc output for this > subproject will be posted in the next week or two. Keep your eyes peeled :-) > > -- Jonathan > >> On 11/08/2015 4:42 a.m., Hervé girod wrote: >> It passed under my radar that we use classes in com.sun.javafx.css, and >> com.sun.javafx.css.parser, mainly : >> - CSSParser >> - Stylesheet >> - Selector >> - Rule >> >> The use case is to be able to process JavaFX stylesheets properties. >> >> Hervé >> >> Sent from my iPad >> >>> On 7 août 2015, at 01:10, Jonathan Giles <[email protected]> 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 >
