he platform
I think it's a win-win for everyone involved.
-andy
*From: *openjfx-dev on behalf
of Kevin Rushforth
*Date: *Friday, November 1, 2024 at 15:18
*To: *openjfx-dev
*Subject: *Re: Proposal: JavaFX Incubator Modules
you, the developers, have a chance to have your voice heard and acted
> upon by the platform
>
>
>
> I think it's a win-win for everyone involved.
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev on behalf of Kevin
> Rushforth
> *Dat
>>
>> - the proposed API and implementation are not final
>>
>> - you, the developers, have a chance to have your voice heard and acted
>> upon by the platform
>>
>>
>>
>> I think it's a win-win for everyone involved.
>>
>>
&g
2024 at 15:18
To: openjfx-dev
Subject: Re: Proposal: JavaFX Incubator Modules
I'm restarting the discussion from an earlier thread [0], along with a
PR to get the support for JavaFX incubator modules integrated ahead of
any particular feature that might use them.
JEP 11 [1] defines a p
The goal of incubating these or any other APIs is to get feedback from
applications developers as they use them, and be able to react to that
feedback with the freedom of being able to make incompatible changes. If
and when a feature is generally accepted, and we think the API is ready,
we woul
I can only second this. I haven't looked at the RichTextArea, but find
it extremely odd to hear that it also includes part of the input map
proposal instead of just a new Control/Skin/Behavior. Any changes to
how input maps work should be a separate proposal and PR.
--John
On 02/11/2024 00:
I think it should be made clear that incubation is not an alternative
to, or a path around community concensus. Specifically, I'm looking at
the RichTextArea proposal, which seems to also incubate the InputMap
proposal. If we accepted the incubation of incidental features without
community concensu
I'm restarting the discussion from an earlier thread [0], along with a
PR to get the support for JavaFX incubator modules integrated ahead of
any particular feature that might use them.
JEP 11 [1] defines a process for delivering non-final JDK APIs in
incubator modules.
Similarly, some JavaF
I updated the Incubator Modules proposal to address Phil's feedback,
along with updating the example incubator module:
https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
https://github.com/openjdk/jfx/pull/1375
-- Kevin
On 2/22/2024 2:32 PM, Kevin Rushforth wrote
Something like this might be reasonable as long as we also add "and
hasn't been modified in the current release". I could easily image the
case where an incubating feature goes into, say JavaFX 26 in March, and
by the time feedback comes in that prompts a change in the API, it's
July or August
W.r.t to (3) perhaps we could include in the write up an expectation
that continued incubation implies continued updates.
Meaning if there are no updates in a release then that either means it
is ready to be final next time round, or that the
author is no longer actively pursuing it and this shou
These are all good points.
1. I agree. This seems like a good idea for all the reasons you mention.
2. I'll add the additional information. And I like your suggestion to
require a JEP (*) to either drop or finalize an incubating feature.
3. Yes, I was deliberately vague on what constitutes a
1) The first thing that jumps out at me is the namespace : javafx.incubator
The JDK's JEP 11 says "An incubator module is identified by
the|jdk.incubator.|prefix in its module name"
It says the same about the packages inside the module.
"An incubating API is identified by the|jdk.incubator.|pre
13 matches
Mail list logo
