<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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:<br>
<br>
1. Experimental EA test build from a sandbox branch -- a parallel
build, distinct from jfx mainline builds<br>
<br>
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.<br>
<br>
2. Incubator modules -- API in incubator.* modules in the jfx
mainline builds<br>
<br>
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.<br>
<br>
3. Preview features -- API in standard modules in the jfx mainline
builds<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- Kevin<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://github.com/openjdk/jfx/pull/1359">https://github.com/openjdk/jfx/pull/1359</a><br>
<br>
<br>
<div class="moz-cite-prefix">On 11/6/2024 5:57 AM, Johan Vos wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABxFH2Fqi_r7Xm+y3YYbUUu492Ar4ZWw5=HE-b6NYNVtsGW6mg@mail.gmail.com">
<div dir="ltr">
<div>Thank you Kevin for restarting the discussion!</div>
<div><br>
</div>
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.
<div>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):
<div>* Metal pipeline</div>
<div>* Wayland pipeline</div>
<div>* Direct3D12 pipeline</div>
<div>* Headless glass platform</div>
<div><br>
</div>
<div>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. </div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Johan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2024 at 1:59 PM
Nir Lisker <<a href="mailto:nlisker@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">nlisker@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">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?
<div>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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2024 at
12:22 AM Andy Goryachev <<a href="mailto:andy.goryachev@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">andy.goryachev@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16"">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:</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16""> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16"">- the
proposed API and implementation are not final</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16"">- you,
the developers, have a chance to have your voice
heard and acted upon by the platform</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16""> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16"">I
think it's a win-win for everyone involved.</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16""> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16"">-andy</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16""> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16""> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Iosevka Fixed SS16""> </span></p>
<div id="m_417328484365177146m_6695130465001093369mail-editor-reference-message-container">
<div>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">openjfx-dev
<<a href="mailto:openjfx-dev-retn@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">openjfx-dev-retn@openjdk.org</a>>
on behalf of Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@oracle.com</a>><br>
<b>Date: </b>Friday, November 1, 2024
at 15:18<br>
<b>To: </b>openjfx-dev <<a href="mailto:openjfx-dev@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">openjfx-dev@openjdk.org</a>><br>
<b>Subject: </b>Re: Proposal: JavaFX
Incubator Modules</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt">I'm restarting
the discussion from an earlier thread
[0], along with a
<br>
PR to get the support for JavaFX
incubator modules integrated ahead of <br>
any particular feature that might use
them.<br>
<br>
JEP 11 [1] defines a process for
delivering non-final JDK APIs in <br>
incubator modules.<br>
<br>
Similarly, some JavaFX APIs would
benefit from spending a period of time <br>
in a JavaFX release prior to being
deemed stable. I propose JavaFX <br>
incubator modules as a means of putting
non-final API in the hands of <br>
developers, while the API progresses
towards either finalization or <br>
removal in a future release. This is
especially useful for complex <br>
features with a large API surface.<br>
<br>
The JavaFX proposal is largely the same
as the JDK one, but has some <br>
important differences that are listed in
the JEP.<br>
<br>
Please take a look at the updated
proposal [2] and PR 1616 [3] that adds <br>
the needed support for incubator
modules.<br>
<br>
I have also created a Draft PR [4] with
an example module, for <br>
illustrative purposes only, to show how
this might work. This Draft PR <br>
is based on PR 1616.<br>
<br>
Please reply to this message with any
feedback, or add PR comments in PR <br>
1616.<br>
<br>
Thank you.<br>
<br>
-- Kevin<br>
<br>
[0] <a href="https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">
https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html</a><br>
[1] <a href="https://openjdk.org/jeps/11" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/jeps/11</a><br>
[2] <br>
<a href="https://urldefense.com/v3/__https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOY5NZPqw$" target="_blank" moz-do-not-send="true">https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md</a><br>
[4] <a href="https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1616__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOKbjtAUg$" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jfx/pull/1616</a><br>
[5] <a href="https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1617__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEO6j7QKaw$" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jfx/pull/1617</a></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>