Preview features for JavaFX

[Kevin Rushforth]

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