On Thu, 13 Feb 2025 21:53:25 GMT, Michael Strauß <[email protected]> wrote:
>> Yeah, that's what I came to realize as well. So our property should remain
>> boolean.
>>
>> The only other thing I could think of is for us to provide a new utility
>> method (in some class in javafx.base) that an application must call to
>> register the version of JavaFX API that are compiling against. For example,
>> imagine a `java.javafx.util.PreviewFeatures` class with the following method:
>>
>>
>> public void setVersion(int featureVersion) {}
>>
>>
>> An application would need to call `PreviewFeatures.setVersion(25)` to use
>> JavaFX preview features from JavaFX 25. That method would unlock preview
>> features only if the version passed in matches the runtime feature version.
>> This would be in addition to the boolean system property.
>>
>> The question is whether it is worth the additional complexity (not for us to
>> implement, that's trivial unless I'm missing something), but rather than
>> documentation and burden on the app developer using a preview feature. The
>> docs for each new preview feature would need to link to the PreviewFeatures
>> utility class to describe how to unlock the features. On the plus side, it
>> would provide a common place to document how to unlock preview features --
>> "call this method from the application and set that system property on the
>> command line when running the app".
>
> I wouldn't be in favor of requiring application developers to call a method
> to unlock a preview API. It seems a bit too cumbersome and intrusive to me,
> since it requires you to embed build information into your source code. I've
> also never seen this in other libraries or frameworks.
> I wouldn't be in favor ... since it requires you to embed build information
> into your source code
That seems reason enough to abandon this idea.
> I've also never seen this in other libraries or frameworks.
True. Significantly, I didn't propose anything like this for the incubator
modules, which can have the same problem.
So I think this is a good minimal solution that provide a clue to the developer
that they are relying on API that is unstable and will change in the future
(meaning that using such API is a risk they need to be willing to take).
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1955355086
