Proposal: JavaFX Incubator Modules

[Johan Vos]

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
>> [4] https://github.com/openjdk/jfx/pull/1616
>> [5] https://github.com/openjdk/jfx/pull/1617
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241106/c2cf0683/attachment.htm>