In order for preview features and incubating features to not cause more
problems than they solve, there needs to be a robust way to ensure that
applications and libraries don't use them without knowing that they are
doing so. We know how to do that for a feature that lives in its own
module (an incubating feature), but not how to do that for something
like a preview feature.
For incubating features, this is relatively straight-forward, since they
are delivered in a separate module that has "incubator" in the name,
isn't resolved by default, and warns you at runtime when those modules
are resolved. Adapting what the JDK does for JavaFX should be pretty
easy, and retain the benefit that an app knows when they are using
incubating features.
I don't think it is feasible to do the same thing for preview features.
The way the JDK preview features work is that a command line option is
needed both at compile time and at runtime to opt into preview features
for a specific release. This prevents using a preview API from an
existing module and package without knowing that it is subject to
change. Without a clear "opt in" mechanism to be able to use an API, an
app would be able to accidentally use a feature whose API is unstable
and quite possible might change. An annotation isn't good enough (and
documentation certainly isn't sufficient). IDEs will still autocomplete
and show the API, and once an app uses it -- accidentally or otherwise
-- there is no indication at runtime that you are using a feature that
will likely stop working without any notice in the next version.
I don't see a good way to do this for JavaFX given the limitations.
-- Kevin
On 2/5/2024 7:19 PM, Michael Strauß wrote:
The discussion around the new Platform Preferences API has brought up
a potential area where the API may lack a way to detect whether a
particular preference is supported on a particular operating system
[0].
Discussions like these will invariably come up when new API is
released, and some of the real-world insights may prove to be very
valuable. However, with the current development process, we specify
and implement new features largely without feedback from application
developers. I know that, in principle, developers can join in on the
discussion on this mailing list. But the reality is that GA is the
first time that a new feature gets wider exposure.
All of this makes it very hard for us to ship new features, since we
must be extremely careful to get it right the first time. The JDK uses
incubator modules and preview features to address these challenges. It
seems that OpenJFX will also potentially use an incubator module to
introduce new controls [1].
This is great for modular features, but not so great for new API that
is added to existing infrastructure. Maybe we could add something akin
to preview features to OpenJFX: this could be as easy as documenting
the new API to be in preview, or decorate the new API with a
@PreviewFeature annotation. I don't think that it is necessary to go
beyond simple documentation; in particular, we don't need this to be
integrated with the Java compiler.
Documenting new features to be preview features will enable us to ship
features quicker, and ensure that what we're building is actually
useful in the real world because we can actually go back and improve
aspects of a feature without worrying as much about backwards
compatibility.
In particular, my suggestion is to ship the new Platform Preferences
API as a preview feature for jfx22.
[0] https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html
[1] https://bugs.openjdk.org/browse/JDK-8309381
