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:
1. Experimental EA test build from a sandbox branch -- a parallel build,
distinct from jfx mainline builds
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.
2. Incubator modules -- API in incubator.* modules in the jfx mainline
builds
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.
3. Preview features -- API in standard modules in the jfx mainline builds
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.
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.
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.
-- Kevin
[1] https://github.com/openjdk/jfx/pull/1359
On 11/6/2024 5:57 AM, Johan Vos wrote:
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 <nlis...@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.goryac...@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-r...@openjdk.org> on behalf
of Kevin Rushforth <kevin.rushfo...@oracle.com>
*Date: *Friday, November 1, 2024 at 15:18
*To: *openjfx-dev <openjfx-dev@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
<https://urldefense.com/v3/__https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOY5NZPqw$>
[4] https://github.com/openjdk/jfx/pull/1616
<https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1616__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOKbjtAUg$>
[5] https://github.com/openjdk/jfx/pull/1617
<https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1617__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEO6j7QKaw$>
