From mark.reinhold at oracle.com Tue Sep 14 14:30:29 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 14 Sep 2021 07:30:29 -0700 Subject: Accelerating the JDK LTS release cadence Message-ID: <20210914073029.487804714@eggemoggin.niobe.net> Over on my blog today I?ve proposed shifting the JDK LTS release cadence from three years to two years: https://mreinhold.org/blog/forward-even-faster The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather than JDK 23 (in 2024). This change would, if accepted, have no effect on the main-line feature releases developed in the JDK Project [1]. Every such release is intended to be stable and ready for production use, whether it?s an LTS release or not [2]. This change would, however, affect the update releases produced in the JDK Updates Project [3]. That Project would have to take on a new LTS release line every two years rather than three, which would be more work, and also decide for how long to maintain each line. This change would also affect vendors who offer paid support for LTS releases, whether or not they participate in the JDK Updates Project. Given the potential to accelerate the entire Java ecosystem, however, in my view the additional work would be well justified. Comments? Questions? - Mark [1] https://openjdk.java.net/projects/jdk/ [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html [3] https://openjdk.java.net/projects/jdk-updates/ From forax at univ-mlv.fr Tue Sep 14 15:12:11 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 Sep 2021 17:12:11 +0200 (CEST) Subject: Accelerating the JDK LTS release cadence In-Reply-To: <20210914073029.487804714@eggemoggin.niobe.net> References: <20210914073029.487804714@eggemoggin.niobe.net> Message-ID: <1704119558.1100864.1631632331161.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "mark reinhold" > To: "discuss" > Sent: Mardi 14 Septembre 2021 16:30:29 > Subject: Accelerating the JDK LTS release cadence Hi Mark, > Over on my blog today I?ve proposed shifting the JDK LTS release cadence > from three years to two years: > > https://mreinhold.org/blog/forward-even-faster > > The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather > than JDK 23 (in 2024). > > This change would, if accepted, have no effect on the main-line feature > releases developed in the JDK Project [1]. Every such release is > intended to be stable and ready for production use, whether it?s an LTS > release or not [2]. > > This change would, however, affect the update releases produced in the > JDK Updates Project [3]. That Project would have to take on a new LTS > release line every two years rather than three, which would be more work, > and also decide for how long to maintain each line. > > This change would also affect vendors who offer paid support for LTS > releases, whether or not they participate in the JDK Updates Project. > > Given the potential to accelerate the entire Java ecosystem, however, > in my view the additional work would be well justified. > > Comments? Questions? As a user, i applaud the idea of having more choices but i've some concerns: - as a maintainer of some libraries, it will make my life more complex, because the ecosystem will not evolve in lockstep as it was before, i fear a scenario like Android were numerous LTS are used at the same time by different people making the choice when to upgrade quite complex. - as an OpenJDK member, we now that LTS has an impact of the development of the JDK, stewards are less available before a LTS, there are more migration documentations to write etc, so for me this proposed change will slow down the OpenJDK development not accelerate it. - some people will start to think in term of feature releases again when big features like Loom or Valhalla will land. I'm ok with a LTS without a big feature or a LTS with more than one big features but i fear that not everybody will agree on that. A 3 years is a long time, that shield us from that kind of discussions. > > - Mark regards, R?mi > > > [1] https://openjdk.java.net/projects/jdk/ > [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html > [3] https://openjdk.java.net/projects/jdk-updates/ From volker.simonis at gmail.com Tue Sep 14 17:07:06 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Sep 2021 19:07:06 +0200 Subject: Accelerating the JDK LTS release cadence In-Reply-To: <20210914073029.487804714@eggemoggin.niobe.net> References: <20210914073029.487804714@eggemoggin.niobe.net> Message-ID: On Tue, Sep 14, 2021 at 4:31 PM wrote: > > Over on my blog today I?ve proposed shifting the JDK LTS release cadence > from three years to two years: > > https://mreinhold.org/blog/forward-even-faster > > The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather > than JDK 23 (in 2024). > > This change would, if accepted, have no effect on the main-line feature > releases developed in the JDK Project [1]. Every such release is > intended to be stable and ready for production use, whether it?s an LTS > release or not [2]. > > This change would, however, affect the update releases produced in the > JDK Updates Project [3]. That Project would have to take on a new LTS > release line every two years rather than three, which would be more work, > and also decide for how long to maintain each line. > > This change would also affect vendors who offer paid support for LTS > releases, whether or not they participate in the JDK Updates Project. > > Given the potential to accelerate the entire Java ecosystem, however, > in my view the additional work would be well justified. > > Comments? Questions? > Hi Mark, this is an interesting proposal which definitely requires some in-depth discussion. One of the points which are not completely clear to me from your blog and Oracle's Java 17 Press Release [1] is how Oracle plans to contribute to the JDK Updates Project in the future? In [1], Oracle writes: "Oracle JDK 17 and future JDK releases are provided under a free-to-use license until a full year after the next LTS release. Oracle will also continue providing Oracle OpenJDK releases under the open-source General Public License (GPL), as it has since 2017." >From this sentence it is not clear to me if Oracle OpenJDK releases under GPL will also be provided by Oracle "until a full year after the next LTS release". Moreover, it is unclear if Oracle will only act for 6 month as Maintainer of the corresponding LTS update release in the JDK Updates Project (as it currently does for feature releases) or if it plans to extend its commitment as Maintainer of LTS update releases up to "until a full year after the next LTS release"? I would obviously greatly welcome Oracles decision to increase its engagement in the JDK Updates Project and I'm sure that such a decision will positively influence the reactions of the community for your proposal :) So can you please shed some light on Oracle's future plans regarding the involvement in the JDK Updates Project if your new LTS release cadence proposal will be accepted by the community? Thank you and best regards, Volker [1] https://www.oracle.com/news/announcement/oracle-releases-java-17-2021-09-14/ > - Mark > > > [1] https://openjdk.java.net/projects/jdk/ > [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html > [3] https://openjdk.java.net/projects/jdk-updates/ From mark.reinhold at oracle.com Tue Sep 14 17:58:54 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 14 Sep 2021 10:58:54 -0700 Subject: Accelerating the JDK LTS release cadence In-Reply-To: <1704119558.1100864.1631632331161.JavaMail.zimbra@u-pem.fr> References: <20210914073029.487804714@eggemoggin.niobe.net> <1704119558.1100864.1631632331161.JavaMail.zimbra@u-pem.fr> Message-ID: <20210914105854.634005385@eggemoggin.niobe.net> 2021/9/14 8:12:11 -0700, Remi Forax : > As a user, i applaud the idea of having more choices but i've some > concerns: > > - as a maintainer of some libraries, it will make my life more > complex, because the ecosystem will not evolve in lockstep as it was > before, i fear a scenario like Android were numerous LTS are used at > the same time by different people making the choice when to upgrade > quite complex. There is already a vast range of releases in use today -- including releases earlier than JDK 8. The ecosystem has never evolved in lockstep. I agree that it?s likely that there will be more LTS releases in active use than there are today. Thanks to changes we started making years ago, however, in particular the encapsulation of JDK internals [1], I don?t think that will be a big problem. Many library maintainers have found that once they move past JDK 8 it?s pretty easy to keep up with every six-month feature release, LTS or not. As a library maintainer you can choose a baseline JDK release depending upon the new features you want to use, and then stick to building with that baseline for years if you like. During that time, just make sure that it continues to run on the latest LTS release while still building with the baseline. Even better: Spread your effort out over time, and give your users the option of using non-LTS releases, by tracking every six-month feature release instead. > - as an OpenJDK member, we now that LTS has an impact of the > development of the JDK, stewards are less available before a LTS, > there are more migration documentations to write etc, so for me this > proposed change will slow down the OpenJDK development not accelerate > it. My perspective from inside Oracle is that most of us working on JDK 17 itself have spent hardly any more time on it at all as compared to the preceding non-LTS releases. We?ve been writing release notes, updating migration guides and other documentation, and so forth for every single six-month feature release. Do you have evidence to suggest that we?ve been less available? > - some people will start to think in term of feature releases again > when big features like Loom or Valhalla will land. I'm ok with a LTS > without a big feature or a LTS with more than one big features but i > fear that not everybody will agree on that. A 3 years is a long time, > that shield us from that kind of discussions. People who want big features to align with LTS releases are, in effect, arguing for a return to the old unpredictable feature-driven release model. We abandoned that model in 2017. Do you want to go back? There will always be discussions about which features are, or are not, or should be, or shouldn?t be, in a particular release. Let?s not be unduly distracted by them. - Mark [1] https://openjdk.java.net/jeps/403 From mark.reinhold at oracle.com Tue Sep 14 18:05:09 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 14 Sep 2021 11:05:09 -0700 Subject: Accelerating the JDK LTS release cadence In-Reply-To: References: <20210914073029.487804714@eggemoggin.niobe.net> Message-ID: <20210914110509.766399361@eggemoggin.niobe.net> 2021/9/14 10:07:06 -0700, volker.simonis at gmail.com: > ... > > So can you please shed some light on Oracle's future plans regarding > the involvement in the JDK Updates Project if your new LTS release > cadence proposal will be accepted by the community? Oracle engineers will continue to participate in the JDK Updates Project just as they do today. They will lead the first two update releases of each feature release, LTS or not, and then hand that maintainership over to other contributors, if any are interested. - Mark From simonisv at amazon.de Fri Sep 17 20:07:55 2021 From: simonisv at amazon.de (Simonis, Volker) Date: Fri, 17 Sep 2021 20:07:55 +0000 Subject: Accelerating the JDK LTS release cadence In-Reply-To: <20210914073029.487804714@eggemoggin.niobe.net> References: <20210914073029.487804714@eggemoggin.niobe.net> Message-ID: <1631909275833.63437@amazon.de> Hi Mark, On behalf of the Amazon Corretto team I?d like to express our support for the new JDK LTS release cadence proposal. We think this is the right step forward to keep the OpenJDK project vibrant and relevant with benefits for both developers and enterprises. The Corretto team will be happy to help out and take over new responsibilities in the OpenJDK Updates Project if endorsed by the OpenJDK community. Thank you and best regards, Volker & the Amazon Corretto team ________________________________________ From: discuss on behalf of mark.reinhold at oracle.com Sent: Tuesday, September 14, 2021 16:30 To: discuss at openjdk.java.net Subject: Accelerating the JDK LTS release cadence Over on my blog today I?ve proposed shifting the JDK LTS release cadence from three years to two years: https://mreinhold.org/blog/forward-even-faster The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather than JDK 23 (in 2024). This change would, if accepted, have no effect on the main-line feature releases developed in the JDK Project [1]. Every such release is intended to be stable and ready for production use, whether it?s an LTS release or not [2]. This change would, however, affect the update releases produced in the JDK Updates Project [3]. That Project would have to take on a new LTS release line every two years rather than three, which would be more work, and also decide for how long to maintain each line. This change would also affect vendors who offer paid support for LTS releases, whether or not they participate in the JDK Updates Project. Given the potential to accelerate the entire Java ecosystem, however, in my view the additional work would be well justified. Comments? Questions? - Mark [1] https://openjdk.java.net/projects/jdk/ [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html [3] https://openjdk.java.net/projects/jdk-updates/ Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From forax at univ-mlv.fr Sun Sep 19 18:44:51 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 19 Sep 2021 20:44:51 +0200 (CEST) Subject: Accelerating the JDK LTS release cadence In-Reply-To: <20210914105854.634005385@eggemoggin.niobe.net> References: <20210914073029.487804714@eggemoggin.niobe.net> <1704119558.1100864.1631632331161.JavaMail.zimbra@u-pem.fr> <20210914105854.634005385@eggemoggin.niobe.net> Message-ID: <2069528417.2941040.1632077091861.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "mark reinhold" > To: "Remi Forax" > Cc: "discuss" > Sent: Mardi 14 Septembre 2021 19:58:54 > Subject: Re: Accelerating the JDK LTS release cadence Sorry for the late answer, > 2021/9/14 8:12:11 -0700, Remi Forax : >> As a user, i applaud the idea of having more choices but i've some >> concerns: >> >> - as a maintainer of some libraries, it will make my life more >> complex, because the ecosystem will not evolve in lockstep as it was >> before, i fear a scenario like Android were numerous LTS are used at >> the same time by different people making the choice when to upgrade >> quite complex. > > There is already a vast range of releases in use today -- including > releases earlier than JDK 8. The ecosystem has never evolved in > lockstep. > > I agree that it?s likely that there will be more LTS releases in active > use than there are today. Thanks to changes we started making years > ago, however, in particular the encapsulation of JDK internals [1], I > don?t think that will be a big problem. Many library maintainers have > found that once they move past JDK 8 it?s pretty easy to keep up with > every six-month feature release, LTS or not. yes, > > As a library maintainer you can choose a baseline JDK release depending > upon the new features you want to use, and then stick to building with > that baseline for years if you like. During that time, just make sure > that it continues to run on the latest LTS release while still building > with the baseline. Even better: Spread your effort out over time, and > give your users the option of using non-LTS releases, by tracking every > six-month feature release instead. As a library maintainer, there are two factors, either i will upgrade when one of the dependency upgrade (by example Guava support Java 8+) or i will upgrade if a new feature allows me to have a better API (like lambdas). The former reason is why the ecosystem mostly evolve in lockstep, once several popular libraries target a new version of Java, most of the libraries move to that version. > >> - as an OpenJDK member, we now that LTS has an impact of the >> development of the JDK, stewards are less available before a LTS, >> there are more migration documentations to write etc, so for me this >> proposed change will slow down the OpenJDK development not accelerate >> it. > > My perspective from inside Oracle is that most of us working on JDK 17 > itself have spent hardly any more time on it at all as compared to the > preceding non-LTS releases. We?ve been writing release notes, updating > migration guides and other documentation, and so forth for every single > six-month feature release. Do you have evidence to suggest that we?ve > been less available? I will not snitch on anyone :) > >> - some people will start to think in term of feature releases again >> when big features like Loom or Valhalla will land. I'm ok with a LTS >> without a big feature or a LTS with more than one big features but i >> fear that not everybody will agree on that. A 3 years is a long time, >> that shield us from that kind of discussions. > > People who want big features to align with LTS releases are, in effect, > arguing for a return to the old unpredictable feature-driven release > model. We abandoned that model in 2017. Do you want to go back? > > There will always be discussions about which features are, or are not, > or should be, or shouldn?t be, in a particular release. Let?s not be > unduly distracted by them. I agree. I've discussed with quite a lot of people during this week, most of them prefer a 2 year schedule for a LTS. 2 years is good for application developers, 3 years is better for library maintainers. There is at least 10x more application developers, so i will shut my big mouth. > > - Mark R?mi > > > [1] https://openjdk.java.net/jeps/403 From peter.lawrey at gmail.com Mon Sep 20 07:57:49 2021 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Mon, 20 Sep 2021 08:57:49 +0100 Subject: Accelerating the JDK LTS release cadence In-Reply-To: <20210914073029.487804714@eggemoggin.niobe.net> References: <20210914073029.487804714@eggemoggin.niobe.net> Message-ID: Hi, Java 11 to 17 seemed like a long time and we ended up supporting a pseudo LTS version Java 14 in between. A two years gap seems better. I assume Java 18, 19, and 20 will be just the short term supported status. i.e. nothing special about 19. Is there any particular reason September happens to be when LTS are occurring? Regards, Peter. On Tue, 14 Sept 2021 at 15:31, wrote: > Over on my blog today I?ve proposed shifting the JDK LTS release cadence > from three years to two years: > > https://mreinhold.org/blog/forward-even-faster > > The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather > than JDK 23 (in 2024). > > This change would, if accepted, have no effect on the main-line feature > releases developed in the JDK Project [1]. Every such release is > intended to be stable and ready for production use, whether it?s an LTS > release or not [2]. > > This change would, however, affect the update releases produced in the > JDK Updates Project [3]. That Project would have to take on a new LTS > release line every two years rather than three, which would be more work, > and also decide for how long to maintain each line. > > This change would also affect vendors who offer paid support for LTS > releases, whether or not they participate in the JDK Updates Project. > > Given the potential to accelerate the entire Java ecosystem, however, > in my view the additional work would be well justified. > > Comments? Questions? > > - Mark > > > [1] https://openjdk.java.net/projects/jdk/ > [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html > [3] https://openjdk.java.net/projects/jdk-updates/ > From jason.greene at redhat.com Mon Sep 20 15:25:23 2021 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 20 Sep 2021 10:25:23 -0500 Subject: GraalVM Capabilities Important to Native Java & Leyden Message-ID: Quarkus has been utilizing GraalVM in real-world native Java deployments for quite some time. Based on that experience, we recommend carrying over (adapting as required) specific capabilities essential to this use case. We feel all of these goals are consistent with the original Leyden announcement but wanted to affirm them, along with some supporting information we think is relevant. Thank you for considering our feedback. Native Java Goals ================= Minimal Footprint Comparable to Container Friendly Languages ------------------------------------------------------------ In a cloud environment, the base overhead of a JVM runtime is multiplied across many more process instances, introduced by the combination of the architectural decoupling required to embrace cloud orchestration (i.e., building a system using multiple microservices on Kubernetes vs. a single JVM app), as well as the need for horizontal elastic scalability, and the multiple instances per service required to respond to load and provide fault tolerance. Due to a large number of smaller sized processes and a lack of shareability in a container-isolated system, the base overhead introduced by executable code (both application and JVM components), metaspace, and other non-heap structures have a significant impact on the combined memory usage of the overall system, and the resulting container density achievable with a given set of resources. While other languages, such as Golang, have demonstrated reduced overhead ideal for this usage pattern, Java has shown mass appeal: a record of improving developer teams? productivity, a vibrant ecosystem of frameworks, and millions of developers with years of experience using the language. Ideally, those gains are not sacrificed to achieve the desired performance of a cloud-native runtime. Therefore, a native Java runtime should alter the chosen trade-offs (including API and potentially JLS changes) to fully realize an environment that combines the core Java language and a minimalist footprint. Instant Boot ------------ Also important in an elastic cloud environment, and even more so in a serverless functions environment, is the ability to cold start immediately on-demand, processing and returning data with minimal latency from a non-existent process to a fully operational process that has produced a reply. Such processes need to support a variance in life-span, potentially lasting for only a single request, to persisting for long periods of time processing many requests. This need encompasses two aspects. The first is the JVM startup itself is as minimal as possible, limiting the amount of JDK initialization code required to be executed. The second is that the application can start from some form of precomputed state, minimizing the amount of startup activity required to run. GraalVM Benefits to Preserve (and Enhance) ========================================== Closed-world Optimization ------------------------- GraalVM?s architectural decision to fully embrace closed-world optimization is essential to achieving the footprint goals above. Since microservice-style applications only use a subset of the JDK and the libraries they depend on, significant gains can be had by fine-grained elimination of unreachable dead code and fields. For that to be a reality, changes to the expectations of a Java runtime are required. Notably, dynamic code/class-loading offers limited benefits in an immutable container-based application yet prevents the significant gains that are ideal to the environment. Therefore, dynamic class definition should be disallowed, as is the case with GraalVM native image. Secondly, Java reflection targets should be explicitly declared in an opt-in manner to support minimal and partial inclusions of public and package-protected members. To do otherwise forces entire APIs to be included, which contradicts the desired objective to include only what is necessary for a small service. In a purpose-driven scenario, it?s not uncommon for a small percentage of an API surface to be used by an application. Build-time Static Initialization -------------------------------- Java?s facility of per-class initialization is heavily utilized in virtually all applications, resulting in the execution of hundreds to thousands of initializers, even in very simple scenarios. For example, the simple case of a plain Java ?Hello World? involves over 100 initializers. In addition to the added CPU cost executing a chain of per-class initializers, additional memory is required to retain one-time code (including dependencies), the associated metadata, and transient heap structures. GraalVM?s approach eliminates these costs by generating an optimal initial heap using the output of prerun static initializers. With build-time static initializers, compiled code output can exclude large swaths of code, including entire dependency trees. For example, suppose an application using Jackson pre-parses all JSON configuration into a standard Java collection style structure. In that case, the entire muli-megabyte Jackson dependency tree can be completely excluded from the resulting code output. The resulting initial content contains only the needed collection data and is stored in the binary image executable. On process launch, this initial heap content is mapped directly from the image into the process address space creating an instant working state with minimal initialization cost. Service implementations that capitalize on this technique have the ability to launch and respond to requests immediately with a pre-constructed heap, taking only a few milliseconds to complete a full cold start. Such an ability becomes important with elastic scalability since the ability to respond to new load is limited by the time to spin up functional services. The most extreme case being serverless scenarios where scaling occurs from zero, and cold start time is effectively added to the response time of a request. Of course, there are also scenarios where a static initializer or some portion of the initializer should be executed at runtime. GraalVM addresses this through configuration, although with Leyden, there is an opportunity to look at other approaches such as extending the language via a keyword or annotation to allow the developer to indicate the appropriate lifecycle phase for the initializer (build or runtime) or through an alternative mechanism such as dynamic constants (with appropriate language support) which could be similarly configured for an appropriate lifecycle phase. API to Influence Compilation Output ----------------------------------- Another important ability for native images is a build-time API to influence compilation output, allowing applications and runtime frameworks to dynamically assess and register the needs of the application. This is important since a framework is often in the best position to determine which application methods, fields, and types should be accessible through reflection. As an example, data serialization frameworks typically employ mapping annotations to mark which types are to be serializable and which methods or fields will be used later on during marshaling. Using this information, the framework can inform the native image compiler to register those members, avoiding the need to doubly declare type information, as well as the consistency problems it would entail. Another example is an agent-style monitoring framework. Under such a framework, a configured policy separate from source code might indicate which members of which types will be probed and should be retained (as opposed to eliminated or inlined) GraalVM provides such a mechanism through a rich Feature API, which covers these use-cases and others, and has been successfully used by Quarkus and other GraalVM supporting projects. Adaptation/Bridging Facilities and Tools ---------------------------------------- A challenge with using native Java is that developers will want to reuse existing Java libraries before they are updated to handle the new runtime target. Many of these libraries incorporate code with assumptions that the JVM is a fully dynamic environment supporting open-ended discovery and arbitrary code definition. Additionally, while discouraged, it?s not uncommon to see the usage of JDK internal APIs, some of which may not be present or may not support the same interactions in a native setting. To address this need, GraalVM includes a bytecode substitution feature, which allows Java developers the ability to adjust certain behavior of a library. This capability can be used to correct or replace usages of internal API (e.g., Unsafe), adjust discovery logic to be native friendly, correct OS-specific patterns, prune code with broken linkage, adjust JNI usage, and many other usage scenarios. While the ability to retrofit existing Java libraries effectively enables usage, ideally, the Leyden contracts would obviate the need for post-Leyden Java code to require it. This is desirable since built-in language semantics would offer improved readability, reliability, and robustness. That said, until such time that the Java community can react and fully update the ecosystem, there will be a need for some form of code adaptation facility, similar to GraalVM substitutions. However, such a facility does not have to be part of the JDK distribution. It could exist as an external community project and simply integrate with an OpenJDK SPI or act as an external compilation preprocessing step. From Martijn.Verburg at microsoft.com Mon Sep 20 22:47:29 2021 From: Martijn.Verburg at microsoft.com (Martijn Verburg) Date: Mon, 20 Sep 2021 22:47:29 +0000 Subject: Accelerating the JDK LTS release cadence In-Reply-To: <1631909275833.63437@amazon.de> References: <20210914073029.487804714@eggemoggin.niobe.net> <1631909275833.63437@amazon.de> Message-ID: Hi, Mark/Volker/All, Microsoft believes in the end-user and operator benefits that modern Java brings. Therefore, we would also like to endorse the 2-year LTS proposal for builds of OpenJDK. Since most of the end-user ecosystem prefers to have the extra stability of an LTS, this is a great way to encourage them with their modernization efforts! Microsoft is willing to commit to helping maintain the various LTS updates projects as they move through their natural lifecycles. As a side note, .NET has a 2-year LTS cycle, so this makes double sense to us :-). Cheers, Martijn (and the MSFT Java Engineering Group) NOTE: My working day may not be your working day! Please don?t feel obliged to read or reply to this e-mail outside of your normal working hours. ________________________________ From: discuss on behalf of Simonis, Volker Sent: Friday, September 17, 2021 21:07 To: mark.reinhold at oracle.com ; discuss at openjdk.java.net Subject: [EXTERNAL] Re: Accelerating the JDK LTS release cadence Hi Mark, On behalf of the Amazon Corretto team I?d like to express our support for the new JDK LTS release cadence proposal. We think this is the right step forward to keep the OpenJDK project vibrant and relevant with benefits for both developers and enterprises. The Corretto team will be happy to help out and take over new responsibilities in the OpenJDK Updates Project if endorsed by the OpenJDK community. Thank you and best regards, Volker & the Amazon Corretto team ________________________________________ From: discuss on behalf of mark.reinhold at oracle.com Sent: Tuesday, September 14, 2021 16:30 To: discuss at openjdk.java.net Subject: Accelerating the JDK LTS release cadence Over on my blog today I?ve proposed shifting the JDK LTS release cadence from three years to two years: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmreinhold.org%2Fblog%2Fforward-even-faster&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a82dDbMyZoLO%2BlKmySoMZws4oabreSt2k%2BqeWmJSf3A%3D&reserved=0 The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather than JDK 23 (in 2024). This change would, if accepted, have no effect on the main-line feature releases developed in the JDK Project [1]. Every such release is intended to be stable and ready for production use, whether it?s an LTS release or not [2]. This change would, however, affect the update releases produced in the JDK Updates Project [3]. That Project would have to take on a new LTS release line every two years rather than three, which would be more work, and also decide for how long to maintain each line. This change would also affect vendors who offer paid support for LTS releases, whether or not they participate in the JDK Updates Project. Given the potential to accelerate the entire Java ecosystem, however, in my view the additional work would be well justified. Comments? Questions? - Mark [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fprojects%2Fjdk%2F&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J5x%2BleQgj9kM3NcI3wjw1TR9JMqHjTLOIEArlxufVgw%3D&reserved=0 [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-dev%2F2021-May%2F005543.html&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sr2Re5Fw%2Bz8iuuHURugDlFZ%2BVB4rR2wgzT500bIh6Jk%3D&reserved=0 [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fprojects%2Fjdk-updates%2F&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zvuSm1k1D76JViYbCzwkI3zEUnvmuAfHj4mWvclFWUw%3D&reserved=0 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From gil at azul.com Mon Sep 20 23:59:46 2021 From: gil at azul.com (Gil Tene) Date: Mon, 20 Sep 2021 23:59:46 +0000 Subject: Accelerating the JDK LTS release cadence In-Reply-To: References: <20210914073029.487804714@eggemoggin.niobe.net> <1631909275833.63437@amazon.de> Message-ID: <99C8997C-8699-41D8-94F6-4C0E6674B090@azul.com> Hi Mark/Volker/Martijn/All, On behalf of Azul, I'd like to express our strong support for this proposal to move to a more frequent LTS cadence in OpenJDK. In our experience, most production environments tend to require a degree of expected longevity and stability in the versions they actually adopt, with a clear need for ongoing bugfixes & security updates but with no other (or absolutely minimal) changes or enhancements forced on them unless they expressly choose to more to later Java versions. Designated LTS releases serve this purpose well, offering both stability and a predictable, practical schedule that version change rollouts can be planned against, and with plenty of overlap in continuing update timeframes to facilitate non-urgent moves to newer versions. Having LTS versions [predictably] appear on a more frequent basis is a positive, and will likely accelerate the adoption of new Java features in production environments going forward. It does come with an extra maintenance burden for the community as a whole, but that burden is well worth it in our opinion. As we do with OpenJDK 7u, 8u, 11u, 13u, and 15u, Azul will continue to contribute to maintaining additional LTS releases in the OpenJDK updates project, and is happy to help meet the added burden that more frequent LTS releases may create. ? Gil. > On Sep 20, 2021, at 3:47 PM, Martijn Verburg wrote: > > Hi, Mark/Volker/All, > > > Microsoft believes in the end-user and operator benefits that modern Java brings. Therefore, we would also like to endorse the 2-year LTS proposal for builds of OpenJDK. Since most of the end-user ecosystem prefers to have the extra stability of an LTS, this is a great way to encourage them with their modernization efforts! > > > Microsoft is willing to commit to helping maintain the various LTS updates projects as they move through their natural lifecycles. > > > As a side note, .NET has a 2-year LTS cycle, so this makes double sense to us :-). > > > Cheers, > Martijn (and the MSFT Java Engineering Group) > > > NOTE: My working day may not be your working day! Please don?t feel obliged to read or reply to this e-mail outside of your normal working hours. > > ________________________________ > From: discuss on behalf of Simonis, Volker > Sent: Friday, September 17, 2021 21:07 > To: mark.reinhold at oracle.com ; discuss at openjdk.java.net > Subject: [EXTERNAL] Re: Accelerating the JDK LTS release cadence > > Hi Mark, > > On behalf of the Amazon Corretto team I?d like to express our support > for the new JDK LTS release cadence proposal. We think this is the > right step forward to keep the OpenJDK project vibrant and relevant > with benefits for both developers and enterprises. The Corretto team > will be happy to help out and take over new responsibilities in the > OpenJDK Updates Project if endorsed by the OpenJDK community. > > Thank you and best regards, > Volker & the Amazon Corretto team > ________________________________________ > From: discuss on behalf of mark.reinhold at oracle.com > Sent: Tuesday, September 14, 2021 16:30 > To: discuss at openjdk.java.net > Subject: Accelerating the JDK LTS release cadence > > Over on my blog today I?ve proposed shifting the JDK LTS release cadence > from three years to two years: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmreinhold.org%2Fblog%2Fforward-even-faster&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a82dDbMyZoLO%2BlKmySoMZws4oabreSt2k%2BqeWmJSf3A%3D&reserved=0 > > The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather > than JDK 23 (in 2024). > > This change would, if accepted, have no effect on the main-line feature > releases developed in the JDK Project [1]. Every such release is > intended to be stable and ready for production use, whether it?s an LTS > release or not [2]. > > This change would, however, affect the update releases produced in the > JDK Updates Project [3]. That Project would have to take on a new LTS > release line every two years rather than three, which would be more work, > and also decide for how long to maintain each line. > > This change would also affect vendors who offer paid support for LTS > releases, whether or not they participate in the JDK Updates Project. > > Given the potential to accelerate the entire Java ecosystem, however, > in my view the additional work would be well justified. > > Comments? Questions? > > - Mark > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fprojects%2Fjdk%2F&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J5x%2BleQgj9kM3NcI3wjw1TR9JMqHjTLOIEArlxufVgw%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-dev%2F2021-May%2F005543.html&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sr2Re5Fw%2Bz8iuuHURugDlFZ%2BVB4rR2wgzT500bIh6Jk%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fprojects%2Fjdk-updates%2F&data=04%7C01%7Cmartijn.verburg%40microsoft.com%7C36002d900603493a0b6108d97a16f6c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637675061328608920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zvuSm1k1D76JViYbCzwkI3zEUnvmuAfHj4mWvclFWUw%3D&reserved=0 > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 From aph at redhat.com Tue Sep 21 14:07:36 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Sep 2021 15:07:36 +0100 Subject: Accelerating the JDK LTS release cadence In-Reply-To: <20210914073029.487804714@eggemoggin.niobe.net> References: <20210914073029.487804714@eggemoggin.niobe.net> Message-ID: On 9/14/21 3:30 PM, mark.reinhold at oracle.com wrote: > Over on my blog today I?ve proposed shifting the JDK LTS release cadence > from three years to two years: > > https://mreinhold.org/blog/forward-even-faster > > The LTS release following JDK 17 would thus be JDK 21 (in 2023), rather > than JDK 23 (in 2024). > > ... > > Comments? Questions? Firstly, thank you very much for asking. I'm rather late to this party because I had to go away and think about the possible consequences and poll a few people. I've taken the time to move from my initial "Cool!" reaction to something more nuanced. TL/DR: The most obvious absence in this conversation is that of ISVs and end users. As developers of Java as well as users of it, we're perhaps biased in favour of new features, and we're less likely to feel the adverse effects of the upgrade treadmill. For that reason we should seek input from the broad Java community before making a decision that will affect everyone. >From my point of view as an engineer, moving to a two-year LTS cycle is broadly positive. There's a lot going on with Java development, and the time since JDK 11 has felt to me like a very long time to wait. Getting Loom, Panama, etc. into people's hands as part of an LTS would be good. However, we have to think about the wider Java community. Certifying libraries to run on a new Java release can take months of effort, and no-one is going to welcome having to do so more frequently. Also, many of our end users have been highly resistant to upgrading to new Java releases. As you know, many still use JDK 8, and some would continue to do so forever if they could. I don't want us to be releasing frequent "LTS" versions that few people use. That would cause the fragmentation of the Java community we really want to avoid. On the positive side, JEP 396 (Strongly Encapsulate JDK Internals by Default) should be a huge help, making it less likely that a JDK upgrade will break library compatibility. So, from me it's a rather nervous yes, but. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Mon Sep 27 11:09:04 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 27 Sep 2021 11:09:04 +0000 Subject: Call for Discussion: New Project: RISC-V Port Message-ID: Hi, We would like to propose a new project called "RISC-V Port". The goal of the project will be to provide a full featured port of OpenJDK on the RISC-V platform. The current project would only target Linux. RISC-V ISA is actually a family of related ISAs of which there are currently four base ISAs [1]. Those base ISAs can be combined with a set of standard extensions. RV64G and RV32G are defined as general-purpose ISAs. This port will support RV64GV, i.e., RV64G ISA plus the "V" standard extension for vector operations [2]. And the implementation will be fully compatible with RISC-V ISA specifications. This port may support other ISA variants like RV32G depending on community interest. We (Huawei Technologies) already have a complete (i.e. template interpreter, C1 and C2 JIT) RISC-V port. This work is based on a snapshot of JDK main-line on May 10, 2021 and has been pushed to the riscv-port-branch of jdk-sandbox: https://github.com/openjdk/jdk-sandbox/tree/riscv-port-branch We've passed JTReg tests on QEMU and HiFive Unleashed board. So it should be good enough to run most Java programs. The VectorAPI and ForeignAPI features are not supported for now. Support for vector operations is experimental, we need to do more testing for this part. We've provided full build instructions [3], but we'll help you if you get stuck. Aleksey Shipilev is building riscv-port-branch nightlies here [4]. We want people to try it out. We intend to rebase the source code to the latest JDK mainline, and then, after a round of in-project reviews, suggest it for integration into JDK mainline. If this project is approved, I believe we still have time to submit the integration JEP targeting JDK 18. We would welcome your advice and guidance about this. We will consider 17u and 11u backports, after JDK mainline integration is done. This, of course, depends on whether the 17u and 11u maintainers would approve such backport. I propose myself, Fei Yang as a Project Lead of this new project. If you're interested or want to be the committer, please drop me a message. I have been working on OpenJDK for aarch64 port project since year 2015 and is an OpenJDK committer [5]. I am currently a major developer for OpenJDK RISC-V port and has reviewed most of the code changes internally. Previously, I am also a GCC committer [6] and has contributed various performance and bugfixes since year 2013. The proposed initial set of reviewers are: Fei Yang Aleksey Shipilev Edward Nevill Other contrbutors who are not listed on OpenJDK Census include: Yadong Wang Feilong Jiang Taiping Guo Yanhong Zhu Kuai Wei Xiaolin Zheng These people will be nominated to the proper community roles starting from Authors once this project is formed. Comments, expressions of interest etc. are welcome. Thanks, Felix [1] https://github.com/riscv/riscv-isa-manual [2] https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf [3] http://cr.openjdk.java.net/~fyang/openjdk-riscv-port/BuildRISCVJDK.md [4] https://builds.shipilev.net/openjdk-jdk-riscv [5] http://openjdk.java.net/census#fyang [6] https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS From shade at redhat.com Tue Sep 28 08:08:22 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Sep 2021 10:08:22 +0200 Subject: Call for Discussion: New Project: RISC-V Port In-Reply-To: References: Message-ID: On 9/27/21 1:09 PM, Yangfei (Felix) wrote: > Comments, expressions of interest etc. are welcome. I support adding this to mainline. As per "Proposing a New Project", at least one Group Lead must declare that their Group is a sponsor of the proposed Project: https://openjdk.java.net/projects/#new-project Since this seems to fall under Porters Group, like all other ports: https://openjdk.java.net/census#porters ...then maybe Dalibor can declare the sponsorship? -- Thanks, -Aleksey From adinn at redhat.com Tue Sep 28 12:49:50 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Sep 2021 13:49:50 +0100 Subject: Call for Discussion: New Project: RISC-V Port In-Reply-To: References: Message-ID: On 27/09/2021 12:09, Yangfei (Felix) wrote: > We would like to propose a new project called "RISC-V Port". I am not in a position to speak on behalf of Red Hat. However, speaking personally I support adding this porting project. I will not be able to contribute a lot of time to it but I will do my best to offer help and/or advice where I can. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From felix.yang at huawei.com Wed Sep 29 01:41:37 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 29 Sep 2021 01:41:37 +0000 Subject: Call for Discussion: New Project: RISC-V Port In-Reply-To: References:

Message-ID: Hi Andrew, > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Tuesday, September 28, 2021 8:50 PM > To: Yangfei (Felix) ; discuss at openjdk.java.net > Subject: Re: Call for Discussion: New Project: RISC-V Port > > On 27/09/2021 12:09, Yangfei (Felix) wrote: > > We would like to propose a new project called "RISC-V Port". > I am not in a position to speak on behalf of Red Hat. However, speaking > personally I support adding this porting project. I will not be able to > contribute a lot of time to it but I will do my best to offer help and/or advice > where I can. Thanks for your support. I want to emphasize that the experience of how the AArch64 port was done is immensely valuable for us working on this RISC-V port. I believe development and upstreaming of the AArch64 port will pave the way for this new proposed project. Thanks, Felix.