jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] JDK 25 feature set is now frozen!

[David D. <dav...@or...>]

Greetings and welcome to the June installment of the OpenJDK Quality Outreach update.

JDK 25, scheduled for General Availability on September 16, 2025, has entered Rampdown Phase One (RDP1)[1]. The JDK 25 feature set is now frozen (see JDK 25 details below), and only low-risk enhancements will be considered. Please help us identify potential issues in the coming weeks by testing your projects on JDK 25 EA builds. With enough lead time, we can resolve them before JDK 25 transitions to the Release Candidate phase in early August[2].

Be make sure to review the JDK 25 heads-ups below; two of them pertain to changes in file operations on Windows.

Last but certainly not least, you are invited to attend next week’s JCP EC online public meeting, where Alex Buckley will give a presentation on Tip & Tail Development—a topic particularly relevant for open-source project maintainers. See [3] for details, the meeting will be recorded.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-June/010191.html
[2] https://openjdk.org/projects/jdk/25/
[3] https://jcp.org/aboutJava/communityprocess/ec-public/materials/2025-06-10/JCP-EC-Public-Agenda-June-2025.html


# Heads-up - JDK 25: java.io.File.delete no longer deletes read-only files on Windows

`File.delete` has been changed on Windows so that it now fails and returns `false` for regular files when the DOS read-only attribute is set. Prior to JDK 25, `File.delete` would delete read-only files by first removing the DOS read-only attribute before attempting deletion. However, because removing the attribute and deleting the file are not a single atomic operation, this could result in the file remaining but with modified attributes if the deletion failed. Applications that depend on the previous behavior should be updated to clear the file attributes before deleting files.

To ease the transition, a system property has been introduced to restore the previous behavior. Running with `-Djdk.io.File.allowDeleteReadOnlyFiles=true` will cause `File.delete` to remove the DOS read-only attribute before attempting deletion, restoring the legacy behavior.

See https://bugs.openjdk.org/browse/JDK-8355954 for more details.


# Heads-up - JDK 25: File operations on Windows now always fail if the used name ends with a space

File operations on a path with a trailing space in a directory or file name, e.g. "C:\\SomeFolder\\SomeFile ", now fail consistently on Windows. For example. `File::mkdir` will return `false`, or `File::createNewFile` will throw `IOException` if an element in the path has a trailing space. Such pathnames are not legal on Windows. Prior to JDK 25, operations on a `File` created from such an illegal abstract pathname could appear to succeed when in fact they did not.

See https://bugs.openjdk.org/browse/JDK-8354450 for more details.


# Heads-up - JDK 25: Separate Metaspace and GC Printing

Historically the printing of Metaspace and GC logs have been combined; this was a result of permanent generation (PermGen) being a part of the GC Heap. However, Metaspace has replaced PermGen and resides in its own native memory location outside of the GC Heap. With Metaspace no longer a part of the GC Heap, the reason for combining the messaging no longer makes sense and could lead to confusion.

Starting with JDK 25, the way logging is tagged in the HotSpot JVM will change: although the content of the logs will remain the same, messages related to Metaspace will now use the existing Metaspace tag.

As part of this update, there are also some user-facing changes to `jcmd`. To better clarify that Metaspace is not part of the GC Heap, Metaspace information is no longer displayed with the `GC.heap_info` command. Instead, details about Metaspace memory usage have been moved to the `VM.metaspace` command.

See https://bugs.openjdk.org/browse/JDK-8356848 for more details.


# JDK 25

The JDK 25 early-access builds 25 are available[4] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here[5].

Please refer to the “Topics of Interest” section at the end of this update for additional information on JDK 25.

## JEPs integrated in JDK 25:
- JEP 470: PEM Encodings of Cryptographic Objects (Preview)
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port
- JEP 505: Structured Concurrency (5th Preview)
- JEP 506: Scoped Values
- JEP 507: Primitive Types in Patterns, instanceof, and switch (3rd Preview)
- JEP 508: Vector API (10th Incubator)
- JEP 509: JFR CPU-Time Profiling (Experimental)
- JEP 510: Key Derivation Function API
- JEP 511: Module Import Declarations
- JEP 512: Compact Source Files and Instance Main Methods
- JEP 513: Flexible Constructor Bodies
- JEP 514: Ahead-of-Time Command-Line Ergonomics
- JEP 515: Ahead-of-Time Method Profiling
- JEP 518: JFR Cooperative Sampling
- JEP 519: Compact Object Headers
- JEP 520: JFR Method Timing & Tracing
- JEP 521: Generational Shenandoah

## Changes in recent JDK 25 builds that may be of interest:
- JDK-8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures
- JDK-8354276: Strict HTTP header validation
- JDK-8356848: Separate Metaspace and GC printing
- JDK-8355954: java.io.File.delete no longer deletes read-only files on Windows
- JDK-8353440: Disable FTP fallback for non-local file URLs by default
- JDK-8354908: javac mishandles supplementary character in character literal
- JDK-8355360: -d option of jwebserver command should accept relative paths
- JDK-8354084: Streamline XPath API's extension function control
- JDK-8354305: SHAKE128 and SHAKE256 MessageDigest algorithms
- JDK-8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer
- JDK-8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException
- JDK-8322810: Lambda expression types can't be classes
- JDK-8352612: No way to add back lint categories after "none"
- JDK-8348732: SunJCE and SunPKCS11 have different PBE key encodings
- JDK-8350498: Remove two Camerfirma root CA certificates
- JDK-8350441: ZGC: Overhaul Page Allocation
- JDK-8347337: ZGC: String dedups short-lived strings
- JDK-8350279: HttpClient: Add a new HttpResponse method to identify connections
- JDK-8350753: Deprecate UseCompressedClassPointers
- JDK-8254622: Hide superclasses from conditionally exported packages
- JDK-8346465: Add a check in setData() to restrict the update of Built-In ICC_Profiles
- JDK-8347472: Correct Attribute traversal and writing for Code attributes
- JDK-8351654: Agent transformer bytecodes should be verified
- JDK-8348967: Deprecate security permission classes for removal
- JDK-8353642: Deprecate URL::getPermission method and networking permission classes for removal
- JDK-8353856: Deprecate FlighRecorderPermission class for removal
- JDK-8353614: JFR: jfr print --exact
- JDK-8346109: Create JDK taglet for additional preview notes
- JDK-8285888: Clarify that java.net.http.HttpClient do NOT support Digest authentication
- JDK-8350542: Optional.orElseThrow(Supplier) does not specify behavior when supplier returns null
- JDK-8342206: Convenience method to check if a constant pool entry matches nominal descriptors

Note: For a more exhaustive list of changes, please see here[6].

[4] https://jdk.java.net/25/
[5] https://jdk.java.net/25/release-notes
[6] https://github.com/openjdk/jdk/compare/jdk-25+17...jdk-25+25


# JavaFX 25 Early-Access Builds

These are early access builds of the JavaFX 25 Runtime, built from the openjdk/jfx repository. They enable JavaFX application developers to build and test their applications with JavaFX 25 on JDK 25. Although these builds are designed to work with JDK 25 EA, they are also compatible with JDK 22 and later versions.

The latest early access builds of JavaFX 25 Builds 18 (2025/5/23) are available[7], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 25 API Javadocs[8] are available too.

[7] https://jdk.java.net/javafx25/
[8] https://download.java.net/java/early_access/javafx25/docs/api/overview-summary.html


# JavaFX Direct3D 12 Early-Access Builds

These are early access builds of JavaFX from the "direct3d12" branch of the openjdk/jfx-sandbox repository[9], which implement the new Direct3D 12 graphics rendering pipeline for Windows x64. The goal of these EA builds is to solicit feedback as we work toward integrating this functionality into JavaFX. Binaries[10] are provided for convenience, so users do not need to build from source.

Feedback can be reported to the openjfx-dev mailing list[11]. These builds are provided under the GNU General Public License, version 2, with the Classpath Exception, and are based on an incomplete version of JavaFX 25.

[9] https://github.com/openjdk/jfx-sandbox/tree/direct3d12
[10] https://jdk.java.net/javafxdirect3d12/
[11] https://mail.openjdk.org/pipermail/openjfx-dev/


# Topics of Interest

- Java 25 Brings 18 JEPs - Inside Java Newscast
https://inside.java/2025/06/05/newscast-92/

- Strings Just Got Faster in JDK 25
https://inside.java/2025/05/01/strings-just-got-faster/

- What's new for JFR in JDK 25
https://egahlin.github.io/2025/05/31/whats-new-in-jdk-25.html

- Structured Concurrency Revamp in Java 25 - Inside Java Newscast
https://inside.java/2025/05/08/newscast-91/

- Where Is the Java Language Going?
https://inside.java/2025/04/20/javaone-future-java/

- Java for AI
https://inside.java/2025/05/03/javaone-java-ai/

- Pattern Matching in Java: Better Code, Better APIs
https://inside.java/2025/05/24/javaone-pattern-matching/

- Towards a JSON API for the JDK
https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145905.html

- Modern Java Development with Tip & Tail
https://inside.java/2025/05/17/javaone-tip-tail/

- Java 24, Faster Than Ever
https://inside.java/2025/05/17/javaone-faster-jdk24/

- “Ahead of Time Computation” with Dan Heidinga - Inside Java Podcast
https://inside.java/2025/05/16/podcast-036/

- “Stream Gatherers” with Viktor Klang - Inside Java Podcast
https://inside.java/2025/05/05/podcast-035/

- Garbage Collection in Java: The Performance Benefits of Upgrading
https://inside.java/2025/05/14/javaone-garbage-collection/

- JavaFX 24 and Beyond
https://inside.java/2025/05/10/javaone-javafx/

- JDK 24 Security Enhancements
https://seanjmullan.org/blog/2025/04/07/jdk24


~


This concludes the update for now. Should you experience any difficulties while testing your projects with the latest JDK early-access builds, just ping me.

PS: If you no longer wish to receive OpenJDK Quality Outreach updates, please let me know.

--David

[Jython-dev] OpenJDK Quality Outreach: Java 24 Is Now Available!

[David D. <dav...@or...>]

Greetings and welcome to the latest OpenJDK Quality Outreach update!

JDK 24 was officially released (General Availability) on March 18th during JavaOne. You can rewatch the Java 24 launch and the J1 keynote here [1]. Be sure to also check out the Quality Outreach section here [2]. JavaOne was amazing, and if you couldn't attend, make sure to watch the JavaOne 2025 playlist [3] regularly as sessions are gradually being added.

With the release of JDK 24, the focus now moves to JDK 25 testing. On that note, be sure to check out the heads-up below, with more to follow. And as always, if you experience any issues with your project running on a JDK 25 early-access builds, please don't hesitate to reach out.

[1] https://www.youtube.com/watch?v=mk_2MIWxLI0&t=12s
[2] https://www.youtube.com/live/GwR7Gvi80Xo?si=gxdqAhVbnNV0JZGt&t=2795
[3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzVV1xRJkRbcM2tOgVwytJAi


# Heads-up - JDK 25: New Null Checks in Inner Class Constructors

The Java Language Specification prescribes that various use sites of inner class constructors should include null checks of the immediately enclosing instance and from then on assumes that the reference is non-null. However, it does not mandate such checks of the incoming instance at the declaration site of these constructors and so core reflection, method handles, and direct bytecode invocation can pass null as enclosing instance, which can lead to NullPointerExceptions down the road.

Since a null enclosing instance is outside of the JLS and the future evolution of inner classes may lead to unexpected NPEs, Java 25 will start ensuring that references to the immediately enclosing instance are always non-null.

Starting with JDK 25, when javac is targeting release 25 or higher, it will emit null checks for the enclosing instances in inner class constructors.

This behavioral change will lead to new NPEs in code that uses core reflection, method handles, or direct bytecode invocation to pass null as enclosing instance. Such code is rare and usually found in libraries or frameworks (as opposed to in applications). It should be changed to no longer pass a null reference.

In case these additional checks lead to issues, their emission can be prevented with a flag: `-XDnullCheckOuterThis=(true|false)`. This should be seen as a temporary workaround and no guarantees are made for how long this flag will be available.

For more details, check JDK-8351274 [4].

[4] https://bugs.openjdk.org/browse/JDK-8351274


# JDK 25

The JDK 25 early-access builds 17 are available [5] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6].

The following JEPs have been targeted to JDK 25, so far:
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port

## Changes in recent JDK 25 builds that may be of interest:
- JDK-8353118: Deprecate the use of `java.locale.useOldISOCodes` system property
- JDK-8351435: Change the default Console implementation back to the built-in one in `java.base` module
- JDK-8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64
- JDK-8349583: Add mechanism to disable signature schemes based on their TLS scope
- JDK-8338675: javac shouldn't silently change .jar files on the classpath
- JDK-8319447: Improve performance of delayed task handling
- JDK-8341775: Duplicate manifest files are removed by jarsigner after signing
- JDK-8303770: Remove Baltimore root certificate expiring in May 2025
- JDK-8346948: Update CLDR to Version 47.0
- JDK-8348829: Remove ObjectMonitor perf counters
- JDK-8164714: Constructor.newInstance creates instance of inner class with null outer class
- JDK-8352716: (tz) Update Timezone Data to 2025b
- JDK-8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
- JDK-8345213: JVM Prefers /etc/timezone Over /etc/localtime on Debian 12
- JDK-8350646: Calendar.Builder.build() Throws ArrayIndexOutOfBoundsException
- JDK-8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal
- JDK-8328119: Support HKDF in SunPKCS11 (Preview)
- JDK-8327378: XMLStreamReader throws EOFException instead of XMLStreamException
- JDK-8024695: new File("").exists() returns false whereas it is the current working directory
- JDK-8351224: Deprecate com.sun.tools.attach.AttachPermission for removal
- JDK-8351310: Deprecate com.sun.jdi.JDIPermission for removal
- JDK-8348561: Add aarch64 intrinsics for ML-DSA
- JDK-8351266: JFR: -XX:StartFlightRecording:report-on-exit
- JDK-8350638: Make keyboard navigation more usable in API docs
- JDK-8350464: The flags to set the native priority for the VMThread and Java threads need a broader range
- JDK-8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native
- JDK-8347335: ZGC: Use limitless mark stack memory
- JDK-8348596: Update FreeType to 2.13.3

Note: A more exhaustive list of changes can be found here [7].

[5] https://jdk.java.net/25/
[6] https://jdk.java.net/25/release-notes
[7] https://github.com/openjdk/jdk/compare/jdk-25+10...jdk-25+17


# JavaFX 25 Early-Access Builds

These are early access builds of the JavaFX 25 Runtime built from openjdk/jfx [8]. These builds enable JavaFX application developers to build and test their applications with JavaFX 25 on JDK 25. Although these builds are designed to work with JDK 25-EA builds, they are also known to work with JDK 22 and later versions.

The latest early access builds of JavaFX 25 Builds 11 (2025/4/4) are now available [9], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 25 API Javadocs [10] are available too.

[8] https://github.com/openjdk/jfx
[9] https://jdk.java.net/javafx25/
[10] https://download.java.net/java/early_access/javafx25/docs/api/overview-summary.html


# Topics of Interest

- The Arrival of Java 24
https://blogs.oracle.com/java/post/the-arrival-of-java-24

- Performance Improvements in JDK 24
https://inside.java/2025/03/19/performance-improvements-in-jdk24/

- Java 24 - Better Language, Better APIs, Better Runtime
https://inside.java/2025/03/01/jfokus-better-jdk24/

- JDK 24 Release Notes Overview - Security Update
https://inside.java/2025/04/05/java-24-security-notes/

- JDK 24 Release Notes Review for Developers
https://inside.java/2025/03/13/newscast-87/

- JDK 24 Release Notes Overview for Operations
https://inside.java/2025/03/29/java-24-for-ops/

- JDK 24 G1/Parallel/Serial GC Changes
https://tschatzl.github.io/2025/04/01/jdk24-g1-serial-parallel-gc-changes.html

- Scoped Values in Java 24
https://inside.java/2025/02/27/newscast-86/

- Stable Values in Java 25
https://inside.java/2025/03/27/newscast-88/

- New Write Barriers for G1
http://tschatzl.github.io/2025/02/21/new-write-barriers.html

- SuperWord (Auto-Vectorization) - Scheduling
https://eme64.github.io/blog/2023/05/16/SuperWord-Scheduling.html

~

That's it for this time. Feel free to reach out if you encounter any issues while testing your project(s) with the latest JDK early-access builds.

--David

[Jython-dev] Query Regarding CVE-2024-3220

[Nandakrishnan P N <NAN...@ib...>]

Hello Jython-Dev,

I would like to know regarding the vulnerability of CVE-2024-3220 in jython. The description of the vulnerability is as follows:
“There is a defect in the CPython standard library module “mimetypes” where on Windows the default list of known file locations are writable meaning other users can create invalid files to cause MemoryError to be raised on Python runtime startup or have file extensions be interpreted as the incorrect file type. This defect is caused by the default locations of Linux and macOS platforms (such as “/etc/mime.types”) also being used on Windows, where they are user-writable locations (“C:\etc\mime.types”). To work-around this issue a user can call mimetypes.init() with an empty list (“[]”) on Windows platforms to avoid using the default list of known file locations.”

Link: https://nvd.nist.gov/vuln/detail/CVE-2024-3220
           https://access.redhat.com/security/cve/CVE-2024-3220

Can jython  be vulnerable to this ? If yes, is there any fix in plan?

>From my understanding, this is a low vulnerability and the level of vulnerability depends on how the user use jython. The work around for the issue is that, a user can call mimetypes.init() with an empty list. Please share your insights.

I’m new to jython-user group. Please let me know if there is  any other way to communicate these details.

Thanks & Regards
Nandakrishnan P N
Software Developer , IBM

[Jython-dev] JDK 24 Release Candidate | JavaOne and More Heads-Up

[David D. <dav...@or...>]

Welcome to the first OpenJDK Quality Outreach update of 2025!

The first Release Candidate builds of JDK 24 are now available [1] and tt this stage, only P1 issues will be evaluated. With the JDK 24 General Availability set for March 18th, the attention is now turning to JDK 25.

JDK 24 will officially launch at JavaOne in Redwood Shores, CA [2]. If you're attending or planning to attend JavaOne, please reach out as I’m planning a Quality Outreach gathering.

To conclude, make sure to take a look at the heads-up below.

[1] https://jdk.java.net/24/
[2] https://javaone.com/


# Heads-up - JDK 24: Remote Debugging with `jstat` and `jhsdb` is Deprecated for Removal

Java's Remote Method Invocation (RMI), introduced in 1997, enables remote procedure calls between different JVMs. RMI relies on serialization to encode objects into byte streams when sending them as arguments and return values between JVMs. Both technologies have long-term security issues and configuration challenges, and they haven't withstood the test of time. Today, the broader ecosystem has moved away from RMI in favor of more web-friendly protocols, and as a result, Java is also gradually reducing and eliminating its dependencies on it where possilbe.

Among other tools, Java offers these two tools to connect to a local HotSpot JVM and observe or debug it as well as the program it executes:

- `jstat` reads performance counters
- `jhsdb` provides snapshot debugging and analysis features

Both `jstat` and `jhsdb` offer remote capabilities, which are implemented using RMI. Due to the aforementioned effort to reduce dependencies on RMI, the remote capabilities of `jstat` and `jhsdb` are deprecated for removal in JDK 24:

- JDK-8327793 [3]: `jstatd` allows remote connections with jstat
- JDK-8338894 [4]: `jhsdb debugd` (allows remote connections with `jhsdb`) as well as the `--connect` option of the `jhsdb` subcommands `hsdb` and `clhsdb`

Please note that `jstat` and `jhsdb`'s capabilities for local use remain available and there are no plans to change that. It should also be mentionned that JFR (JDK Flight Recorder) offers a modern alternative for getting remote insights into a running HotSpot JVM.

Questions or feedback on these deprecations can be directed at the serviceability-dev mailing list [5] (subscription required).

[3] https://bugs.openjdk.org/browse/JDK-8327793
[4] https://bugs.openjdk.org/browse/JDK-8338894
[5] https://mail.openjdk.org/mailman/listinfo/serviceability-dev


# Heads-up - JDK 25: Proposal to Deprecate for Removal `-UseCompressedClassPointers`

## Reducing Code and Test Complexity

Shortly after the adoption of 64-bit architectures the `-XX:[-|+]UseCompressedClassPointers` and `-XX:[-|+]UseCompressedOops` arguments were added to provide Java users the ability to enable using 32-bit references even when on a 64-bit architecture. This reduces memory overhead and helps reduce cache misses. You can read more about this here [6].

Removing the `-UseCompressedClassPointers` option would make `+UseCompressedClassPointers` the default case and reduce the number of configurations that would need to be supported from three to two (`+UseCompressedClassPointers` and `+UseCompactObjectHeaders`). This would also significantly reduce code complexity as well as testing effort. Along with this, `-UseCompressedClassPointers` does not work well in a 64-bit architecture as can be seen here [7], it’s suspected there are many more examples.

## Minimal Benefit

The `-UseCompressedClassPointers` use rarely provides any tangible benefit to Java users. Any historical connection with the `-UseCompresseedOops`flag has long since been removed, and the net result of using `-UseCompressedClassPointers` is simply increased memory overhead.

## Reasons to Keep `-UseCompressedClassPointers`

There are currently two reasons to continue supporting `-UseCompressedClassPointers`:

- `-UseCompressedClassPointers` works well in 32-bit operating systems. However support for 32-bit operating systems is on its way out with JEP 479: 'Remove the Windows 32-bit x86 Port' [8] and JEP 501: 'Deprecate the 32-bit x86 Port for Removal' [9] which are both in forthcoming JDK 24.
- In cases where more than 5 million classes are loaded. However such cases are rare, likely the result of programmer error, and would also mean loading likely tens of GBs of non-class data into metaspace as well.

For more on this topic, check this thread [10] on the hotspot-dev mailing list.

The engineers working on this are considering marking `-UseCompressedClassPointers` as deprecated for removal in JDK 25 and are looking for feedback on the impact this could have. Please direct questions and feedback to the lilliput-dev [11] mailing list (registration required).

[6] https://stuefe.de/posts/metaspace/what-is-compressed-class-space/
[7] https://github.com/openjdk/jdk/pull/23053
[8] https://openjdk.org/jeps/479
[9] https://openjdk.org/jeps/501
[10] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html
[11] https://mail.openjdk.org/pipermail/lilliput-dev/


# Heads-Up - Distrust New TLS Server Certificates Issued by Camerfirma Root Certificates

The Java Cryptographic Roadmap has been updated to reflect how the JDK will stop trusting new TLS server certificates issued by Camerfirma, aligning with similar actions taken by Apple, Google, Microsoft, and Mozilla. In short, TLS Server certificates issued on or before April 15, 2025 will continue to be trusted until they expire while new certificates issued after that date will be rejected. JDK 24 will be one of the many versions affected by this change. For more details, please check the latest Java Cryptographic Roadmap [12].

[12] https://www.java.com/en/jre-jdk-cryptoroadmap.html


# Heads-Up - JavaFX Metal Early-Access builds

Early access builds of JavaFX that implement the new macOS Metal graphics rendering pipeline are now available [13]. These EA builds are provided as a convenience, so users don't have to build from the "metal" branch of the openjdk/jfx-sandbox repository [14]. The goal of these early access builds is to gather feedback as the team works on incorporating this feature into JavaFX. Feedback can be reported to the openjfx-dev mailing list [15] (subscription required). These builds are based on an incomplete version of JavaFX 25.

Moreover, the initial JavaFX 25 early-access builds are now also available [16].

[13] https://jdk.java.net/javafxmetal/
[14] https://github.com/openjdk/jfx-sandbox/tree/metal
[15] https://mail.openjdk.org/pipermail/openjfx-dev/
[16] https://jdk.java.net/javafx25/


# JDK 24 Release Candidates

The JDK 24 Release Candidate builds (builds 36) are available [17] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [18], and the javadocs here [19].

[17] https://jdk.java.net/24/
[18] https://jdk.java.net/24/release-notes
[19] https://download.java.net/java/early_access/jdk24/docs/api/


# JDK 25 Early-Access Builds

The JDK 25 early-access builds 9 are now available [20] and are provided under the GNU General Public License v2, with the Classpath Exception. The initial Release Notes are available here [21].

## Changes in recent JDK 25 builds that may be of interest:
- JDK-8347949: Currency method to stream available Currencies
- JDK-8344168: Change Unsafe base offset from int to long
- JDK-8347506: Compatible OCSP readtimeout property with OCSP timeout
- JDK-8346587: Distrust TLS server certificates anchored by Camerfirma Root CAs
- JDK-8345045: Remove the jmx.remote.x.buffer.size JMX notification property
- JDK-8345049: Remove the jmx.tabular.data.hash.map compatibility property
- JDK-8344976: Remove the jmx.invoke.getters compatibility property
- JDK-8345048: Remove the jmx.extend.open.types compatibility property
- JDK-8328919: Add BodyHandlers / BodySubscribers methods to handle excessive server input
- JDK-8344966: Remove the allowNonPublic MBean compatibility property
- JDK-8347596: Update HSS/LMS public key encoding
- JDK-8283795: Add TLSv1.3 and CNSA 1.0 algorithms to implementation requirements
- JDK-8225763: Inflater and Deflater should implement AutoCloseable
- JDK-8345432: (ch, fs) Replace anonymous Thread with InnocuousThread
- JDK-8345259: Disallow ALL-MODULE-PATH without explicit --module-path
- JDK-8335428: `ProcessBuilder` on Windows Quotes Argument Strings Containing Any Space Character
- JDK-8287788: Implement a better allocator for downcalls
- JDK-8344137: Update XML Security for Java to 3.0.5
- JDK-8334581: Remove no-arg constructor BasicSliderUI()
- JDK-8347965: (tz) Update Timezone Data to 2025a

Note: A complete list of changes can be found here [22].

[20] https://jdk.java.net/25/
[21] https://jdk.java.net/25/release-notes
[22] https://github.com/openjdk/jdk/compare/jdk-25+1...jdk-25+9


# Topics of Interest

Java Language Evolution in 2025
https://inside.java/2025/01/30/newscast-84/

Java's Plans for 2025
https://inside.java/2025/01/16/newscast-83/

A Deep Dive into JVM Start-up
https://inside.java/2025/01/28/jvm-start-up/

Modern Java Deep Dive
https://inside.java/2025/02/09/devoxxbelgium-modern-java-deepdive/

Java Performance Update
https://inside.java/2025/01/26/devoxxbelgium-java-perfromance-update/

Podcast - “Doc, JavaDoc and Markdown” with Jonathan Gibbons
https://inside.java/2025/01/21/podcast-034/

Evolution of Java Ecosystem for Integrating AI
https://inside.java/2025/01/29/evolution-of-java-ecosystem-for-integrating-ai/

Peaceful and Bright Future of Integrity by Default in Java
https://inside.java/2025/01/03/evolving-default-integrity/

James Gosling on Java - Historical Oddities & Persistent Itches #JVMLS
https://inside.java/2024/12/28/jvmls-jamesgosling/


~

I’d like to thank everyone who has already provided feedback on the JDK 25 builds. Your input is incredibly valuable, especially when received early in the development cycle. And if you encounter any issues, please ping me.

Hope to see some of you at JavaOne!

--David

[Jython-dev] JDK 24 Feature Freeze | Permanently Disabling the Security Manager

[David D. <dav...@or...>]

Welcome to the final OpenJDK Quality Outreach update of the year!

JDK 24, scheduled for General Availability on March 18, 2025 [1], is now in Rampdown Phase One (RDP1) [2]. At this point, the overall JDK 24 feature set is frozen and only low-risk enhancements might still be considered. You will find below the final list of the 24 JEPs that were integrated into JDK 24 as well as JDK 24 technical materials in the last section.

This QO update also covers 3 important heads-ups related to security, integrity and JDK 24.

The next key milestone is early February with the first JDK 24 Release Candidate builds. That means that we have a few weeks, modulo the end of year break, to find and hopefully address any issue that your projects might encounter. So, please let us know if you encounter any issue with the JDK early-access builds.

[1] https://openjdk.org/projects/jdk/24/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-December/009672.html


# Heads-up - JDK 24: Permanently Disabling the Security Manager

Introduced to enforce the principle of the least privilege, the Security Manager was designed to prevent unauthorized code from accessing sensitive resources (ex. files, network connections, etc.). While effective in theory, it has fallen short in practice for multiple reasons: complexity, limited adoption, maintenance overhead and evolving threat landscape.

In Java 17, the Security Manager was deprecated for removal under JEP 411 [3]. In JDK 24, its functionality will be effectively disabled via JEP 486 [4]. Key changes include:

- Disabling the Security Manager - it will no longer be possible to enable the SM at startup using command-line options, nor will it be possible to install a custom SM during runtime.
- Rendering the Security Manager API non-functional - the SM API will remain present for compatibility but will no longer have any operational effect.
- Improving maintainability - thousands of lines of code dedicated to supporting the Security Manager will be removed, freeing OpenJDK contributors to implement modern security features.

Developers and enterprises using older Java versions or legacy applications relying on the Security Manager will retain access until JDK 24. Beyond that, they are encouraged to transition to alternative sandboxing and API interception mechanisms.

## Call to Action

The deprecation of the Security Manager in JDK 17 had little to no impact on most Java developers. Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem, highlighting its limited relevance. Furthermore, major frameworks and tools (ex. Jakarta EE, Ant, Tomcat, etc.) have already removed support for the Security Manager, reinforcing the trend.

For applications still dependent on the Security Manager, the JDK offers options to identify and address its usage:

- jdeprscan [5] scans a JAR file for the usage of deprecated API elements, and it helps find code using these methods.
- Messages on the console warnings highlight Security Manager usage during runtime.
- Check how you launch your Java application - with the Security Manager allowed or enabled via command line options, or policy files that require it to be installed and configured.

These tools give code maintainers the necessary insights to transition away from the Security Manager before its complete removal in future JDK releases. By taking these steps, you will ensure a smooth transition from the Security Manager while adopting more effective security practices.

This is a summary; for more details, make sure to read JEP 486 [4].

[3] https://openjdk.org/jeps/411
[4] https://openjdk.org/jeps/486
[5] https://dev.java/learn/jvm/tools/core/jdeprscan/


# Heads-up - JDK 24: Prepares Restricted Native Access

Any interaction between Java code and native code, be it via the Java Native Interface (JNI) API or the Foreign Function & Memory (FFM) API, is risky in the sense that it can compromise the integrity of applications and of the Java Platform itself, for example by causing JVM crashes, even after the native code completed execution. According to the policy of integrity by default, all JDK features that are capable of breaking integrity must obtain explicit approval from the application’s developer. JDK 24, by means of JEP 472 [6], prepares that by aligning the behaviors of JNI and FFM by:

- Printing warnings for all restricted operations (with the goal to turn these into exceptions in a future release).
- Expanding the command-line options `--enable-native-access` and `--illegal-native-access` to govern restricted operations of both APIs.

Note that this is a change for JNI, which used to not trigger such warnings, as well as for FFM, which used to forbid restricted operations by default. Starting with JDK 24, both APIs behave uniformly by printing warnings. In the future, both APIs will throw exceptions instead. The intent is neither to discourage the use of, deprecate, or even remove JNI nor to restrict the behavior of native code called via JNI or FFM. The goal is to ensure that applications and the Java Platform have integrity by default while giving application operators the tools they need to selectively opt-out where needed.

This is a summary; for more details, please read the full Heads-Up [7] and JEP 472 [6].

[6] https://openjdk.org/jeps/472
[7] https://inside.java/2024/12/09/quality-heads-up/


# Heads-up - JDK 24: Security Properties Files Inclusion


Managing security properties across multiple JDK releases can be a challenge, particularly in environments requiring centralized control and distinct security profiles. To address this and starting with JDK 24, the Java Platform now allows the main security properties file (`${java.home}/conf/security/java.security`) or any file specified via the `java.security.properties` system property to include additional files. This inclusion is recursive, allowing for nested configurations, provided no cycles occur.

The `include` keyword is reserved and cannot be used to define security properties, as any attempt to do so results in an unchecked `IllegalArgumentException`.  The inclusion mechanism enhances security by explicitly listing files in the main configuration file, preventing misconfigurations by throwing a fatal error if a file is missing or inaccessible. It also forbids including directories or URLs, ensuring strict control over which files are included. Users must ensure proper permissions for included files to avoid tampering, such as enforcing secure file permissions. The system supports a clear priority for security property overrides based on the order of inclusion, and updates to a single file automatically propagate across all configurations.

This enhancement offers better control and adaptability over Java security properties for developers, system administrators and infrastructure engineers.

This is a summary; for more details, please read the full Heads-Up [8] and the JDK 24 release notes [9].

[8] https://inside.java/2024/12/10/quality-heads-up/
[9] https://jdk.java.net/24/release-notes#JDK-8319332


# JDK 24 Early-Access Builds

The JDK 24 early-access builds 28 are available [10] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [11].

## JEPs integrated into JDK 24:
- JEP 404: Generational Shenandoah (Experimental)
- JEP 450: Compact Object Headers (Experimental)
- JEP 472: Prepare to Restrict the Use of JNI
- JEP 475: Late Barrier Expansion for G1
- JEP 478: Key Derivation Function API (Preview)
- JEP 479: Remove the Windows 32-bit x86 Port
- JEP 483: Ahead-of-Time Class Loading & Linking
- JEP 484: Class-File API
- JEP 485: Stream Gatherers
- JEP 486: Permanently Disable the Security Manager
- JEP 487: Scoped Values (4th Preview)
- JEP 488: Primitive Types in Patterns, instanceof, and switch (2nd Preview)
- JEP 489: Vector API (9th Incubator)
- JEP 490: ZGC: Remove the Non-Generational Mode
- JEP 491: Synchronize Virtual Threads without Pinning
- JEP 492: Flexible Constructor Bodies (3rd Preview)
- JEP 493: Linking Run-Time Images without JMODs
- JEP 494: Module Import Declarations (2nd Preview)
- JEP 495: Simple Source Files and Instance Main Methods (4th Preview)
- JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
- JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
- JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
- JEP 499: Structured Concurrency (4th Preview)
- JEP 501: Deprecate the 32-bit x86 Port for Removal

## Changes in recent JDK 24 builds that may be of interest:
- JDK-8345015: Remove unused method lookup_time_t_function [Reported by JaCoCo]
- JDK-8344352: 32-bit builds crash after JDK-8305895 [Reported by JaCoCo]
- JDK-8344299: SM cleanup in javax.naming modules
- JDK-8343791: Socket.connect API should document whether the socket will be closed…
- JDK-8343001: Adjust XSLT and XPath Extension Function Property
- JDK-8341551: Revisit jdk.internal.loader.URLClassPath.JarLoader after JEP 486
- JDK-8340359: Remove javax.naming.Context.APPLET
- JDK-8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands
- JDK-8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation
- JDK-8341964: Add mechanism to disable different parts of TLS cipher suite
- JDK-8341553: Remove UseCompactObjectHeaders extra CDS archives
- JDK-8333582: Update CLDR to Version 46.0
- JDK-8341975: Unable to set encoding for IO.println, IO.print and IO.readln
- JDK-8342075: HttpClient: improve HTTP/2 flow control checks
- JDK-8326949: Authorization header is removed when a proxy Authenticator is set on HttpClient
- JDK-8245545: Disable TLS_RSA cipher suites
- JDK-8319993: Update Unicode Data Files to 16.0.0
- JDK-8343020: (fs) Add support for SecureDirectoryStream on macOS
- JDK-8335912: Add an operation mode to the jar command when extracting to not overwriting existing files
- JDK-8343881: java.lang.classfile.Attribute attributeName() method should return Utf8Entry
- JDK-8338021: Support new unsigned and saturating vector operators in VectorAPI
- JDK-8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory
- JDK-8341566: Add Reader.of(CharSequence)
- JDK-8338536: Permanently disable remote code downloading in JNDI
- JDK-8343004: Adjust JAXP limits
- JDK-8343150: Change URLClassLoader.getPermissions to return empty PermissionCollection

Note: A complete list of changes can be found here [12].

[10] https://jdk.java.net/24/
[11] https://jdk.java.net/24/release-notes
[12] https://github.com/openjdk/jdk/compare/jdk-24+21...jdk-24+28


# Topics of Interest

- Java 24 Performance Improvements & Deprecations
https://www.youtube.com/watch?v=oTc16DAMTqg

- Java 24 Language & API Changes
https://inside.java/2024/12/05/newscast-81/

- Java 24 Stops Pinning Virtual Threads (Almost)
https://inside.java/2024/11/21/newscast-80/

- Detoxifying the JDK Source Code
https://stuartmarks.wordpress.com/2024/12/12/detoxifying-the-jdk-source-code/

- Better Java Streams with Gatherers - JEP Cafe
https://inside.java/2024/11/26/jepcafe23/

- Java Language Futures - Fall 2024 Edition
https://inside.java/2024/10/30/devoxxbelgium-java-language-futures/

- Ask the Java Architects
https://inside.java/2024/11/14/devoxxbelgium-ask-architects/

- Pattern Matching in Java - Past, Present, Future
https://inside.java/2024/11/11/devoxxbelgium-pattern-matching/

- Monitoring Java Application Security with JDK tools and JFR Events
https://inside.java/2024/11/17/devoxxbelgium-security/

- ZGC Automatic Heap Sizing #JVMLS
https://inside.java/2024/11/09/jvmls-zgc/

- Postcards from the Peak of Complexity
https://inside.java/2024/11/03/devoxxbelgium-complexity-peak/

- Release Your (Java) Projects Like OpenJDK
https://inside.java/2024/10/31/newscast-79/

- Are Virtual Threads Going to Make Reactive Programming Irrelevant?
https://inside.java/2024/10/28/javazone-virtual-threads/

- A Sneak Peek at StableValue and SegmentMapper
https://inside.java/2024/10/24/devoxxbelgium-stablevalues/
- Advancing AI by Accelerating Java on Parallel Architectures
https://inside.java/2024/10/23/java-and-ai/


~

As always, ping me if you find any issues while testing your project(s) with the latest JDK early-access builds. And as the year-end is fast approaching, let me wish you all the best for the upcoming holidays. See you in 2025 with Java 24, JavaOne and Java 25!

PS: Please let me know if you don't want to receive these OpenJDK Quality Outreach updates anymore.

--David

[Jython-dev] JDK 23 Release Candidates | Restrictive JAXP Configuration Heads-up

[David D. <dav...@or...>]

Welcome to the latest OpenJDK Quality Outreach update!

Everything is on track for the General Availability of Java 23 on September 17th [1] as the JDK 23 Release Candidate builds (RC2 - builds 37) are now available [2]. And before shifting your attention to JDK 24, make sure to check the Heads-Up below as it is related to an important JAXP update in JDK 23.

The JVM Language Summit took place earlier this month in Santa Clara (California). During this unique conference, key updates around the Java platforms were presented and discussed. So, make sure to watch the JVMLS 2024 playlist [3] as videos are added regularly. And it's not really a surprise but Valhalla was a highly discussed topic. In his session [4], Brian Goetz (Java Language Architect) explained the proposed solution: value classes, null-restricted types, improved definite assignment analysis, and strict initialization. Around the same time-frame, Valhalla Early-Access builds implementing Value Classes and Objects were also made available [5], see the Release Notes [6] for the details. As usual, feedback should be reported to the proper mailing list [7].

[1] https://openjdk.org/projects/jdk/23/
[2] https://jdk.java.net/23/
[3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzUEYnTa6KYORRbP3nhsK0L1
[4] https://www.youtube.com/watch?v=IF9l8fYfSnI
[5] https://jdk.java.net/valhalla/
[6] https://openjdk.org/projects/valhalla/early-access
[7] https://mail.openjdk.org/mailman/listinfo/valhalla-dev


## Heads-up - JDK 23: Prepare for a More Restrictive JAXP Configuration

The Java platform supports XML processing with JAXP (Java APIs for XML Processing) that are based on a wide range of XML technologies and standards, which can make them challenging to secure. To mitigate risks, JAXP offers comprehensive security features [8], but the default settings of some security features are not strict, making them opt-in. To improve out-of-the-box security, future JDK releases will make XML processing more restrictive by default and JDKs 21 to 23 help developers prepare for these changes.

### JDK 21: JAXP Configuration File

JDK 21 added `$JAVA_HOME/conf/jaxp.properties` as the default JAXP configuration file, property settings in this file reflect the current, built-in defaults for the JDK. JDK 21 also added the system property `java.xml.config.file` for specifying the location of a custom configuration file. For details, refer to JDK-8303530 [9] or the `java.xml` documentation [10].

### JDK 23: Restrictive JAXP Configuration File Template

JDK 23 adds `$JAVA_HOME/conf/jaxp-strict.properties.template`, a JAXP configuration file template that specifies more restrictive XML processing settings. It is recommended to test applications on these more restrictive settings to prepare them for a future JDK release that has them as default.

The following steps should be used to test an application with that template:
* copy the template file to a location outside of `$JAVA_HOME/conf`, e.g. `/<my_path>/jaxp-strict.properties`
* run the application with the system property `java.xml.config.file` set to the file's path, e.g. `java -Djava.xml.config.file=/<my_path>/jaxp-strict.properties myApp`

For details, please refer to JDK-8330542 [11].

[8] https://docs.oracle.com/en/java/javase/22/security/java-api-xml-processing-jaxp-security-guide.html#GUID-6E76FE41-A8C5-4F56-AB46-83A89B1E904A
[9] https://bugs.openjdk.org/browse/JDK-8303530
[10] https://docs.oracle.com/en/java/javase/21/docs/api/java.xml/module-summary.html#Conf
[11] https://bugs.openjdk.org/browse/JDK-8330542


## JDK 24 Early-Access Builds

The JDK 24 early-access builds 12 are available [12], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [13].

### Changes in recent JDK 24 builds that may be of interest:
- JDK-8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception
- JDK-8329471: Remove GTK2
- JDK-8333772: Incorrect Kerberos behavior when udp_preference_limit = 0
- JDK-8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException …
- JDK-4966250: SSLSessionContext.setSessionTimeout() documentation could be updated
- JDK-8337506: Disable "best-fit" mapping on Windows command line
- JDK-8336479: Provide Process.waitFor(Duration)
- JDK-8336999: Verification for resource area allocated data structures in C2
- JDK-8335480: Only deoptimize threads if needed when closing shared arena
- JDK-8335939: Hide element writing across the ClassFile API
- JDK-8336489: Track scoped accesses in JVMCI compiled code
- JDK-8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
- JDK-8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation
- JDK-8333396: Use StringBuilder internally for java.text.Format.* formatting
- JDK-8336815: Several methods in java.net.Socket and ServerSocket do not s…

Note: A more exhaustive list of changes can be found here [14].

[12] https://jdk.java.net/24/
[13] https://jdk.java.net/24/release-notes
[14] https://github.com/openjdk/jdk/compare/jdk-24+7...jdk-24+12


# Project Loom New Early-Access Builds

The latest Loom early access builds (Builds 24-loom+3-33 -2024/7/27) are now available [15]. These builds, based on an incomplete version of JDK 24, improve the implementation of Java monitors (synchronized methods) to work better with virtual threads. These builds are intended for developers looking to "kick the tires" and provide feedback or bug reports. Feedback should be reported to the Loom mailing  list  [16] (subscription required).

[15] https://jdk.java.net/loom/
[16] http://mail.openjdk.org/mailman/listinfo/loom-dev


# JavaFX Early-Access Builds

These are early access builds of the JavaFX 23 and 24 Runtime built from openjdk/jfx [17]. These builds enable JavaFX application developers to build and test their applications with JavaFX 23 and 24 on JDK 23 and 24 respectively. And although these builds are designed to work with JDK 23 EA, they are also known to work with JDK 21 and later versions.

The latest early access builds of JavaFX 23 (Builds 27) are available [18], under the GNU General Public License, version 2, with the Classpath Exception. And similarly, the latest early access builds of JavaFX 24 (Builds 4) are available here [19].

[17] https://github.com/openjdk/jfx
[18] https://jdk.java.net/javafx23/
[19] https://jdk.java.net/javafx24/


## Topics of Interest

- JDK 23 G1/Parallel/Serial GC changes
https://tschatzl.github.io/2024/07/22/jdk23-g1-serial-parallel-gc-changes.html

- How to Read a JDK Enhancement Proposal
https://inside.java/2024/08/01/newscast-74/

- JFR Event to Detect Invocations of Deprecated Methods
https://egahlin.github.io/2024/05/31/deprecated-event.html

- JVMLS: Valhalla - Where Are We?
https://www.youtube.com/watch?v=IF9l8fYfSnI

- JVMLS: An Opinionated Overview on Static Analysis for Java
https://inside.java/2024/08/20/jvmls-static-analysis/

- JVMLS: Rethinking Java String Concatenation
https://inside.java/2024/08/19/jvmls-string-concatention/

- JVMLS: Project Babylon - Code Reflection
https://inside.java/2024/08/14/jvmls-code-reflection/

- JVMLS: A Code Reflection Example - Translating Java to SPIR-V
https://inside.java/2024/08/16/jvmls-spir-v/

- JVMLS: Java in 2024 Keynote
https://inside.java/2024/08/12/jvmls-keynote/


~


As always, please ping me if you encounter issues with an early-access build. And see you next month for the Java 23 launch!

--David

[Jython-dev] Jython 2.7.4 available

[Jeff A. <ja...@fa...>]

The project is happy to announce the general availability of Jython 
2.7.4 at https://www.jython.org/download .

v2.7.4 is a contains minor bug-fixes (thanks to all who contributed to 
triage and PRs) and security fixes by way of updated dependency JARs. 
Fuller details are at the link above, by following links on the page, 
and on our GitHub project.

-- 

Jeff Allen

Re: [Jython-dev] Hello from JRuby

[Jeff A. <ja...@fa...>]

Great to hear from you and what a kind offer. I agree with much of what 
you write about the value of a JVM implementation.

If you've poked around the project you may have noticed some efforts 
towards a Jython 3, while keeping a 2.7 alive. These aim to use the 
dynamic language features to full advantage. It's quite slow progress. 
Early invokedynamic resources, including some of your own, have been 
important for understanding how we might do this (thanks). It is clear 
that your role as an early adopter has helped shape the feature.

I'll reply with more specifics off-list.

Jeff Allen

On 01/08/2024 14:56, Charles Oliver Nutter wrote:
> Hello fellow JVM language developers!
>
> I am a co-lead of JRuby for many years, and have had some passing 
> connection with previous Jython maintainers: Tobias Ivarsson, Frank 
> Wierzbicki, and others. I am jumping on this list to ask how I might 
> help Jython in my capacity as a JVM language hacker. I am also 
> attempting to secure funding to keep JRuby development going, and I 
> would like to see if it's possible to do the same for Jython.
>
> Despite the enormous resources that have been poured into alternative 
> Ruby and Python implementations over the past decade, I still believe 
> that "pure" JVM implementations are valuable to both the communities 
> that use these languages and to the JVM language community in general. 
> JRuby, over the past twenty years, has remained the only alternative 
> Ruby implementation to ever see significant production deployment. 
> This is in large part because we adhere to some level of JVM purity: 
> we run on any JVM, on any platform, without commercial entanglements. 
> We also try to turn the challenges of implementing a JVM dynamic 
> language into opportunities for OpenJDK to improve; InvokeDynamic, 
> Panama, and Loom have in large part been answers to those challenges. 
> Jython has also proven itself, and even though it has fallen behind 
> standard Python and does not fully utilize modern JVM features, it 
> remains one of the great success stories of JVM dynamic languages.
>
> I believe Jython remains an important project. I'd like to do what I 
> can to help it move forward and become a viable target for modern 
> Python applications. Can we have a discussion about some shared future 
> for our two projects?
>
> *Charles Oliver Nutter*
> /Architect and Technologist/
> Headius Enterprises
> https://www.headius.com
> he...@he...

-- 

Jeff Allen

[Jython-dev] Hello from JRuby

[Charles O. N. <he...@he...>]

Hello fellow JVM language developers!

I am a co-lead of JRuby for many years, and have had some passing
connection with previous Jython maintainers: Tobias Ivarsson, Frank
Wierzbicki, and others. I am jumping on this list to ask how I might help
Jython in my capacity as a JVM language hacker. I am also attempting to
secure funding to keep JRuby development going, and I would like to see if
it's possible to do the same for Jython.

Despite the enormous resources that have been poured into alternative Ruby
and Python implementations over the past decade, I still believe that
"pure" JVM implementations are valuable to both the communities that use
these languages and to the JVM language community in general. JRuby, over
the past twenty years, has remained the only alternative Ruby
implementation to ever see significant production deployment. This is in
large part because we adhere to some level of JVM purity: we run on any
JVM, on any platform, without commercial entanglements. We also try to turn
the challenges of implementing a JVM dynamic language into opportunities
for OpenJDK to improve; InvokeDynamic, Panama, and Loom have in large part
been answers to those challenges. Jython has also proven itself, and even
though it has fallen behind standard Python and does not fully utilize
modern JVM features, it remains one of the great success stories of JVM
dynamic languages.

I believe Jython remains an important project. I'd like to do what I can to
help it move forward and become a viable target for modern Python
applications. Can we have a discussion about some shared future for our two
projects?

*Charles Oliver Nutter*
*Architect and Technologist*
Headius Enterprises
https://www.headius.com
he...@he...

[Jython-dev] JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!

[David D. <dav...@or...>]

Welcome to the OpenJDK Quality Outreach summer update.

JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high. That also means that the JDK 23 Initial Release Candidates are fast approaching, i.e., August 8th [3]! So, and in addition to testing your projects with the latest JDK 23 early-access builds, it is now a good time to start testing with the JDK 24 early-access builds.

Make sure to also check the heads-up below as some are related to JDK 23 and might have some impact, i.e., the first one being related to the eventual removal of the Security Manager and the second one discusses the removal of the legacy COMPAT locale provider.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html
[2] https://openjdk.org/jeps/3#rdp-2
[3] https://openjdk.org/projects/jdk/23/


## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security Manager

In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs, such as `AccessControlContext`, were deprecated for removal. The `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager related APIs even though they do not require Security Manager to be installed to use them.

As of JDK 23 [5], to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs' behavior depend on allowing the Security Manager:
- If the system property `java.security.manager` is set on the command line to the empty string, a class name, or the value `allow` then there is no behavior change compared to previous releases.
- If the system property `java.security.manager` is not set on the command line or has been set on the command line to the value `disallow`, invoking the `Subject.getSubject` method will throw `UnsupportedOperationException`.

Yet, running an application with `-Djava.security.manager=allow` is a temporary workaround to keep older code working. Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it with utmost priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make sure to check [5] and [6] for additional details.

The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating as soon as possible code that stores a `Subject` in an `AccessControlContext` and invokes `AccessController.doPrivileged` with that context. Such code will stop working when the Security Manager is removed.

[4] https://openjdk.org/jeps/411
[5] https://jdk.java.net/23/release-notes#b15
[6] https://inside.java/2024/07/08/quality-heads-up/
[7] https://dev.java/learn/jvm/tools/core/jdeprscan/


## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider

### A Quick History of Locale Data in the JDK

Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014:
- JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers:
   . JRE/COMPAT for the JDK’s legacy data collection (default)
   . CLDR for the CLDR data
   . a custom locale provider can be implemented
- JDK 9 picks CLDR by default
- JDK 21 issues a warning on JRE/COMPAT

There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 [8] lists a few of them.

### Locale Data in JDK 23

JDK 23 [9] removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect.

Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain:
- Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed.
- Implement a custom locale data provider [10].

For more details on that as well as on CLDR in the JDK in general, please check JEP 252 [8] that has been recently rewritten to provide better information and guidance.

[8] https://openjdk.org/jeps/252
[9] https://bugs.openjdk.org/browse/JDK-8325568
[10] https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html


## Heads-up - JDK 23:  Initial Leyden Early-Access Builds

Project Leyden published its first early-access builds (24-leyden+2-8 2024/6/20) [11]. The initial release is focused on improving Java applications start-up time, but other Leyden optimizations will be explored in future releases.

Below are some of the highlights of these Leyden EA builds:
- Ahead-of-time compilation of Java methods to natively execute them as soon as the application starts up in the production run;
- Ahead-of-time resolution of constant pool entries allows the AOT compiler to generate better code and for your application to start faster;
- Ahead-of-time generation of Dynamic Proxies and reflection data as frameworks use those extensively during start-up time;
- A unified Cache Data Store (CDS) archive to simplify the creation of the CDS archive, while supporting multiple types of optimization artifacts;
- Loaded Classes in the CDS archive as soon the application starts up;
- Class loader lookup cache to help application frameworks perform repeated lookups without repeatedly scanning the classpath;
- Archived Method Profiles to reach Java application peak performance faster.

The easiest way to start with Leyden features is by using the java program in the Leyden Early Access Release with the -XX:CacheDataStore flag. More details of this Leyden EA Build can be found in the release notes [12].

[11] https://jdk.java.net/leyden/
[12] https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md


## JDK 23 Early-Access Builds

The JDK 23 early-access builds 32 are available [13], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [14] and the Javadoc here [15].

[13] https://jdk.java.net/23/
[14] https://jdk.java.net/23/release-notes
[15] https://download.java.net/java/early_access/jdk23/docs/api/


## JDK 24 Early-Access Builds

The JDK 24 early-access builds 7 are available [16], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [17].

### Changes in recent JDK 24 builds that may be of interest:
- JDK-8334299: Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR
- JDK-8330846: Add stacks of mounted virtual threads to the HotSpot thread …
- JDK-8333649: Allow different NativeCall encodings
- JDK-8333755: NumberFormat integer only parsing breaks when format has suffix
- JDK-8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
- JDK-8327793: Deprecate jstatd for removal
- JDK-8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature
- JDK-8334580: Deprecate no-arg constructor BasicSliderUI() for removal
- JDK-8320448: Accelerate IndexOf using AVX2
- JDK-8333749: Consolidate ConstantDesc conversion in java.base
- JDK-8329141: Obsolete RTM flags and code
- JDK-8330198: Add some class loading related perf counters to measure VM startup
- JDK-8330699: Obsolete -XX:+UseEmptySlotsInSupers
- JDK-8334734: Remove specialized readXxxEntry methods from ClassReader

This is only a curated list, a complete list of changes can be found here [18].

[16] https://jdk.java.net/24/
[17] https://jdk.java.net/24/release-notes
[18] https://github.com/openjdk/jdk/compare/jdk-24+0...jdk-24+7


## Topics of Interest

- Integrity by Default - Inside Java Newscast
https://inside.java/2024/07/18/newscast-73/

- Java and AI? - Inside Java Newscast
https://inside.java/2024/07/04/newscast-72/

- What Happened to String Templates? - Inside Java Newscast
https://inside.java/2024/06/20/newscast-71/

- Java Language Futures - Spring 2024 Edition
https://inside.java/2024/07/01/java-language-futures/

- Project Loom - Structured Concurrency
https://inside.java/2024/07/13/structured-concurrency/

- How to Build Custom Java Runtimes with Jlink
https://inside.java/2024/06/21/build-runtimes-with-jlink/


## July 2024 Critical Patch Update Released

As part of the July 2024 CPU, Oracle released OpenJDK 22.0.2, JavaFX 22.0.2, JDK 22.0.2, JDK 21.0.4 LTS, JDK 17.0.12 LTS, JDK 11.0.24 LTS, JDK 8u421 as as well as JDK 8u421-perf.

~


We still have a few days before JDK 23 enters into the Release Candidate phase so please make sure to test your projects on the latest early-access builds and report any issue… but that shouldn't be a reason to not enjoy the summer and recharge your batteries! 😎

--David

[Jython-dev] JDK 23 Feature Freeze / New Loom EA builds

[David D. <dav...@or...>]

Welcome to the latest OpenJDK Quality Outreach update!

JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release!

This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html
[2] https://openjdk.org/projects/jdk/23/


## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used.

Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal).

[3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html
[4] https://openjdk.org/jeps/471


## Heads-Up - JDK 23: Changes Default Annotation Processing Policy

Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing.

### New `-proc` Value
To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values:
- `none`: compilation _without_ annotation processing, this policy exists since JDK 6
- `only`: annotation processing _without_ compilation, this policy exists since JDK 6
- `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it)

Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23.

### Migration to `-proc:full`

Several measures were undertaken to help projects prepare for the switch to `-proc:full`:
- As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`.
- Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected.

With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy.

Additional details can be found in the original proposal [5].

[5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html


## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads

Project Loom published new early-access builds [6]. These builds have an improved object monitor implementation that should prevent virtual threads from pinning their carrier thread in the following situations:
- when blocking on entering a synchronized method/statement because the object's associated monitor is held by another thread,
- when parking (e.g. when doing socket I/O) while in a synchronized method,
- when calling `Object.wait` while in a synchronized method.
The changes for `Object.wait`/timed-`wait` is the main change since the previous Loom EA build.

The Loom team is looking for help to test the changes, i.e., trying out these builds with code that is known to use virtual threads and with libraries that are "very synchronized". The primary goal is to gauge both reliability and performance. Right now, the focus is on being functional and reliable. Please note that the performance for some cases isn't yet fully on par with blocking on j.u.concurrent locks and condition objects.

As before, JFR events can be used to identify remaining cases of pinning, parking or blocking in a class initializer for example. The system property `jdk.tracePinnedThreads`, which used to print stack traces when threads are pinned, no longer outputs anything.

Please send feedback via email to the Loom mailing list [7] (subscription required).

[6] https://jdk.java.net/loom/
[7] http://mail.openjdk.org/mailman/listinfo/loom-dev


## JDK 23 Early-Access Builds

JDK 23 early-access builds 26 are now available [8] with the Release Notes here [9] and the javadocs here[10]. Those builds are provided under the GNU GPL v2, with the Classpath Exception.

### JEPs integrated into JDK 23:
- JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)
- JEP 466: Class-File API (2nd Preview)
- JEP 467: Markdown Documentation Comments
- JEP 469: Vector API (8th Incubator)
- JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
- JEP 473: Stream Gatherers (2nd Preview)
- JEP 474: ZGC: Generational Mode by Default
- JEP 476: Module Import Declarations (Preview)
- JEP 477: Implicitly Declared Classes and Instance Main Methods (3rd Preview)
- JEP 480: Structured Concurrency (3rd Preview)
- JEP 481: Scoped Values (3rd Preview)
- JEP 482: Flexible Constructor Bodies (2nd Preview)

### Changes in recent JDK 23 builds that may be of interest:
- JDK-8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
- JDK-8051959: Add thread and timestamp options to java.security.debug system property
- JDK-8321428: Deprecate for removal the package java.beans.beancontext
- JDK-8319990: Update CLDR to Version 45.0
- JDK-8331975: Enable case-insensitive check in ccache and keytab entry lookup
- JDK-8328083: degrade virtual thread support for GetObjectMonitorUsage
- JDK-8326666: Remove the Java Management Extension (JMX) Subject Delegation feature
- JDK-8295111: dpkg appears to have problems resolving symbolically linked native libraries
- JDK-8330077: Allow max number of events to be buffered to be configurable to avoid OVERFLOW_EVENT
- JDK-8332476: j.u.r.RandomGeneratorFactor.create(long|byte[]) should throw rather than silently fallback to no-arg create()
- JDK-8329113: Deprecate -XX:+UseNotificationThread
- JDK-8331202: Support for Duration until another Instant
- JDK-8316138: Add GlobalSign 2 TLS root certificates
- JDK-8330276: Console methods with explicit Locale
- JDK-8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module
- JDK-6968351: httpserver clashes with delayed TCP ACKs for low Content-Length
- JDK-8331021: Deprecate and then obsolete the DontYieldALot flag
- JDK-8330607: Deprecate -XX:+UseEmptySlotsInSupers
- JDK-8320522: Remove code related to `RegisterFinalizersAtInit`
- JDK-8329636: Deprecate -XX:+PreserveAllAnnotations
- JDK-8322234: Remove obsolete desktop integration from Linux installers
- JDK-8328649: Disallow enclosing instances for local classes in constructor prologues
- JDK-8330734: JFR: Re-engineer mirror class mechanism
- JDK-8300148: Consider using a StoreStore barrier instead of Release barrier on ctor exit
- JDK-8329997: Add provisions for checking memory segment alignment constraints
- JDK-8305457: Implement java.io.IO
- JDK-8321314: Reinstate disabling the compiler's default active annotation processing
- JDK-6942632: Hotspot should be able to use more than 64 logical processors on Windows
- JDK-8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull
- JDK-8206447: InflaterInputStream.skip receives long but it's limited to Integer.MAX_VALUE

Note: A more exhaustive list of changes can be found here [11].

[8] https://jdk.java.net/23/
[9] https://jdk.java.net/23/release-notes
[10] https://download.java.net/java/early_access/jdk23/docs/api/
[11] https://github.com/openjdk/jdk/compare/jdk-23+17...jdk-23+26


## New Jextract Early-Access Builds

New Jextract early-access builds have been made available [12]. These builds are based on JDK 22 and bring multiple enhancements. For additional details, make sure to check [13]. Moreover, a new jextract guide [14] has been published.

[12] https://jdk.java.net/jextract/
[13] https://mail.openjdk.org/pipermail/jextract-dev/2024-May/001699.html
[14] https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md


## JavaFX Early-Access Builds

These are early access builds of the JavaFX 23 Runtime built from openjdk/jfx [15]. These builds enable JavaFX application developers to build and test their applications with JavaFX 23 on JDK 23. Although these builds are designed to work with JDK 23EA, they are also known to work with JDK 21 and later versions.

The latest early access builds of JavaFX 23 are available here [16], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 23 API Javadocs [17] are also available.

[15] https://github.com/openjdk/jfx
[16] https://jdk.java.net/javafx23/
[17] https://download.java.net/java/early_access/javafx23/docs/api/overview-summary.html


## Topics of Interest

- All Java 23 Features - Inside Java Newscast
https://inside.java/2024/06/06/newscast-70/

- Module Imports in Java 23 - Inside Java Newscast
https://inside.java/2024/05/16/newscast-69/

- Java 23: JavaDoc Hits the Markdown on Comments - Inside Java Newscast
https://inside.java/2024/05/01/newscast-68/

- Java 23: Restoring the Balance with Primitive Patterns - Inside Java Newscast
https://inside.java/2024/04/04/newscast-66/

- Java in 2024 - Constant evolution, delivered.
https://inside.java/2024/06/01/java-in-2024-keynote/

- Introduction to JDK Mission Control
https://inside.java/2024/05/18/jmc-intro/

- What's New in JMC 9? - Sip of Java
https://inside.java/2024/04/21/sip096/

- Programmer's Guide to JDK Flight Recorder
https://inside.java/2024/04/12/programmer-guide-to-jfr/

- A Decade of JDK Updates in OpenJDK
https://inside.java/2024/04/09/a-decade-of-jdk-updates/

- Data-Oriented Programming - Version 1.1
https://inside.java/2024/05/23/dop-v1-1-introduction/


~

As usual, let us know if you find any issues while testing your project(s) with the latest JDK early-access builds.

Thank you!

--David

[Jython-dev] Jython 3 snapshot on APIdia

[Stefan R. <ste...@gm...>]

Dear Folks,

most of you probably got the APIdia announcement already via jython-user
(for those who didn't, it is appended below). Since this is the dev list, I
would like to point out that also a snapshot of the Jython 3 core (
github.com/jython/jython/tree/main) is available on APIdia at

https://apidia.net/java/Jython/3.0.0-snapshot

Jython 3 is pre-alpha and experimental, so it is not accessible by the
search on the landing page apidia.net -- just directly via the given link.


--- original announcement to jython-users ---

Dear Jythonistas, Jython and Java enthusiasts,

with this email I proudly announce that a new Java API documentation
website is in town and Jython is among the first projects being hosted.
Please check it out at

apidia.net/java/Jython

The documentation resembles Javadoc but with some improvements.

Perhaps most notably, it revives the package and class side navigation,
which Javadoc used to have until Java 12. (That was removed due to
deprecation of frames. On APIdia, it is implemented in a future-proof way.)
The search field was intended as a replacement, but I always felt that a
structured API navigation and a search field are really two things. To
address that, on APIdia you have both.

Similar to Javadoc, the search field searches names of classes/interfaces
etc., members, packages and modules. On APIdia, it also features regex
functionality (e.g. "|", "^", "$" work as "or", "start" and "end",
respectively) with following special rules: spaces are interpreted as ".*",
which means you can type space-separated snippets of a long name to quickly
specify your target. If the search text contains a ".", fully qualified
names are searched.

While you navigate through docs, the site maintains a parameterized url
that can serve as a link to the current view state.

As of this writing, APIdia hosts the full Java 22 standard library and
several hundred artifacts from Maven Central. In addition to Jython, that
includes Guava, all other Jython dependencies, Netty, Jetty, JavaFX,
Jakarta and Java EE artifacts, most of Apache commons and Spring to some
extent. All hosted projects are fully interlinked.

Various design details are improved over Javadoc. To name some, function
args have mouseover tooltip texts (if corresponding docs are available).
Summary lines are robust: sentences do not end prematurely with common
abbreviations like "e.g.", "i.e." and so on. Common patterns such as "Note:
...", "Warning: ...", "Issue: ..." etc. are rendered as proper admonition
boxes. Functions transparently indicate if some other function is
overridden, implemented, hidden or redeclared, whether and where from doc
is inherited, and whether deprecation is inherited.

In the top-right menu, you can edit visibility settings and turn on private
methods, internal packages and modules. If you check and uncheck the boxes,
the site adjusts the displayed content accordingly. So, if you want to hack
on Jython internals, this is the place for you.

With this functionality, the site is still lightweight and fast. Since it
is free of tracking, you won't be bothered by annoying cookie banners.

What's more to say? APIdia launched just days ago, so what it needs now is
users. If you like the site, please spread the word to your fellow devs and
kindly provide feedback, so it can improve.

Happy API documentation browsing!

Stefan

[Jython-dev] Java 22 is GA + Heads-up!

[David D. <dav...@or...>]

Welcome to the latest OpenJDK Quality Outreach update!

Java 22 was just released along with JavaFX 22 [1][2]. Thank you to all the projects who contributed to those releases by testing and providing feedback using their respective early-access builds. And to celebrate that, the Java DevRel Team hosted a +4h live-stream with guests such as Brian Goetz, Viktor Klang, Alan Bateman, etc. You can watch the launch stream replay here [3].

The JDK 23 schedule is now known [4] with rampdown starting early June and general availability sets for mid-September. So far, 2 JEPs have been targeted to JDK 23:
- JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [5]
- JEP 466: Class-File API (2nd Preview) [6]

The focus should now be shifted to testing your project(s) on JDK 23. And don't forget that the Oracle setup-java github action [7] supports, amongst others, the latest OpenJDK 23 Early-Access builds. So, JDK 23 EA testing is literally one pipeline away.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-March/008827.html
[3] https://jdk.java.net/javafx22/
[3] https://www.youtube.com/live/AjjAZsnRXtE?feature=shared&t=278
[4] https://openjdk.org/projects/jdk/23/
[5] https://openjdk.org/jeps/455
[6] https://openjdk.org/jeps/466
[7] https://github.com/oracle-actions/setup-java


## Heads-up: JDK 20-23: Support for Unicode CLDR Version 42

The JDK update to CLDR version 42 included a change where regular spaces in date/time formats (and some other formatted values) were replaced with (narrow) non-breaking spaces. This lead to issues for existing code that relied on parsing such strings. To address that, JDK 23 allows loose matching of spaces when parsing date/time strings. Loose matching is performed in the lenient parsing style for both date/time parsers in `java.time.format` and `java.text` packages. In the default strict parsing style, those spaces are considered distinct as before.

Please read this updated heads-up [9] for details on how to configure strict/lenient parsing in the `java.time.format` (strict by default) and `java.text` (lenient by default) packages.

[9] https://inside.java/2024/03/29/quality-heads-up/


## Heads-up: macOS 14 users running on Apple silicon systems should update directly to macOS 14.4.1

An issue introduced by macOS 14.4 caused some Java processes, regardless of the Java version, to terminate unexpectedly on Apple silicon (AArch64). On March 25 Apple released macOS 14.4.1 and indicated on their support site that it addresses this issue. Oracle can confirm that after applying macOS 14.4.1 we are unable to reproduce the problem. So, Java users on macOS 14 running on Apple silicon systems should skip macOS 14.4 and update directly to macOS 14.4.1.

More details can be found on https://blogs.oracle.com/java/post/java-on-macos-14-4


## JDK 23 Early-Access Builds

The JDK 23 EA builds 16 are available [10], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [11] are also available.

### Changes in recent JDK 23 builds that may be of interest:
- JDK-8324774: Add DejaVu web fonts (reported by AssertJ)
- JDK-8327385: Add JavaDoc option to exclude web fonts from generated documentation (reported by AssertJ)
- JDK-8328638: Fallback option for POST-only OCSP requests
- JDK-8320362: Load anchor certificates from Keychain keystore
- JDK-8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods
- JDK-8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs
- JDK-8327818: Implement Kerberos debug with sun.security.util.Debug
- JDK-7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream
- JDK-8319251: Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
- JDK-8327651: Rename DictionaryEntry members related to protection domain
- JDK-8321408: Add Certainly roots R1 and E1
- JDK-8164094: javadoc allows to create a @link to a non-existent method
- JDK-8325496: Make TrimNativeHeapInterval a product switch
- JDK-8174269: Remove COMPAT locale data provider from JDK
- JDK-8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because …
- JDK-8139457: Relax alignment of array elements
- JDK-8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly
- JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError when pattern is empty string
- JDK-8247972: incorrect implementation of JVM TI GetObjectMonitorUsage
- JDK-8325580: Remove "alternatives --remove" call from Java rpm installer
- JDK-8326838: JFR: Native mirror events
- JDK-8326106: Write and clear stack trace table outside of safepoint
- JDK-8323183: ClassFile API performance improvements
- JDK-8324829: Uniform use of synchronizations in NMT
- JDK-8326586: Improve Speed of System.map
- JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter
- JDK-8265372: Simplify PKCS9Attribute
- JDK-8317431: Implement simpler Comparator when building certification paths
- JDK-8327093: Add truncate function to BitMap API

Note: A more detailed list of changes can be found here [12].

[10] https://jdk.java.net/23/
[11] https://jdk.java.net/23/release-notes
[12] https://github.com/openjdk/jdk/compare/jdk-23+10...jdk-23+16


## JavaFX 23 Early-Access Builds

These are early access builds of the JavaFX 23 Runtime built from openjdk/jfx [13]. These builds enable JavaFX application developers to build and test their applications with JavaFX 23 on JDK 23. Although these builds are designed to work with JDK 23, they are also known to work with JDK 17 and later versions.

The latest early access builds of JavaFX 23 Builds 10 (2024/3/26) are available [14], under the GNU General Public License, version 2, with the Classpath Exception.

[13] https://github.com/openjdk/jfx
[14] https://jdk.java.net/javafx23/


## Topics of Interest:

- The Arrival of Java 22
https://inside.java/2024/03/19/the-arrival-of-java-22/

- JDK 22 Release Notes Review (video)
https://inside.java/2024/03/14/newscast-65/

- Java 22 in 2 Minutes
https://inside.java/2024/03/21/sip095/

- (Dirty?) Tricks in Java 22
https://inside.java/2024/02/29/newscast-64/

- JDK 22 Security Enhancements
https://seanjmullan.org/blog/2024/03/20/jdk22

- Java 17 to 21 - A Showcase of JDK Security Enhancements
https://inside.java/2024/03/03/jfokus-jdk-security-changes/

- Netflix - Bending Pause Times to Your Will with Generational ZGC
https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b

- MethodHandle Primer
https://jornvernee.github.io/methodhandles/2024/01/19/methodhandle-primer.html

- Pruning Dead Exception Handlers
https://jornvernee.github.io/hotspot/jit/2024/02/16/prune-dead-exception-handlers.html

- Update on String Templates (JEP 459)
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-March/004010.html

- The State of OpenJDK
https://inside.java/2024/02/23/fosdem2024-openjdk-state/

- Project Wakefield - The JDK Wayland Desktop on Linux
https://inside.java/2024/03/24/openjdk-wakefield/

- Project Leyden -  Capturing Lightning in a Bottle
https://inside.java/2024/02/28/leyden/

- jlink - Java's Custom Runtime Builder
https://inside.java/2024/02/25/jlink-stackwalker/

- Modern Java in Action
https://inside.java/2024/03/09/jfokus-modern-java-action/

- New Java Platform Extension for VS Code Release
https://inside.java/2024/03/27/vscode-extension-update/

~

That's it for this instalment. And don't forget to ping me if you encounter issues with JDK 23 EA builds.

--David

[Jython-dev] JDK 22 Release Candidates & Virtual Threads pinning heads-up

[David D. <dav...@or...>]

Welcome to the latest OpenJDK Quality Outreach update!

The first JDK 22 Release Candidates builds are now available [1]. At this stage, only P1 issues will still be evaluated. And with the JDK 22 General Availability set for March 19th, it is now time to fully focus on JDK 23. At the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But new JEP candidates [3][4] have recently been announced, so things should evolve rapidly.

I'd like to thank those of you who have already provided feedback on the JDK 22 EA builds. Feedback is always extremely useful, even more, when it comes early in the development cycle. Another area where we need your help is Loom. So, please make sure to check the heads-up below that discusses the so-called Virtual Threads "pinning" issue.

[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466


## Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been extremely well received by the Java ecosystem but there are still a few pain points. Much has been written about the so-called "pinning" issue that arises with synchronized methods or synchronized statements. The two most common cases are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized method, and (b) a virtual thread blocks entering a synchronized method because the object's associated monitor is held by another thread. In both cases, the underlying carrier/native thread is not "released" to do other work. Performance and scalability may suffer and in some cases, starvation and deadlock might happen. This recent "Virtual Threads Next Steps" video [5] explains in more details the why's and discusses some potential solutions.

New Loom early-access builds haven been recently published [6]. Those Loom EA builds have changes to the object monitor implementation that do not pin for these two common cases. The Loom team needs your help to test these updated object monitors with code that you know is using virtual threads and with libraries that are heavily synchronized. The goal is to gauge both reliability and performance.

The simplest way to report an issue or feedback is to use the Loom mailing list [7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current default) and `-XX:LockingMode=2` would be extremely helpful as that would exercise the two locking modes currently implemented by the HotSpot VM.

[5] https://inside.java/2024/02/17/virtual-threads-next-steps/
[6] https://jdk.java.net/loom/
[7] https://mail.openjdk.org/pipermail/loom-dev/


## JDK 22 Release Candidates

The JDK 22 Release Candidate builds (builds 36) are available [8] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [9], and the javadocs here [10].

[8] https://jdk.java.net/22/
[9] https://jdk.java.net/22/release-notes
[10] https://download.java.net/java/early_access/jdk22/docs/api/


## JDK 23 Early-Access Builds

The JDK 23 Early-Access builds 10 are available [11], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [12].

### Changes in recent JDK 23 builds that may be of interest:

- JDK-8324287: Record total and free swap space in JFR
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8324665: Loose matching of space separators in the lenient date/time parsing mode
- JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow
- JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern
- JDK-8325221: Obsolete TLABStats
- JDK-8322535: Change default AArch64 SpinPause instruction
- JDK-8323746: Add PathElement hashCode and equals
- JDK-8325570: Update to Graphviz 9.0.0
- JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8324068: Improve references to tags in the Doc Comment Spec
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8321545: Override toString() for Format subclasses
- JDK-8324301: Obsolete MaxGCMinorPauseMillis
- JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1
- JDK-8324771: Obsolete RAMFraction related flags
- JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa…
- JDK-8325150: (tz) Update Timezone Data to 2024a
- JDK-8324571: JDK 23 L10n resource files update

Note: Complete list of changes can be found here [13].

[11] https://jdk.java.net/23/
[12] https://jdk.java.net/23/release-notes
[13] https://github.com/openjdk/jdk/compare/jdk-23+6...jdk-23+10


## JavaFX Early-Access Builds:

These are early access builds of the JavaFX 22 & 23 Runtime built from openjdk/jfx [14]. These builds enable JavaFX application developers to build and test their applications with JavaFX 22 & 23 on JDK 22 & 23 respectively. Although these builds are designed to work with JDK 22 and above, they are also known to work with JDK 17 and later versions.

The latest early access builds of JavaFX 22 Builds 29 are available [15], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 22 API Javadocs [16] are also available.

The latest early access builds of JavaFX 23 Builds 5 are available [17], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 23 API Javadocs [18] are also available.

[14] https://github.com/openjdk/jfx
[15] https://jdk.java.net/javafx22/
[16] https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html
[17] https://jdk.java.net/javafx23/
[18] https://download.java.net/java/early_access/javafx23/docs/api/overview-summary.html


## Topics of Interest

- Java Renaissance Keynote
https://inside.java/2024/02/05/java-renaissance/

- Managing Throughput with Virtual Threads - Sip of Java
https://inside.java/2024/02/04/sip094/

- Data-Oriented Programming in Java 21 - JEP Café
https://inside.java/2024/02/08/jepcafe22/

- Does Java 22 Kill Build Tools? - Inside Java Newscast
https://inside.java/2024/02/15/newscast-63/

- JDK 22 G1/Parallel/Serial GC changes
https://tschatzl.github.io/2024/02/06/jdk22-g1-parallel-gc-changes.html

- Java 22 Previews Statements Before super(...) and this(...)
https://inside.java/2024/02/01/newscast-62/

- State of jextract
https://cr.openjdk.org/~mcimadamore/panama/jextract_changes.html

- FOSDEM 2024: FFM API - A (quick) peek under the hood
https://inside.java/2024/02/13/fosdem2024-ffm-api/

- FOSDEM 2024: Virtual Threads - Next Steps
https://inside.java/2024/02/17/virtual-threads-next-steps/

- Java Language Update - Early 2024 Edition
https://inside.java/2024/02/18/java-language-update-early-2024-update/

- When Should a Compiler Expand Garbage Collection Barriers?
https://robcasloz.github.io/blog/2024/02/14/when-should-a-compiler-expand-garbage-collection-barriers.html

- Emulating C# LINQ in Java using Code Reflection
https://openjdk.org/projects/babylon/articles/linq

- Automatic differentiation of Java code using Code Reflection
https://openjdk.org/projects/babylon/articles/auto-diff


## Java Cryptographic Roadmap Update

The Java Cryptographic Roadmap [19] has been updated with the following planned changes.

* Enable XML Signature secure validation mode by default on JDK 11 and JDK 8
- Target date changed from the July 2024 CPU to the April 2024 CPU.
- This change has already been made in JDK 17 and later releases.

* Disable DTLS 1.0 in JDK 17 and 11 with the July 2024 CPU
- This change has already been made in JDK 20 and later releases.
- DTLS is not available in releases prior to JDK 9.

[19] https://www.java.com/en/jre-jdk-cryptoroadmap.html


~

That's it for this installment. As usual, if you have issues, or questions, please ping me.

--David

[Jython-dev] JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…

[David D. <dav...@or...>]

Greetings!

We are starting 2024 with JDK 22 as it has just entered Rampdown Phase 2 [1]. And with the initial JDK 22 Release Candidates now less than 2 weeks away (Feb. 8th) [2], it is time to shift our attention to JDK 23.

After multiple rounds of incubations and preview, the Foreign Function & Memory API is becoming standard and permanent in JDK 22. If we put its 'Function' angle aside, this API also offers a standard and secure way to access off-heap API. And that brings us to the heads-up below 'Deprecate the memory-access methods in sun.misc.Unsafe for removal in a future release' as developers still using sun.misc.Unsafe for accessing memory are strongly encouraged to start preparing their plans to migrate away from those unsafe methods.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-January/008675.html
[2] https://openjdk.org/projects/jdk/22/


## Heads-up: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal in a Future Release

The effort focused on enforcing the integrity of the Java platform [3] continues! The next phase in that long but important initiative will most likely target the sun.misc.Unsafe API used for accessing memory. Those methods alone represent 79 methods out of the 87 sun.misc.Unsafe methods!

This draft JEP [4] outlines the plan to deprecate for removal the sun.misc.Unsafe Memory-Access methods, the reasons, and the standard alternatives. As the draft plan suggests, the first step will be to deprecate all memory-access methods (on-heap, off-heap, and bimodal) for removal. This will cause compile-time deprecation warnings for code that refers to the methods, alerting library developers to their forthcoming removal. In addition, a new command-line option will allow users to receive runtime warnings when those methods are used. This command-line will help users to assess if their codebase uses those unsafe API to access memory. It should be mentioned that other tools such as JFR and jdeprscan can also be used to detect the use of those deprecated APIs.

Library developers are strongly encouraged to migrate from sun.misc.Unsafe to the supported replacements, so that applications can migrate smoothly to modern JDKs. The initial step will be to conduct investigations to understand if, how, and where sun.misc.Unsafe methods are used to access memory.

[3] https://openjdk.org/jeps/8305968
[4] https://openjdk.org/jeps/8323072


## Heads-up: Java Array Element Alignment - Weakening of Some Methods Guarantees ?

Some methods make promises about Java array element alignment that are too strong. There are some ongoing reflexions to change the implementation (and the specification) of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation.

For more details, make sure to check JDK-8320247 [5] and the related PR [6] but in a nutshell, the new behaviour would be :
- The `VarHandle` returned by `MethodHandles::byteArrayViewVarHandle` would only support `get` and `set` methods, and all other access methods would throw an exception.
- The `VarHandle` returned by `MethodHandles::byteBufferViewHandle` would only support the `get` and `set` access methods when a heap buffer is used, and all other access methods would throw an exception when used with a heap buffer. Direct byte buffers will continue to work the same way.
- The `ByteBuffer::alignmentOffset` and `ByteBuffer::alignedSlice` methods would throw an exception if the buffer is a heap buffer, and the given `unitSize` is greater than 1.

If you have relevant feedback about this potential change, please make sure to bring it to the core-libs-dev mailing list [7], or comment on the PR [6].

[5] https://bugs.openjdk.org/browse/JDK-8320247
[6] https://github.com/openjdk/jdk/pull/16681
[7] https://mail.openjdk.org/pipermail/core-libs-dev/


## JDK 22 Early-Access Builds

JDK 22 Early-Access builds 33 are now available [8], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [9] and the javadocs [10] are also available.

### Changes in recent JDK 22 builds that may be of interest:

- JDK-8320597: RSA signature verification fails on signed data that does not encode params correctly [Reported by Apache POI]
- JDK-8322214: Return value of XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early access builds [Reported by Apache POI]
- JDK-8322725: (tz) Update Timezone Data to 2023d
- JDK-8321480: ISO 4217 Amendment 176 Update
- JDK-8314468: Improve Compiler loops
- JDK-8314295: Enhance verification of verifier
- JDK-8316976: Improve signature handling
- JDK-8317547: Enhance TLS connection support
- JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
- JDK-8323659: LinkedTransferQueue add and put methods call overridable offer

Note: A complete list of changes can be found here [11].

[8] https://jdk.java.net/22/
[9] https://jdk.java.net/22/release-notes
[10] https://download.java.net/java/early_access/jdk22/docs/api/
[11] https://github.com/openjdk/jdk/compare/jdk-22+27...jdk-22+33


## JDK 23 Early-Access builds

JDK 23 Early-Access builds 7 are available [12] for testing. These EA builds are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [13] are also available.

### Changes in recent JDK 23 builds that may be of interest:

- JDK-8320597: RSA signature verification fails on signed data that does not encode params correctly [Reported by Apache POI]
- JDK-8322214: Return value of XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early access builds [Reported by Apache POI]
- JDK-8321545: Override toString() for Format subclasses
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8322383: G1: Only preserve marks on objects that are actually moved
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8320786: Remove ThreadGroup.stop
- JDK-8320532: Remove Thread/ThreadGroup suspend/resume
- JDK-8312150: Remove -Xnoagent option
- JDK-8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock
- JDK-8322725: (tz) Update Timezone Data to 2023d
- JDK-8321480: ISO 4217 Amendment 176 Update
- JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
- JDK-8321594: NativeThreadSet should use placeholder for virtual threads
- JDK-8321940: Improve CDSHeapVerifier in handling of interned strings
- JDK-8321802: (zipfs) Add validation of incorrect LOC signature in ZipFileSystem
- JDK-8322841: Parallel: Remove unused using-declaration in MutableNUMASpace
- JDK-8319626: Override toString() for ZipFile
- JDK-8322878: Including sealing information Class.toGenericString()

Note: A more exhaustive changes list can be found here [14].

[12] https://jdk.java.net/23/
[13] https://jdk.java.net/23/release-notes
[14] https://github.com/openjdk/jdk/compare/jdk-23+1...jdk-23+7


## JavaFX 22 & 23 Early-Access Builds

These are early access builds of the JavaFX 22 Runtime built from openjdk/jfx [14]. These builds enable JavaFX application developers to build and test their applications with JavaFX 22 on JDK 22. Although JavaFX 22 is designed to work with JDK 22, it is also known to work with JDK 17 and later versions.

The latest early access builds of JavaFX 22 Builds 26 (2024/1/20) are available [15], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 22 API Javadocs [16] are also available.

The first early access builds (2024/1/19) of JavaFX 23 are now also available [17].

[14] https://github.com/openjdk/jfx
[15] https://jdk.java.net/javafx22/
[16] https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html
[17] https://jdk.java.net/javafx23/


## Topics of Interest

- Podcast “The Panama Effect” with Jorn Vernee
https://inside.java/2024/01/08/podcast-032/

- Java's Plans for 2024 - Inside Java Newscast
https://inside.java/2024/01/18/newscast-61/

- Java 22 Unpacking - Inside Java Newscast
https://inside.java/2023/12/07/newscast-59/

- Java Highlights of 2023 - Inside Java Newscast
https://inside.java/2023/12/21/newscast-60/

- JDK 21: The GCs keep getting better
https://kstefanj.github.io/2023/12/13/jdk-21-the-gcs-keep-getting-better.html

- Java SE Security Developer’s Guide
https://docs.oracle.com/en/java/javase/21/security/index.html#Java-Platform%2C-Standard-Edition

- Another VS Code Extension for Java
https://inside.java/2023/12/03/java-vscode-extension/


## January 2024 Critical Patch Update Released

As part of the January 2024 CPU, Oracle released OpenJDK 21.0.2, JDK 21.0.2 LTS, JDK 17.0.10 LTS, 11.0.22 LTS, 8u401, and 8u401-perf.


~

As usual, let us know if you find any quirks while testing your project(s) with the latest JDK early-access builds.

--David

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2024-01-05 - 2024-01-12)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2023-12-29 - 2024-01-05)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

Re: [Jython-dev] how to use a static method as a stream Function

[Jeff A. <ja...@fa...>]

I managed to do this (in 2.7.3):

 >>> from java.lang import Double
 >>> from java.util import Arrays
 >>> from java.util.function import DoubleBinaryOperator
 >>> class DoubleSum(DoubleBinaryOperator):
...     applyAsDouble = Double.sum
...
 >>> doubleSum = DoubleSum()
 >>> dd = list(map(float, range(10)))
 >>> dd
[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
 >>> Arrays.stream(dd).reduce(-3.0, doubleSum)
42.0

I chose Double here for a quick test, rather than Float, because I 
wasn't sure the coercion to float would work. There does not seem to be 
a way to supply Double.sum directly but you can wrap it as shown in the 
right type with the right method name. This seems to me not far from 
what the Java compiler is doing for you when you use ::.

I haven't stepped through to see what happens under the covers. Is this 
better than the delegation you indicate?

Jeff

On 30/12/2023 22:26, Albert Cardona wrote:
> Hi all,
>
> Is there any way to use something akin to the double colon notation,
> to use a static method as a Function in a collection stream?
>
> Otherwise, if I have to instantiate it as a jython class that then
> delegates to the static method, performance suffers greatly.
>
> For example, how can one use java.lang.Float's sum method, which takes
> two floating-point numbers as arguments, in a reduce operation?
>
> Thank you.
>
> Best wishes,
>
> Albert
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

-- 

Jeff Allen

[Jython-dev] how to use a static method as a stream Function

[Albert C. <sap...@gm...>]

Hi all,

Is there any way to use something akin to the double colon notation,
to use a static method as a Function in a collection stream?

Otherwise, if I have to instantiate it as a jython class that then
delegates to the static method, performance suffers greatly.

For example, how can one use java.lang.Float's sum method, which takes
two floating-point numbers as arguments, in a reduce operation?

Thank you.

Best wishes,

Albert

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2023-12-22 - 2023-12-29)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2023-12-15 - 2023-12-22)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2023-12-08 - 2023-12-15)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

[Jython-dev] JDK 22 Feature Freeze!

[David D. <dav...@or...>]

Welcome to the final OpenJDK Quality Outreach update of 2023!

JDK 22, scheduled for General Availability on March 19, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 22 feature set is frozen (see the final list of JEPs integrated into JDK 22 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 22 enters the Release Candidates phase in early February 2024. So, we count on you to test your projects and help us make JDK 22 another solid release!

[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008535.html


## JDK 22 Early-Access Builds

JDK 22 Early-Access builds 27 are now 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 22:

- JEP 423: Region Pinning for G1
- JEP 447: Statements before super(…) (Preview)
- JEP 454: Foreign Function & Memory API
- JEP 456: Unnamed Variables & Patterns
- JEP 457: Class-File API (Preview)
- JEP 458: Launch Multi-File Source-Code Programs
- JEP 459: String Templates (2nd Preview)
- JEP 460: Vector API (7th Incubator)
- JEP 461: Stream Gatherers (Preview)
- JEP 462: Structured Concurrency (2nd Preview)
- JEP 463: Implicitly Declared Classes and Instance Main Methods (2nd Preview)
- JEP 464: Scoped Values (2nd Preview)

### Changes in recent JDK 22 builds that may be of interest:

- JDK-8318646: Integer#parseInt("") throws empty NumberFormatException message [Reported by Apache Lucene]
- JDK-8318082: ConcurrentModificationException from IndexWriter [Reported by JOOQ]
- JDK-8319450: New methods java.net.InetXAddress.ofLiteral() miss @since tag [Reported by JaCoCo]
- JDK-8321164: javac w/ annotation processor throws AssertionError: Filling jrt:/… during … [Reported by Hibernate]
- JDK-8310644: Make panama memory segment close use async handshakes
- JDK-8302233: HSS/LMS: keytool and jarsigner changes
- JDK-8211238: New @Deprecated JFR event
- JDK-8319124: Update XML Security for Java to 3.0.3
- JDK-8306055: Add a built-in Catalog to JDK XML module
- JDK-8319244: implement JVMTI handshakes support for virtual threads
- JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode
- JDK-8318759: Add four DigiCert root certificates
- JDK-8317374: Add Let's Encrypt ISRG Root X2
- JDK-8306116: Update CLDR to Version 44.0
- JDK-8287843: File::getCanonicalFile doesn't work for \\?\C:\</?\C:\> style paths DOS device paths
- JDK-8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted"
- JDK-8311596: Add separate system properties for TLS server and client for maximum chain length
- JDK-8318160: javac does not reject private method reference with type-variable receiver
- JDK-8305753: Allow JIT compilation for -Xshare:dump
- JDK-8187591: -Werror turns incubator module warning to an error
- JDK-8318096: Introduce AsymmetricKey interface with a getParams method
- JDK-8319174: Enhance robustness of some j.m.BigInteger constructors
- JDK-8288899: Changes to java.util.concurrent.ForkJoinPool and ForkJoinTask
- JDK-8272215: Add InetAddress methods for parsing IP address literals
- JDK-8316996: Catalog API Enhancement: add a factory method
- JDK-8305814: Update Xalan Java to 2.7.3
- JDK-8313643: Update HarfBuzz to 8.2.2
- JDK-8316030: Update Libpng to 1.6.40

Note: A more comprehensive list of changes can be found here [4].

[2] https://jdk.java.net/22/
[3] https://jdk.java.net/22/release-notes
[4] https://github.com/openjdk/jdk/compare/jdk-22+20...jdk-22+27


## JDK 23 Early-Access Builds

Given that JDK 22 is in Rampdown Phase, the initial JDK 23 EA builds are now also available [5]. These EA builds are provided under the GNU General Public License v2, with the Classpath Exception.

[5] https://jdk.java.net/23/


## JavaFX 22 Early-Access Builds

These are early-access builds of the JavaFX 22 [8] Runtime built from openjdk/jfx [9]. This allows JavaFX application developers to build and test their applications with JavaFX 22 on JDK 22. The JavaFX 22 API Javadocs are also available [10].

The JavaFX runtime is delivered as an SDK and as a set of jmods for each platform. You can use the SDK to compile and run JavaFX applications. You can use the jmods with jlink to create a JDK that includes the JavaFX modules, and optionally, your modular application. JavaFX 22 is designed to work with JDK 22,but it is known to work with JDK 17 and later versions.

[8] https://jdk.java.net/javafx22/
[9] https://github.com/openjdk/jfx
[10] https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html


## Topics of Interest:

- Java 22 Unpacking - Inside Java Newscast
https://inside.java/2023/12/07/newscast-59/

- Java On The GPU - Inside Java Newscast
https://inside.java/2023/11/16/newscast-58/

- Better Java Streams with Gatherers - Inside Java Newscast
https://inside.java/2023/11/02/newscast-57/

- Another VS Code Extension for Java
https://inside.java/2023/12/03/java-vscode-extension/

- Introducing Generational ZGC
https://inside.java/2023/11/28/gen-zgc-explainer/

- Improved Emoji Support in Java 21 - Sip of Java
https://inside.java/2023/11/20/sip089/

- JDK Tool Access from JShell - Sip of Java
https://inside.java/2023/10/23/sip085/

- Optimizing your equals() methods with Pattern Matching - JEP Cafe
https://inside.java/2023/11/10/jepcafe21/

- Package a JavaFX Application as a Platform Specific Executable
https://inside.java/2023/11/14/package-javafx-native-exec/

- Open sourcing Jipher for FIPS regulated environments
https://blogs.oracle.com/developers/post/open-sourcing-jipher

- In-memory HttpServer Handler
https://inside.java/2023/11/06/in-memory-http-server-handler/

- Java Architects Answer Your Questions
https://inside.java/2023/10/26/ama-java-architects/

- Hazelcast Jet on Generational ZGC
https://kstefanj.github.io/2023/11/07/hazelcast-on-generational-zgc.html


~

As usual, let us know if you find any quirks while testing your project(s) with the latest JDK early-access builds. And as the year-end is approaching, I'd like to thank you for being part of the OpenJDK Quality Outreach Program. I hope that you will disconnect a bit to spend time with your family and your friends. See you in 2024 with Java 22 and Java 23!

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2023-12-01 - 2023-12-08)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2023-11-24 - 2023-12-01)
Jython tracker at https://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     346 ( +0)
  closed  2504 ( +0)
  total   2850 ( +0)

Open issues with patches: 22   


Most recent 15 issues with no replies (15)
==========================================

#2938: import MessageSource does not work anymore with jython2.7.2
https://bugs.jython.org/issue2938

#2936: can't use SO_EXCLUSIVEADDRUSE in jython2.7.2
https://bugs.jython.org/issue2936

#2934: Filereader.read: TypeError: read(): 1st arg can't be coerced t
https://bugs.jython.org/issue2934

#2916: Saving output of script which has korean string to a file
https://bugs.jython.org/issue2916

#2898: Fix serialization format
https://bugs.jython.org/issue2898

#2886: doing relative imports in a loop causes bad performance due to
https://bugs.jython.org/issue2886

#2878: java.lang.OutOfMemoryError: Java heap space
https://bugs.jython.org/issue2878

#2876: NullPointer exception PyModule.java
https://bugs.jython.org/issue2876

#2874: Jython 2.7 is not able to import an EBCDIC file on z/OS
https://bugs.jython.org/issue2874

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
https://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
https://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
https://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
https://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
https://bugs.jython.org/issue2363

#2143: site-packages support in standalone jar
https://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
https://bugs.jython.org/issue2142

#1925: Support loading java.sql.Drivers that aren't on the boot class
https://bugs.jython.org/issue1925

#1917: No ctypes.c_char
https://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
https://bugs.jython.org/issue1842

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336