<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    There was a desire by some developers to keep JavaFX runnable with
    the most recent LTS of the JDK. I think it might be a harder sell to
    bump the minimum to 18. I'd love to hear from more developers on
    this.<br>
    <br>
    Regarding code snippets, as long as it doesn't break the build if we
    use them, I don't see why we can't start doing that (e.g., if the
    build fails with "unknown tag" or similar, that would be bad). We
    will produce any docs that we build and deliver using JDK 18 for
    now, and JDK 19 when we update the build to that (even though the
    minimum would remain at 17).<br>
    <br>
    As for future version bumps, my thinking is that we would do it at
    least after the next LTS or whenever there is an interesting feature
    we want to take advantage of.<br>
    <br>
    -- Kevin<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 7/19/2022 7:31 AM, Nir Lisker wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CA+0ynh9=AVL8BbUHvPLNCg8jkEzZjSga+FypqiN=rDc2xXHXjQ@mail.gmail.com">
      
      <div dir="ltr">Why is the bump to JDK 17 and not 18? In 18 the
        feature for Code Snippets in Java API Documentation was added
        and it could be useful for any new API.
        <div><br>
          <div>Is the plan to continue to pump the minimum version with
            every release or once in several? Does it depend on the
            benefit the new features add?</div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Jul 19, 2022 at 4:44
          PM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@oracle.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even
          though we build JavaFX binaries with JDK 18 as the boot JDK,
          the <br>
          latest version of JavaFX still runs with JDK 11 (and is
          capable of being <br>
          built using JDK 12 or later, and with some limitations, using
          JDK 11), <br>
          although it isn't tested with older JDK versions. In order for
          JavaFX to <br>
          be able to use newer JDK features, such as records, switch
          expressions, <br>
          text blocks, and so forth, we need to increase the minimum
          version of <br>
          the JDK that can run the latest JavaFX. Additionally, there is
          an <br>
          ongoing cost to keeping JavaFX buildable and runnable on older
          versions <br>
          of Java, and very little reason to continue to do so.<br>
          <br>
          To this end, I propose to bump the minimum version of the JDK
          needed to <br>
          run JavaFX 20 to JDK 17. I filed JDK-8290530 [1] to track
          this. This <br>
          will not affect update releases of earlier versions of JavaFX
          (e.g., <br>
          JavaFX 17.0.NN), which will continue to run with the same
          minimum JDK <br>
          that they run on today.<br>
          <br>
          As a reminder, we only assure that JavaFX NN will run with JDK
          NN-1 or <br>
          later, although in practice, we haven't bumped the minimum
          required JDK <br>
          version in several releases. So, while JavaFX 19 is built
          using JDK 18 <br>
          as the boot JDK, it produces class files that will run with
          JDK 11, <br>
          using "--source 11 --target 11". The proposed change discussed
          here <br>
          would update that in JavaFX 20 to "--source 17 --target 17".<br>
          <br>
          NOTE: this will not be an invitation to do wholesale
          refactoring of <br>
          existing classes or methods to use newer language features
          (e.g., a PR <br>
          that turns a bunch of existing data classes into records would
          not be <br>
          welcome). Rather, this can be seen as enabling judicious use
          of new <br>
          features in new code, much as we did when we started allowing
          the use of <br>
          "var".<br>
          <br>
          Absent a compelling reason to remain stuck in the past, I plan
          to send <br>
          out a pull request for this change next week.<br>
          <br>
          Comments are welcome.<br>
          <br>
          -- Kevin<br>
          <br>
          [1] <a href="https://bugs.openjdk.org/browse/JDK-8290530" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8290530</a><br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>