Proposal: JavaFX Incubator Modules
Nir Lisker
nlisker at gmail.com
Wed Nov 6 12:57:47 UTC 2024
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/e8fd698f/attachment.htm>
More information about the openjfx-dev
mailing list