I updated the Incubator Modules proposal to address Phil's feedback,
along with updating the example incubator module:
https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
https://github.com/openjdk/jfx/pull/1375
-- Kevin
On 2/22/2024 2:32 PM, Kevin Rushforth
Something like this might be reasonable as long as we also add "and
hasn't been modified in the current release". I could easily image the
case where an incubating feature goes into, say JavaFX 26 in March, and
by the time feedback comes in that prompts a change in the API, it's
July or August
W.r.t to (3) perhaps we could include in the write up an expectation
that continued incubation implies continued updates.
Meaning if there are no updates in a release then that either means it
is ready to be final next time round, or that the
author is no longer actively pursuing it and this
These are all good points.
1. I agree. This seems like a good idea for all the reasons you mention.
2. I'll add the additional information. And I like your suggestion to
require a JEP (*) to either drop or finalize an incubating feature.
3. Yes, I was deliberately vague on what constitutes a
1) The first thing that jumps out at me is the namespace : javafx.incubator
The JDK's JEP 11 says "An incubator module is identified by
the|jdk.incubator.|prefix in its module name"
It says the same about the packages inside the module.
"An incubating API is identified by
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
