Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Mark Thomas]

On 20/12/2021 12:33, Rémy Maucherat wrote:




I'm seeing a difference with the new Java versions that will need some
attention, with this stack trace occurring on shutdown:
20-Dec-2021 13:26:40.235 WARNING [Thread-2]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches
Failed to clear soft references from ObjectStreamClass$Caches for web
application [docs]
 java.lang.ClassCastException: class
java.io.ObjectStreamClass$Caches$1 cannot be cast to class
java.util.Map (java.io.ObjectStreamClass$Caches$1 and java.util.Map
are in module java.base of loader 'bootstrap')
 at 
org.apache.catalina.loader.WebappClassLoaderBase.clearCache(WebappClassLoaderBase.java:2340)


I see the change in the JDK repo but it hasn't been back-ported to an EA 
release yet. I wonder if this is planned for Java 19?


My current thinking is to wait to address this until the change makes 
its way into a EA release.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Rémy Maucherat]

On Fri, Dec 10, 2021 at 8:58 AM David Delabassee
 wrote:
>
> Mark,
>
> Thank you for being part of the OpenJDK Quality Outreach Program. As
> year-end 2021 approaches, I'd like to share some updates on JDK 18,
> which is scheduled for General Availability on March 22, 2022.
>
> JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 18 stabilization
> repository. At this point, the overall JDK 18 feature set is now frozen
> and no additional JEPs will be targeted to JDK 18. Only low-risk
> enhancements that add small bits of missing functionality or improve
> usability might still be considered. The next few weeks should be
> leveraged to try to identify and resolve as many issues as possible
> (i.e. before JDK 18 enters the Release Candidates phase).
>
> And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
> issues that were reported by you! So thank you for your help
> contributing to the overall quality of OpenJDK!
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html
>
>
> ## JEP 400 - UTF-8 by Default
>
> All JEPs are now integrated, but we would like to draw your attention to
> JEP 400 especially if you are deploying on Windows as it might induce
> some incompatible behavior on that platform.
>
> JEP 400 [2] is changing the default charset to UTF-8. This aligns with
> the existing `newBufferedReader`/`Writer` methods of the
> `java.nio.file.Files` class where UTF-8 is the default when no explicit
> charset is set. By making UTF-8 the default charset, the JDK I/O APIs
> will now always work in the same, predictable manner, with no need to
> pay attention to the host and or user’s environment!
>
> Further, we encourage you to test your project(s) with the latest JDK 18
> Early Access builds. We don't expect issues on macOS and Linux as their
> default encoding is already UTF-8. On Windows, especially for East Asian
> locales such as Chinese/Japanese/Korean, some incompatible behavior
> could be anticipated. If that’s the case, please consider a mitigation
> strategy [3].
>
> [2] https://openjdk.java.net/jeps/400
> [3] https://inside.java/2021/10/04/the-default-charset-jep400/
>
>
> ## JDK 18
>
> JDK 18 Early-Access builds 27 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Make sure to check the Release Notes [5]. As usual, we encourage you to
> test your project(s) using those EA builds and provide us feedback.
>
> [4] https://jdk.java.net/18/
> [5] https://jdk.java.net/18/release-notes
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> ### Changes in recent builds that maybe of interest:
>
>  Build 27:
>
> - JDK-8266435: WBMPImageReader.read() should not truncate the input
> stream [Reported by PDFBox]
> - JDK-8278078: Cannot reference super before supertype constructor has
> been called
> - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
> - JDK-8277965: Enclosing instance optimization affects serialization
> - JDK-8275821: Optimize random number generators developed in
> JDK-8248862 using Math.unsignedMultiplyHigh()
> - JDK-8225181: KeyStore should have a getAttributes method
> - JDK-8275082: Update XML Security for Java to 2.3.0
> - JDK-8278270: ServerSocket is not thread safe
> - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets
>
>  Build 26:
>
> - JDK-8277451: j.l.r.Field::set on static field with invalid argument
> type should throw IAE [Reported by Hibernate & ByteBuddy]
> - JDK-8258117: jar tool sets the time stamp of module-info.class entries
> to the current time [Reported by Apache Maven]
> - JDK-8268743: Require a better way for copying data between
> MemorySegments and on-heap arrays [Reported by Apache Lucene]
> - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
> [Reported by Apache Ant]
> - JDK-8277861: Terminally deprecate Thread.stop
> - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw
> ClassNotFoundException
> - JDK-8271623: Omit enclosing instance fields from inner classes that
> don't use it
> - JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore
> - JDK-8193682: Infinite loop in ZipOutputStream.close()
> - JDK-8277459: Add `jwebserver` tool [see Topics of Interest]
>
>  Build 25:
>
> - JDK-8259643: ZGC can return metaspace OOM prematurely
> - JDK-8277212: GC accidentally cleans valid megamorphic vtable inline caches
> - JDK-8276970: Default charset for PrintWriter that wraps 

Re: [External] : Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[David Delabassee]

Great! Thanks for the prompt feedback!

Regards,

--David

On 10/12/2021 09:54, Martin Grigorov wrote:

Hi David,

Apache Tomcat build and tests pass successfully with JDK 18-ea+27-1924 
on both Linux x86_64 and aarch64!


Regards,
Martin

On Fri, Dec 10, 2021 at 9:58 AM David Delabassee 
 wrote:


Mark,

Thank you for being part of the OpenJDK Quality Outreach Program. As
year-end 2021 approaches, I'd like to share some updates on JDK 18,
which is scheduled for General Availability on March 22, 2022.

JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means
that
the main-line has been forked into a dedicated JDK 18 stabilization
repository. At this point, the overall JDK 18 feature set is now
frozen
and no additional JEPs will be targeted to JDK 18. Only low-risk
enhancements that add small bits of missing functionality or improve
usability might still be considered. The next few weeks should be
leveraged to try to identify and resolve as many issues as possible
(i.e. before JDK 18 enters the Release Candidates phase).

And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
issues that were reported by you! So thank you for your help
contributing to the overall quality of OpenJDK!

[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html


## JEP 400 - UTF-8 by Default

All JEPs are now integrated, but we would like to draw your
attention to
JEP 400 especially if you are deploying on Windows as it might induce
some incompatible behavior on that platform.

JEP 400 [2] is changing the default charset to UTF-8. This aligns
with
the existing `newBufferedReader`/`Writer` methods of the
`java.nio.file.Files` class where UTF-8 is the default when no
explicit
charset is set. By making UTF-8 the default charset, the JDK I/O APIs
will now always work in the same, predictable manner, with no need to
pay attention to the host and or user’s environment!

Further, we encourage you to test your project(s) with the latest
JDK 18
Early Access builds. We don't expect issues on macOS and Linux as
their
default encoding is already UTF-8. On Windows, especially for East
Asian
locales such as Chinese/Japanese/Korean, some incompatible behavior
could be anticipated. If that’s the case, please consider a
mitigation
strategy [3].

[2] https://openjdk.java.net/jeps/400
[3] https://inside.java/2021/10/04/the-default-charset-jep400/




## JDK 18

JDK 18 Early-Access builds 27 are now available [4], and are provided
under the GNU General Public License v2, with the Classpath
Exception.
Make sure to check the Release Notes [5]. As usual, we encourage
you to
test your project(s) using those EA builds and provide us feedback.

[4] https://jdk.java.net/18/


[5] https://jdk.java.net/18/release-notes



### JEPs integrated to JDK 18:

- JEP 400: UTF-8 by Default
- JEP 408: Simple Web Server
- JEP 413: Code Snippets in Java API Documentation
- JEP 416: Reimplement Core Reflection with Method Handles
- JEP 417: Vector API (Third Incubator)
- JEP 418: Internet-Address Resolution SPI
- JEP 419: Foreign Function & Memory API (Second Incubator)
- JEP 420: Pattern Matching for switch (Second Preview)
- JEP 421: Deprecate Finalization for Removal

### Changes in recent builds that maybe of interest:

 Build 27:

- JDK-8266435: WBMPImageReader.read() should not truncate the input
stream [Reported by PDFBox]
- JDK-8278078: Cannot reference super before supertype constructor
has
been called
- JDK-8177819: DateTimeFormatterBuilder zone parsing should
recognise DST
- JDK-8277965: Enclosing instance optimization affects serialization
- JDK-8275821: Optimize random number generators developed in
JDK-8248862 using Math.unsignedMultiplyHigh()
- JDK-8225181: KeyStore should have a getAttributes method
- JDK-8275082: Update XML Security for Java to 2.3.0
- JDK-8278270: ServerSocket is not thread safe
- JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets

 Build 26:

- JDK-8277451: j.l.r.Field::set on static field with invalid argument
type should throw IAE [Reported by Hibernate & ByteBuddy]
- JDK-8258117: jar tool sets the time stamp of module-info.class
entries
to the 

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Rémy Maucherat]

On Fri, Dec 10, 2021 at 8:58 AM David Delabassee
 wrote:
>
> Mark,
>
> Thank you for being part of the OpenJDK Quality Outreach Program. As
> year-end 2021 approaches, I'd like to share some updates on JDK 18,
> which is scheduled for General Availability on March 22, 2022.
>
> JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 18 stabilization
> repository. At this point, the overall JDK 18 feature set is now frozen
> and no additional JEPs will be targeted to JDK 18. Only low-risk
> enhancements that add small bits of missing functionality or improve
> usability might still be considered. The next few weeks should be
> leveraged to try to identify and resolve as many issues as possible
> (i.e. before JDK 18 enters the Release Candidates phase).
>
> And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
> issues that were reported by you! So thank you for your help
> contributing to the overall quality of OpenJDK!
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html
>
>
> ## JEP 400 - UTF-8 by Default
>
> All JEPs are now integrated, but we would like to draw your attention to
> JEP 400 especially if you are deploying on Windows as it might induce
> some incompatible behavior on that platform.
>
> JEP 400 [2] is changing the default charset to UTF-8. This aligns with
> the existing `newBufferedReader`/`Writer` methods of the
> `java.nio.file.Files` class where UTF-8 is the default when no explicit
> charset is set. By making UTF-8 the default charset, the JDK I/O APIs
> will now always work in the same, predictable manner, with no need to
> pay attention to the host and or user’s environment!
>
> Further, we encourage you to test your project(s) with the latest JDK 18
> Early Access builds. We don't expect issues on macOS and Linux as their
> default encoding is already UTF-8. On Windows, especially for East Asian
> locales such as Chinese/Japanese/Korean, some incompatible behavior
> could be anticipated. If that’s the case, please consider a mitigation
> strategy [3].
>
> [2] https://openjdk.java.net/jeps/400
> [3] https://inside.java/2021/10/04/the-default-charset-jep400/
>
>
> ## JDK 18
>
> JDK 18 Early-Access builds 27 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Make sure to check the Release Notes [5]. As usual, we encourage you to
> test your project(s) using those EA builds and provide us feedback.
>
> [4] https://jdk.java.net/18/
> [5] https://jdk.java.net/18/release-notes
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)

So this was a significant build for this one. No issues found, now
hoping for a smooth transition to java.base (in Java 19 ?).

Rémy

> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> ### Changes in recent builds that maybe of interest:
>
>  Build 27:
>
> - JDK-8266435: WBMPImageReader.read() should not truncate the input
> stream [Reported by PDFBox]
> - JDK-8278078: Cannot reference super before supertype constructor has
> been called
> - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
> - JDK-8277965: Enclosing instance optimization affects serialization
> - JDK-8275821: Optimize random number generators developed in
> JDK-8248862 using Math.unsignedMultiplyHigh()
> - JDK-8225181: KeyStore should have a getAttributes method
> - JDK-8275082: Update XML Security for Java to 2.3.0
> - JDK-8278270: ServerSocket is not thread safe
> - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets
>
>  Build 26:
>
> - JDK-8277451: j.l.r.Field::set on static field with invalid argument
> type should throw IAE [Reported by Hibernate & ByteBuddy]
> - JDK-8258117: jar tool sets the time stamp of module-info.class entries
> to the current time [Reported by Apache Maven]
> - JDK-8268743: Require a better way for copying data between
> MemorySegments and on-heap arrays [Reported by Apache Lucene]
> - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
> [Reported by Apache Ant]
> - JDK-8277861: Terminally deprecate Thread.stop
> - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw
> ClassNotFoundException
> - JDK-8271623: Omit enclosing instance fields from inner classes that
> don't use it
> - JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore
> - JDK-8193682: Infinite loop in ZipOutputStream.close()
> - JDK-8277459: Add `jwebserver` tool [see Topics of Interest]
>
>  Build 25:
>
> - JDK-8259643: ZGC can return metaspace OOM prematurely
> - 

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Martin Grigorov]

Hi David,

Apache Tomcat build and tests pass successfully with JDK 18-ea+27-1924 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Dec 10, 2021 at 9:58 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Mark,
>
> Thank you for being part of the OpenJDK Quality Outreach Program. As
> year-end 2021 approaches, I'd like to share some updates on JDK 18,
> which is scheduled for General Availability on March 22, 2022.
>
> JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 18 stabilization
> repository. At this point, the overall JDK 18 feature set is now frozen
> and no additional JEPs will be targeted to JDK 18. Only low-risk
> enhancements that add small bits of missing functionality or improve
> usability might still be considered. The next few weeks should be
> leveraged to try to identify and resolve as many issues as possible
> (i.e. before JDK 18 enters the Release Candidates phase).
>
> And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
> issues that were reported by you! So thank you for your help
> contributing to the overall quality of OpenJDK!
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html
>
>
> ## JEP 400 - UTF-8 by Default
>
> All JEPs are now integrated, but we would like to draw your attention to
> JEP 400 especially if you are deploying on Windows as it might induce
> some incompatible behavior on that platform.
>
> JEP 400 [2] is changing the default charset to UTF-8. This aligns with
> the existing `newBufferedReader`/`Writer` methods of the
> `java.nio.file.Files` class where UTF-8 is the default when no explicit
> charset is set. By making UTF-8 the default charset, the JDK I/O APIs
> will now always work in the same, predictable manner, with no need to
> pay attention to the host and or user’s environment!
>
> Further, we encourage you to test your project(s) with the latest JDK 18
> Early Access builds. We don't expect issues on macOS and Linux as their
> default encoding is already UTF-8. On Windows, especially for East Asian
> locales such as Chinese/Japanese/Korean, some incompatible behavior
> could be anticipated. If that’s the case, please consider a mitigation
> strategy [3].
>
> [2] https://openjdk.java.net/jeps/400
> [3] https://inside.java/2021/10/04/the-default-charset-jep400/
>
>
> ## JDK 18
>
> JDK 18 Early-Access builds 27 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Make sure to check the Release Notes [5]. As usual, we encourage you to
> test your project(s) using those EA builds and provide us feedback.
>
> [4] https://jdk.java.net/18/
> [5] https://jdk.java.net/18/release-notes
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> ### Changes in recent builds that maybe of interest:
>
>  Build 27:
>
> - JDK-8266435: WBMPImageReader.read() should not truncate the input
> stream [Reported by PDFBox]
> - JDK-8278078: Cannot reference super before supertype constructor has
> been called
> - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
> - JDK-8277965: Enclosing instance optimization affects serialization
> - JDK-8275821: Optimize random number generators developed in
> JDK-8248862 using Math.unsignedMultiplyHigh()
> - JDK-8225181: KeyStore should have a getAttributes method
> - JDK-8275082: Update XML Security for Java to 2.3.0
> - JDK-8278270: ServerSocket is not thread safe
> - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets
>
>  Build 26:
>
> - JDK-8277451: j.l.r.Field::set on static field with invalid argument
> type should throw IAE [Reported by Hibernate & ByteBuddy]
> - JDK-8258117: jar tool sets the time stamp of module-info.class entries
> to the current time [Reported by Apache Maven]
> - JDK-8268743: Require a better way for copying data between
> MemorySegments and on-heap arrays [Reported by Apache Lucene]
> - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
> [Reported by Apache Ant]
> - JDK-8277861: Terminally deprecate Thread.stop
> - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw
> ClassNotFoundException
> - JDK-8271623: Omit enclosing instance fields from inner classes that
> don't use it
> - JDK-8231107: Allow store password to be null when saving a PKCS12
> KeyStore
> - JDK-8193682: Infinite loop in ZipOutputStream.close()
> - JDK-8277459: Add `jwebserver` tool [see Topics of Interest]
>
>  Build 25:
>
> - JDK-8259643: ZGC can return 

JDK 18: Rampdown Phase 1 & Early-Access builds 27

[David Delabassee]

Mark,

Thank you for being part of the OpenJDK Quality Outreach Program. As 
year-end 2021 approaches, I'd like to share some updates on JDK 18, 
which is scheduled for General Availability on March 22, 2022.


JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that 
the main-line has been forked into a dedicated JDK 18 stabilization 
repository. At this point, the overall JDK 18 feature set is now frozen 
and no additional JEPs will be targeted to JDK 18. Only low-risk 
enhancements that add small bits of missing functionality or improve 
usability might still be considered. The next few weeks should be 
leveraged to try to identify and resolve as many issues as possible 
(i.e. before JDK 18 enters the Release Candidates phase).


And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for 
issues that were reported by you! So thank you for your help 
contributing to the overall quality of OpenJDK!


[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html



## JEP 400 - UTF-8 by Default

All JEPs are now integrated, but we would like to draw your attention to 
JEP 400 especially if you are deploying on Windows as it might induce 
some incompatible behavior on that platform.


JEP 400 [2] is changing the default charset to UTF-8. This aligns with 
the existing `newBufferedReader`/`Writer` methods of the 
`java.nio.file.Files` class where UTF-8 is the default when no explicit 
charset is set. By making UTF-8 the default charset, the JDK I/O APIs 
will now always work in the same, predictable manner, with no need to 
pay attention to the host and or user’s environment!


Further, we encourage you to test your project(s) with the latest JDK 18 
Early Access builds. We don't expect issues on macOS and Linux as their 
default encoding is already UTF-8. On Windows, especially for East Asian 
locales such as Chinese/Japanese/Korean, some incompatible behavior 
could be anticipated. If that’s the case, please consider a mitigation 
strategy [3].


[2] https://openjdk.java.net/jeps/400
[3] https://inside.java/2021/10/04/the-default-charset-jep400/


## JDK 18

JDK 18 Early-Access builds 27 are now available [4], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
Make sure to check the Release Notes [5]. As usual, we encourage you to 
test your project(s) using those EA builds and provide us feedback.


[4] https://jdk.java.net/18/
[5] https://jdk.java.net/18/release-notes

### JEPs integrated to JDK 18:

- JEP 400: UTF-8 by Default
- JEP 408: Simple Web Server
- JEP 413: Code Snippets in Java API Documentation
- JEP 416: Reimplement Core Reflection with Method Handles
- JEP 417: Vector API (Third Incubator)
- JEP 418: Internet-Address Resolution SPI
- JEP 419: Foreign Function & Memory API (Second Incubator)
- JEP 420: Pattern Matching for switch (Second Preview)
- JEP 421: Deprecate Finalization for Removal

### Changes in recent builds that maybe of interest:

 Build 27:

- JDK-8266435: WBMPImageReader.read() should not truncate the input 
stream [Reported by PDFBox]
- JDK-8278078: Cannot reference super before supertype constructor has 
been called

- JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
- JDK-8277965: Enclosing instance optimization affects serialization
- JDK-8275821: Optimize random number generators developed in 
JDK-8248862 using Math.unsignedMultiplyHigh()

- JDK-8225181: KeyStore should have a getAttributes method
- JDK-8275082: Update XML Security for Java to 2.3.0
- JDK-8278270: ServerSocket is not thread safe
- JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets

 Build 26:

- JDK-8277451: j.l.r.Field::set on static field with invalid argument 
type should throw IAE [Reported by Hibernate & ByteBuddy]
- JDK-8258117: jar tool sets the time stamp of module-info.class entries 
to the current time [Reported by Apache Maven]
- JDK-8268743: Require a better way for copying data between 
MemorySegments and on-heap arrays [Reported by Apache Lucene]
- JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime 
[Reported by Apache Ant]

- JDK-8277861: Terminally deprecate Thread.stop
- JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw 
ClassNotFoundException
- JDK-8271623: Omit enclosing instance fields from inner classes that 
don't use it

- JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore
- JDK-8193682: Infinite loop in ZipOutputStream.close()
- JDK-8277459: Add `jwebserver` tool [see Topics of Interest]

 Build 25:

- JDK-8259643: ZGC can return metaspace OOM prematurely
- JDK-8277212: GC accidentally cleans valid megamorphic vtable inline caches
- JDK-8276970: Default charset for PrintWriter that wraps PrintStream
- JDK-8272773: Configurable card table card size
- JDK-4337793: Mark non-serializable fields of 
java.security.cert.Certificate and CertPath


 Build 24:

- JDK-8275056: Allow G1 heap regions