<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    These are all good points.<br>
    <br>
    1. I agree. This seems like a good idea for all the reasons you
    mention.<br>
    <br>
    2. I'll add the additional information. And I like your suggestion
    to require a JEP (*) to either drop or finalize an incubating
    feature.<br>
    <br>
    3. Yes, I was deliberately vague on what constitutes a reasonable
    amount of time. Given that we are changing the default to
    "re-incubate" it does make sense to have a "soft timeout" so
    incubating features don't incubate forever without an intentional
    action to keep them alive.<br>
    <br>
    I'll update the proposal accordingly.<br>
    <br>
    Thanks.<br>
    <br>
    -- Kevin<br>
    <br>
    (*) We don't exactly follow the JEP process as described in JEP 2,
    but for larger features we expect a proposal that touches on the
    important points in a JEP-like document and is discussed on the
    mailing list. That's what we mean when we say "needs a JEP".<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/21/2024 9:47 AM, Philip Race
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com">
      
      1) The first thing that jumps out at me is the namespace :
      javafx.incubator<br>
      <br>
      The JDK's JEP 11 says "<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">An
        incubator module is identified by the<span class="Apple-converted-space"> </span></span><code style="font-family: "DejaVu Sans Mono", "Bitstream Vera Sans Mono", "Luxi Mono", "Courier New", monospace; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">jdk.incubator.</code><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><span class="Apple-converted-space"> </span>prefix in its module
        name"<br>
        It says the same about the packages inside the module.<br>
        "</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">An
        incubating API is identified by the<span class="Apple-converted-space"> </span></span><code style="font-family: "DejaVu Sans Mono", "Bitstream Vera Sans Mono", "Luxi Mono", "Courier New", monospace; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">jdk.incubator.</code><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><span class="Apple-converted-space"> </span>prefix in its exported
        package names".</span><br>
      <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.333333px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><br>
        This is to avoid using the standard namespace prefixes for JDK
        of java. and javax. used for final APIs/modules.<br>
        <br>
        So similarly I think JavaFX incubators should avoid the javafx.
        prefix and I suggest "jfx." be used instead.<br>
        This closely mirrors the "jdk." used in JEP 11, taking "java"
        out of the prefix and making it entirely an acronym,<br>
        for both module and package names.<br>
        The pain of updating your code when the API goes final can be
        eased by IDEs and is something you would<br>
        need to do anyway because "incubator" is in all the names in
        either case.<br>
        <br>
        2) The second thing is you don't say what the steps are to
        promote the incubating module to final.<br>
        JEP 11 says a new JEP is needed for that, but it also says a new
        JEP is needed to re-incubate<br>
        which is something JavaFX will not require.<br>
        So do you expect it will be a new JEP for that ?<br>
        I think that would be best to do that as the JEP to propose the
        incubator could be several years old and stale by then.<br>
        You also don't say what it takes to drop it.<br>
        <br>
        So how about the basic process is that the first JEP simply
        proposes the incubating module, once<br>
        it is in as you say it evolves by normal RFEs across releases ?<br>
        Then when it is EITHER ready to go final OR be removed, a new
        JEP must be proposed for that.<br>
        A removal JEP should generally be quite short :-)<br>
        <br>
        So I suggest to add a sentence along those lines to the
        proposal.<br>
        "To either make the API of an incubating module final, or to
        remove it, then a new JEP should be submitted,<br>
        referencing the incubator JEP".<br>
        <br>
        3) The "reasonably small number of JavaFX releases" is I am sure
        intentionally vague, but perhaps<br>
        we could say<br>
        (1) Incubators which span beyond a 24 month period and are not
        yet ready will need<br>
        a simple public approval from the project lead to remain for
        some additiional period at the discretion<br>
        of the Project Lead by adding a simple comment in the JEP,
        otherwise the Project Lead will submit a removal JEP and<br>
        (2) the submitter of the JEP can propose to remove it at any
        time.<br>
        <br>
        -phil.<br>
      </span><br>
      <div class="moz-cite-prefix">On 2/21/24 9:37 AM, Kevin Rushforth
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com">JEP
        11 [1] defines a process for delivering non-final JDK APIs in
        incubator modules. <br>
        <br>
        Similarly, some JavaFX APIs would benefit from spending a period
        of time in a JavaFX release prior to being deemed stable. I
        propose JavaFX incubator modules as a means of putting non-final
        API in the hands of developers, while the API progresses towards
        either finalization or removal in a future release. This is
        especially useful for complex features with a large API surface.
        <br>
        <br>
        The JavaFX proposal is largely the same as the JDK one, but has
        some important differences. <br>
        <br>
        Please take a look at the preliminary proposal [2]. I have also
        created a Draft PR [3], for illustrative purposes only, to show
        how this might work. <br>
        <br>
        Please reply to this message with any feedback. <br>
        <br>
        Thanks. <br>
        <br>
        -- Kevin <br>
        <br>
        [1] <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/11" moz-do-not-send="true">https://openjdk.org/jeps/11</a>
        <br>
        [2]
        <a class="moz-txt-link-freetext" href="https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md" moz-do-not-send="true">https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md</a><br>
        [3] <a class="moz-txt-link-freetext" href="https://github.com/openjdk/jfx/pull/1375" moz-do-not-send="true">https://github.com/openjdk/jfx/pull/1375</a>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>