[External] : Re: Proposal: JavaFX Incubator Modules

Wed Nov 6 16:16:36 UTC 2024

As I see it, there are three different, but at least somewhat 
overlapping, ways to get non-final functionality into the hands of 
developers for testing:

1. Experimental EA test build from a sandbox branch -- a parallel build, 
distinct from jfx mainline builds

A sandbox branch (which is equivalent to a project repo like loom, 
lanai, or valhalla without having to create a separate repo), is a way 
to do all sorts of experiments. When additional feedback is needed, 
producing an experimental EA test build can be a way to have developers 
"kick the tires" to see how well it works. This is suitable for things 
that impact the implementation, like a new graphics pipeline  (Metal, 
D3D12), a new glass backend (wayland, headless), or some other idea. 
Such a test build might have limitations, might not be functionally 
complete, some things might not work, etc. It could also be used to test 
drive a new API before it is ready for a wider test. A sandbox build 
could be suitable for things where the goal is to have a few motivated 
developers test a specific feature, since they will need to be willing 
to go grab a custom experimental build and use it.

2. Incubator modules -- API in incubator.* modules in the jfx mainline 
builds

This is API that isn't ready to be finalized and is subject to change, 
but is ready to be in the mainline with the same level of quality as 
anything else that goes into the mainline, meaning it needs to be 
functionally complete, and not break anything else. It is in a separate 
module so an application knows that are using incubating APIs. The APIs 
are likely to change in response to feedback.

3. Preview features -- API in standard modules in the jfx mainline builds

This is APIthat is almost ready to finalize. It would typically be in an 
existing module as new packages, new classes in existing packages, or 
new methods in existing classes. The API is subject to change, but might 
not change if there are no concerns raised. Since we don't have compiler 
and runtime support, we will need some other "opt in" mechanism so that 
an application knows they are using preview features. Michael proposed 
preview features [1] and I think it's worth revisiting that proposal.

All three have their uses. And while some features might go from sandbox 
--> incubator or sandbox --> preview, it isn't a hard requirement in the 
JDK, and shouldn't be a hard requirement for JavaFX. Some things will go 
directly to mainline without any experimental phase (that's been the 
case for all new JavaFX features up to this point). Some might go into a 
sandbox test build and then into mainline, like Metal (there is no API, 
so incubator modules or preview features are not suitable), some might 
go to incubator then mainline, while other might go to preview and then 
mainline.

We might want to start a new thread on Preview features and experimental 
sandbox builds, although we can discuss the aspects that are common to 
all three in this thread.

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1359

On 11/6/2024 5:57 AM, Johan Vos wrote:
> Thank you Kevin for restarting the discussion!
>
> Adding to what others said (very valid feedback from Michael/John), I 
> specifically want to add a comment about Nir's remark where he 
> mentioned Metal/DX12 pipelines.
> I am a bit worried about the difference between the openjfx sandbox 
> repository and the incubating modules. There are currently (at least) 
> 4 very important branches in the sandbox, that imho are much more 
> important than adding more functionality in the controls (which can be 
> added in userspace):
> * Metal pipeline
> * Wayland pipeline
> * Direct3D12 pipeline
> * Headless glass platform
>
> Those projects do not add new functionality, but they are crucial for 
> maintaining OpenJFX. They are the foundation of existing and new 
> features. They are less visible to end-developers, as they don't 
> change/add external API's. That combination (being critical for 
> OpenJFX and not being attractive to get tested because it's not new 
> functionality) is a bit dangerous, so I believe we must give this high 
> priority, make sure they get reviewed in the OpenJFX community and 
> tested outside the OpenJFX community.
>
> At least with a number of incubating modules in OpenJDK, there was 
> initial sandbox development, which really allows for testing/feedback. 
> If we allow incubating modules to skip this sandbox stage, then I'm 
> not sure there is more value left in the sandbox repository.
>
> - Johan
>
> On Wed, Nov 6, 2024 at 1:59 PM Nir Lisker <nlisker at gmail.com> wrote:
>
>     Being able to add an API without the guarantee for backwards
>     compatibility (temporarily) is obviously alleviating to the
>     developers and will ensure a better end result. My only concern is
>     the amount of usability this can get. Incubating modules usually
>     offer a substantial amount of code. In the JDK there are only a
>     handful of incubating modules, like FFM and Vector API. JavaFX
>     hardly has these huge changes. RTA is perhaps the first one and it
>     seems like incubating modules in JavaFX are added ad-hoc for that.
>     What other uses are envisioned as an incubating module?
>     Are various platform-related changes like platform preferences,
>     customizable window headers etc. suitable for an incubating
>     module? The Metal/DX12 pipelines? One of the many CSS proposals?
>     Behavior/Skin/Input splitting proposals? From what I know, an
>     incubating module is suitable for independent features that can be
>     "nailed on the side" for a while until they are seamlessly
>     integrated, but I don't see JavaFX having many of those.
>
>     On Wed, Nov 6, 2024 at 12:22 AM Andy Goryachev
>     <andy.goryachev at oracle.com> wrote:
>
>         I think the incubator module is a great idea: it allows us to
>         elicit feedback from the platform consumers (the actual target
>         group) rather than a small subset of developers active on the
>         mailing list, however great those people might be.  And being
>         an incubator module, it allows us to send two clear signals:
>
>         - the proposed API and implementation are not final
>
>         - you, the developers, have a chance to have your voice heard
>         and acted upon by the platform
>
>         I think it's a win-win for everyone involved.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf
>         of Kevin Rushforth <kevin.rushforth at oracle.com>
>         *Date: *Friday, November 1, 2024 at 15:18
>         *To: *openjfx-dev <openjfx-dev at openjdk.org>
>         *Subject: *Re: Proposal: JavaFX Incubator Modules
>
>         I'm restarting the discussion from an earlier thread [0],
>         along with a
>         PR to get the support for JavaFX incubator modules integrated
>         ahead of
>         any particular feature that might use them.
>
>         JEP 11 [1] defines a process for delivering non-final JDK APIs in
>         incubator modules.
>
>         Similarly, some JavaFX APIs would benefit from spending a
>         period of time
>         in a JavaFX release prior to being deemed stable. I propose
>         JavaFX
>         incubator modules as a means of putting non-final API in the
>         hands of
>         developers, while the API progresses towards either
>         finalization or
>         removal in a future release. This is especially useful for
>         complex
>         features with a large API surface.
>
>         The JavaFX proposal is largely the same as the JDK one, but
>         has some
>         important differences that are listed in the JEP.
>
>         Please take a look at the updated proposal [2] and PR 1616 [3]
>         that adds
>         the needed support for incubator modules.
>
>         I have also created a Draft PR [4] with an example module, for
>         illustrative purposes only, to show how this might work. This
>         Draft PR
>         is based on PR 1616.
>
>         Please reply to this message with any feedback, or add PR
>         comments in PR
>         1616.
>
>         Thank you.
>
>         -- Kevin
>
>         [0]
>         https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html
>         [1] https://openjdk.org/jeps/11
>         [2]
>         https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md
>         <https://urldefense.com/v3/__https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOY5NZPqw$>
>         [4] https://github.com/openjdk/jfx/pull/1616
>         <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1616__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOKbjtAUg$>
>         [5] https://github.com/openjdk/jfx/pull/1617
>         <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1617__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEO6j7QKaw$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241106/af7784d0/attachment-0001.htm>