<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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 already, meaning that any changes will
go into JavaFX 28.<br>
<br>
The time between when a feature first released (in a GA release) and
the feature freeze for the next release is only a little over 3
months (which is why most features will incubate for at least two
releases).<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/22/2024 1:08 PM, Philip Race
wrote:<br>
</div>
<blockquote type="cite" cite="mid:6118f676-c3d4-47f3-969a-d0516c36b126@oracle.com">
W.r.t to (3) perhaps we could include in the write up an
expectation that continued incubation implies continued updates.<br>
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<br>
author is no longer actively pursuing it and this should inform
the Project Lead as to what action should be taken next.<br>
<br>
-phil.<br>
<br>
<div class="moz-cite-prefix">On 2/21/24 1:55 PM, Kevin Rushforth
wrote:<br>
</div>
<blockquote type="cite" cite="mid:9607cefb-9d61-401e-983a-33a4ab00f729@oracle.com">
These are all good points.<br>
<br>
1. I agree. This seems like a good idea for all the reasons you
mention.<br>
<br>
2. I'll add the additional information. And I like your
suggestion to require a JEP (*) to either drop or finalize an
incubating feature.<br>
<br>
3. Yes, I was deliberately vague on what constitutes a
reasonable amount of time. Given that we are changing the
default to "re-incubate" it does make sense to have a "soft
timeout" so incubating features don't incubate forever without
an intentional action to keep them alive.<br>
<br>
I'll update the proposal accordingly.<br>
<br>
Thanks.<br>
<br>
-- Kevin<br>
<br>
(*) We don't exactly follow the JEP process as described in JEP
2, but for larger features we expect a proposal that touches on
the important points in a JEP-like document and is discussed on
the mailing list. That's what we mean when we say "needs a JEP".<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/21/2024 9:47 AM, Philip Race
wrote:<br>
</div>
<blockquote type="cite" cite="mid:895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com"> 1)
The first thing that jumps out at me is the namespace :
javafx.incubator<br>
<br>
The JDK's JEP 11 says "<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">An
incubator module is identified by the<span class="Apple-converted-space"> </span></span><code style="font-family: "DejaVu Sans Mono", "Bitstream Vera Sans Mono", "Luxi Mono", "Courier New", monospace; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">jdk.incubator.</code><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><span class="Apple-converted-space"> </span>prefix in its module
name"<br>
It says the same about the packages inside the module.<br>
"</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">An
incubating API is identified by the<span class="Apple-converted-space"> </span></span><code style="font-family: "DejaVu Sans Mono", "Bitstream Vera Sans Mono", "Luxi Mono", "Courier New", monospace; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">jdk.incubator.</code><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><span class="Apple-converted-space"> </span>prefix in its
exported package names".</span><br>
<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><br>
This is to avoid using the standard namespace prefixes for
JDK of java. and javax. used for final APIs/modules.<br>
<br>
So similarly I think JavaFX incubators should avoid the
javafx. prefix and I suggest "jfx." be used instead.<br>
This closely mirrors the "jdk." used in JEP 11, taking
"java" out of the prefix and making it entirely an acronym,<br>
for both module and package names.<br>
The pain of updating your code when the API goes final can
be eased by IDEs and is something you would<br>
need to do anyway because "incubator" is in all the names in
either case.<br>
<br>
2) The second thing is you don't say what the steps are to
promote the incubating module to final.<br>
JEP 11 says a new JEP is needed for that, but it also says a
new JEP is needed to re-incubate<br>
which is something JavaFX will not require.<br>
So do you expect it will be a new JEP for that ?<br>
I think that would be best to do that as the JEP to propose
the incubator could be several years old and stale by then.<br>
You also don't say what it takes to drop it.<br>
<br>
So how about the basic process is that the first JEP simply
proposes the incubating module, once<br>
it is in as you say it evolves by normal RFEs across
releases ?<br>
Then when it is EITHER ready to go final OR be removed, a
new JEP must be proposed for that.<br>
A removal JEP should generally be quite short :-)<br>
<br>
So I suggest to add a sentence along those lines to the
proposal.<br>
"To either make the API of an incubating module final, or to
remove it, then a new JEP should be submitted,<br>
referencing the incubator JEP".<br>
<br>
3) The "reasonably small number of JavaFX releases" is I am
sure intentionally vague, but perhaps<br>
we could say<br>
(1) Incubators which span beyond a 24 month period and are
not yet ready will need<br>
a simple public approval from the project lead to remain for
some additiional period at the discretion<br>
of the Project Lead by adding a simple comment in the JEP,
otherwise the Project Lead will submit a removal JEP and<br>
(2) the submitter of the JEP can propose to remove it at any
time.<br>
<br>
-phil.<br>
</span><br>
<div class="moz-cite-prefix">On 2/21/24 9:37 AM, Kevin
Rushforth wrote:<br>
</div>
<blockquote type="cite" cite="mid:4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com">JEP
11 [1] defines a process for delivering non-final JDK APIs
in incubator modules. <br>
<br>
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. <br>
<br>
The JavaFX proposal is largely the same as the JDK one, but
has some important differences. <br>
<br>
Please take a look at the preliminary proposal [2]. I have
also created a Draft PR [3], for illustrative purposes only,
to show how this might work. <br>
<br>
Please reply to this message with any feedback. <br>
<br>
Thanks. <br>
<br>
-- Kevin <br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/11" moz-do-not-send="true">https://openjdk.org/jeps/11</a>
<br>
[2] <a class="moz-txt-link-freetext" href="https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md" moz-do-not-send="true">https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md</a><br>
[3] <a class="moz-txt-link-freetext" href="https://github.com/openjdk/jfx/pull/1375" moz-do-not-send="true">https://github.com/openjdk/jfx/pull/1375</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>