JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://jdk.java.net/20/ [3] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JDK 21: First Early-Access Builds When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a consequence, the first JDK 21 Early-Access builds have been published [7]. [4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [5] https://github.com/openjdk/jdk [6] https://github.com/openjdk/jdk20 [7] https://jdk.java.net/21/ ## Heads-up - Valhalla: LW4 Early-Access Builds Valhalla LW4 early-access builds have been published [8], those builds are primarily focused on implementing the Value Objects JEP draft [9]. For additional details on those EA builds, make sure to read these LW4 release notes [10]. For a more hands-on introduction to Value Object, you can watch the latest JEP Café: Java Value Objects in Action [11]. Interested developers are encouraged to explore the performance and migration impact of value objects on their applications, and to provide feedback to the valhalla-dev [12] mailing list. [8] https://jdk.java.net/valhalla/ [9] https://openjdk.org/jeps/8277163 [10] https://openjdk.org/projects/valhalla/early-access [11] https://inside.java/2022/12/06/jepcafe15/ [12] https://mail.openjdk.org/pipermail/valhalla-dev/ ## Heads-up - Generational ZGC: New Early-Access Builds New Generati
[Math] Towards 4.0
Hello. With all its dependencies having been released, are there any objections (or concerns) wrt the release of the next major version of "Commons Math"? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Towards 4.0
I would say go for it is you are 100% certain that all public and protected elements are the best they can be as a major release is the only time we can change them. Gary On Mon, Dec 12, 2022, 09:39 Gilles Sadowski wrote: > Hello. > > With all its dependencies having been released, are there any > objections (or concerns) wrt the release of the next major version > of "Commons Math"? > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Math] Towards 4.0
Le lun. 12 déc. 2022 à 15:50, Gary Gregory a écrit : > > I would say go for it is you are 100% certain that all public and protected > elements are the best they can be as a major release is the only time we > can change them. 100% I'm sure it isn't. ;-) Much work remains in order to reach desirable goals, API-wise, but it should not hold much longer a release that would provide the many improvements done over the years. Anyways, the idea would be to release a "beta" version so that a mistake such as you evoke (a "public" element that should be "private") could be corrected. [Of course that does not hold for code in "legacy" packages where by definition, work could not be completed to provide an improved API; yet functionality equivalent to CM 3.6.1. should still be available (for people who'd rather not depend on both "3.6.1" and "4.0").] Gilles > > Gary > > On Mon, Dec 12, 2022, 09:39 Gilles Sadowski wrote: > > > Hello. > > > > With all its dependencies having been released, are there any > > objections (or concerns) wrt the release of the next major version > > of "Commons Math"? > > > > Regards, > > Gilles > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Towards 4.0
I'd be happy with at least one beta release. Gary On Mon, Dec 12, 2022, 10:03 Gilles Sadowski wrote: > Le lun. 12 déc. 2022 à 15:50, Gary Gregory a > écrit : > > > > I would say go for it is you are 100% certain that all public and > protected > > elements are the best they can be as a major release is the only time we > > can change them. > > 100% I'm sure it isn't. ;-) > Much work remains in order to reach desirable goals, API-wise, but it > should not hold much longer a release that would provide the many > improvements done over the years. > Anyways, the idea would be to release a "beta" version so that a mistake > such as you evoke (a "public" element that should be "private") could be > corrected. [Of course that does not hold for code in "legacy" packages > where by definition, work could not be completed to provide an improved > API; yet functionality equivalent to CM 3.6.1. should still be available > (for > people who'd rather not depend on both "3.6.1" and "4.0").] > > Gilles > > > > > Gary > > > > On Mon, Dec 12, 2022, 09:39 Gilles Sadowski > wrote: > > > > > Hello. > > > > > > With all its dependencies having been released, are there any > > > objections (or concerns) wrt the release of the next major version > > > of "Commons Math"? > > > > > > Regards, > > > Gilles > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Math] Towards 4.0
I think a beta would be good. Ideally we would get some feedback from those migrating from CM3 to CM4 and there could be a chance to adjust the API. Alex On Mon, 12 Dec 2022 at 15:22, Gary Gregory wrote: > > I'd be happy with at least one beta release. > > Gary > > On Mon, Dec 12, 2022, 10:03 Gilles Sadowski wrote: > > > Le lun. 12 déc. 2022 à 15:50, Gary Gregory a > > écrit : > > > > > > I would say go for it is you are 100% certain that all public and > > protected > > > elements are the best they can be as a major release is the only time we > > > can change them. > > > > 100% I'm sure it isn't. ;-) > > Much work remains in order to reach desirable goals, API-wise, but it > > should not hold much longer a release that would provide the many > > improvements done over the years. > > Anyways, the idea would be to release a "beta" version so that a mistake > > such as you evoke (a "public" element that should be "private") could be > > corrected. [Of course that does not hold for code in "legacy" packages > > where by definition, work could not be completed to provide an improved > > API; yet functionality equivalent to CM 3.6.1. should still be available > > (for > > people who'd rather not depend on both "3.6.1" and "4.0").] > > > > Gilles > > > > > > > > Gary > > > > > > On Mon, Dec 12, 2022, 09:39 Gilles Sadowski > > wrote: > > > > > > > Hello. > > > > > > > > With all its dependencies having been released, are there any > > > > objections (or concerns) wrt the release of the next major version > > > > of "Commons Math"? > > > > > > > > Regards, > > > > Gilles > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] "maven site" fails
Hello. Running $ mvn clean package site [...] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site) on project commons-math-parent: Error parsing '/home/gilles/gilles/devel/java/apache/commons-math/trunk/src/site/xdoc/userguide/analysis.xml': line [20] Error parsing the model: processing instruction can not have PITarget with reserved xml name (position: IGNORABLE_WHITESPACE seen ...ons and\n limitations under the License.\n -->\n\n
Re: [Math] "maven site" fails
Deleting the line: Works. I had to do this for the statistics userguide. IIRC the stylesheet was empty there so it did not matter. However for math the style sheet contains some elements. It includes some styles that do not exist and the project.css which is empty apart from an import of a url that does not exist. So this minimal xsl may not do anything anyway. I would drop the wrote: > > Hello. > > Running > $ mvn clean package site > [...] > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site) > on project commons-math-parent: Error parsing > '/home/gilles/gilles/devel/java/apache/commons-math/trunk/src/site/xdoc/userguide/analysis.xml': > line [20] Error parsing the model: processing instruction can not have > PITarget with reserved xml name (position: IGNORABLE_WHITESPACE seen > ...ons and\n limitations under the License.\n > -->\n\n [...] > > Any idea? > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] "maven site" fails
Le lun. 12 déc. 2022 à 23:53, Alex Herbert a écrit : > > Deleting the line: > > > > Works. > > I had to do this for the statistics userguide. IIRC the stylesheet was > empty there so it did not matter. However for math the style sheet > contains some elements. It includes some styles that do not exist and > the project.css which is empty apart from an import of a url that does > not exist. So this minimal xsl may not do anything anyway. > > I would drop the > Alex > > On Mon, 12 Dec 2022 at 22:33, Gilles Sadowski wrote: > > > > Hello. > > > > Running > > $ mvn clean package site > > [...] > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site) > > on project commons-math-parent: Error parsing > > '/home/gilles/gilles/devel/java/apache/commons-math/trunk/src/site/xdoc/userguide/analysis.xml': > > line [20] Error parsing the model: processing instruction can not have > > PITarget with reserved xml name (position: IGNORABLE_WHITESPACE seen > > ...ons and\n limitations under the License.\n > > -->\n\n > [...] > > > > Any idea? > > > > Regards, > > Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] "mvn commons-build:download-page" fails with Java 11
Hello. Running $ JAVA_HOME=~/java/jdk/oracle/jdk1.8.0_333 mvn commons-build:download-page [...] [INFO] BUILD SUCCESS [...] Running $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/ mvn commons-build:download-page [...] [ERROR] Failed to execute goal org.apache.commons:commons-build-plugin:1.12:download-page (default-cli) on project commons-math4-core: Failed to execute: Executing Ant script: generate-xdocs.build.xml [download-page]: Failed to execute.: The following error occurred while executing this line: [ERROR] /tmp/plexus-ant-component18328128830526809687.build.xml:215: Unable to create javax script engine for javascript [...] Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
