Kevin Rushforth"
Cc: openjfx-dev@openjdk.org
Betreff: Re: Preview features for JavaFX
As for the maven releases for EA snapshots: you're right, we're not building/publishing them weekly.
We have an increasing number of requests for builds for particular configurations, and with
Hi,
Just adding my 2 cents to the discussion.
I think there's a precedent to this that the JavaFX team was using back in
JavaFX 8 and before it. It wasn't for preview features, but it had a
somewhat similar purpose.
There was an "@treatAsPrivate" annotation. This annotation was used in
methods th
Hi,
I don't think it's possible to give a custom warning at compile time
without the user having a specific annotation processor active (ie, to
get the warning, they'd first need to set up an annotation processor
which FX provides). The problem here is that we can't enforce the use
of the an
Yes, something like an opt-in property might be workable and is worth
considering. We would also want to explore ideas for producing a
compile-time warning along with with a pattern to document them. I'm not
familiar enough with what you can do with annotations, but maybe there
is something the
As for the maven releases for EA snapshots: you're right, we're not
building/publishing them weekly.
We have an increasing number of requests for builds for particular
configurations, and with the more frequent LTS versions, the total build
processes are taking more time. All those builds are free,
Hi Kevin, Michael,
I think throwing an exception when using features that are preview
without a prerequisite property being present or set to some value would
be a good idea. JavaFX has quite a few properties already, and a
special one for previews would make it possible to ensure that such a
Hi Kevin,
my suggestion would be to annotate and document the preview API (at
least annotations do show up by default in most IDEs), and emit a
one-time runtime warning when the API is used (this works for methods
and constructors). This would make it quite visible to developers that
they are usin
Announcing new features and encouraging testing of those features is a
good idea. We should do that more often, especially in cases where
feedback on the API is important. Developers who are willing to download
the ea builds (SDK or JMODs) can do so right away, since builds are
published weekly
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
I would add that during the 6 month release cycle, there is usually some
time to get new features out in an ea release and receive early feedback
that way. Maybe even in time that it can be incorporated into the next
release if it is reasonable.
In this concrete case there was no ea build avai
Seems like a good idea to me. From an application developer point of
view I don't care if new parts are super-stable (they never really are).
If they are marked as preview I'll take that as an additional caveat to
not rely on API stability, etc.
Robert
Am 06.02.24 um 04:19 schrieb Michael St
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
12 matches
Mail list logo
