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.
Gluon produces the maven releases, so Johan can probably answer the
question about the frequency of EA snapshots in maven central.
-- Kevin
On 2/6/2024 6:54 AM, Christopher Schnick wrote:
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 available in maven central
for 3 months that contained this new feature, so barely anyone used
it. As an application developer that likes to try out new features, I
would like to see more frequent maven releases, although I'm not sure
how much work that is and if it is automated. Even if it is not
possible to publish every early access release to maven, maybe push a
maven release out on important points during development of the
current release rather than in fixed intervals. One such important
point would have been the release of the platform preferences. I see
now that there is another ea release available on maven after a gap of
3 months, but that one does not contain the fix for Windows color
schemes, so any Windows ea user will get a nonfunctional feature.
Plus making maybe a small announcement when a new larger feature has
been released for the first time in early access and linking to the
appropriate maven release would result in a good real world test
coverage and discussions with other developers.
Best
Christopher
On 2/6/2024 8:32 AM, Robert Lichtenberger wrote:
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 Strauß:
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
