JDK 18: Rampdown Phase 1 & Early-Access builds 27
by David Delabassee
David, Richard,
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 some of 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 up to 512MB [see Topics of Interest]
- JDK-8271515: Integration of JEP 417: Vector API (Third Incubator)
- JDK-8267108: Alternate Subject.getSubject and doAs APIs that do not
depend on Security Manager APIs
- JDK-8244202: Implementation of JEP 418: Internet-Address Resolution SPI
- JDK-8276186: Require getAvailableLocales() methods to include Locale.ROOT
- JDK-8276184: Exclude lambda proxy class from the CDS archive if its
caller class is excluded
## Project Loom Update
New Loom Early-Access builds are also available [6]. Those EA builds are
based on JDK18 EA build 25 and offer a new structured concurrency API
[7]. These EA builds are provided under the GNU General Public License,
version 2, with the Classpath Exception and are produced for the purpose
of gathering feedback. Use for any other purpose is at your own risk.
Feedback should be send to the `loom-dev` mailing list [8].
On that note, you might also want to check this 'On Parallelism and
Concurrency' piece [9].
[6] https://jdk.java.net/loom/
[7]
https://mail.openjdk.java.net/pipermail/loom-dev/2021-November/003072.html
[8] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
[9] https://inside.java/2021/11/30/on-parallelism-and-concurrency/
## Topics of Interest:
- JDK 18: Working with the Simple Web Server
https://inside.java/2021/12/06/working-with-the-simple-web-server/
- JDK 18: Quality Outreach Heads-up: JEP 411
https://inside.java/2021/12/06/quality-heads-up/
- JDK 18: Quality Outreach Heads-up: JEP 416
https://inside.java/2021/11/29/quality-heads-up/
- JDK 18 will bump heap region size limit to 512MB (Vs. 32Mb today)
https://tschatzl.github.io/2021/11/15/heap-regions-x-large.html
- JDK 18: JEP 400 and the Default Charset
https://inside.java/2021/10/04/the-default-charset-jep400/
- Panama/Foreign Status Update
https://mail.openjdk.java.net/pipermail/panama-dev/2021-December/015895.html
- GC progress from JDK 8 to JDK 17
https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html
- JDK Migration Guide
https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html
In closing, I'd like to thank you again for being a welcomed part of the
Quality Outreach program! We look forward to your continued
participation. Please enjoy the holiday season and have a happy new year!
--David
4 years
Add natives for ARM64 to Wildfly distro
by Julien Faye
Hello Wildfly devs,
At my job we want to move to Linux ARM64 machines for our deployments.
The issue we see is that the current (22.0.1) distribution does not include
native binaries for linux-aarch64 architecture :-/
$ find ./ -name "*.so"
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-i686/libartemis-native-32.so
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
I've found https://issues.redhat.com/browse/WFLY-13302 (and
https://issues.redhat.com/browse/WFSSL-32 and
https://issues.apache.org/jira/browse/ARTEMIS-2705) but those are opened
almost an year ago and it is not clear whether they will be resolved any
time soon.
As far as I understand your recommendation is to build the binaries
locally. This is OK but it adds some extra complexity to the deployment and
upgrade processes.
Since ARM64 becomes more and more popular for server side deployments I
would like to ask you whether those tickets could be resolved in near
future ?
Thank you!
Regards,
Julien
4 years
Early wrap-up for WildFly 26 development
by Brian Stansberry
Next week is the planned release for WildFly 26.0.0.Final, with the freeze
for changes coming in via core planned for this Friday, Dec 10.
But, since people will be starting to head off for year end vacations
starting next week, I'd like to get as much as possible done this week.
Specifically I'd like to have all PRs meant for WF 26 (including those that
come in via WF Core) ready for merge by early afternoon
*this Thursday, Dec 9*. We can then get WF Core 18 released and merged
during the EMEA workday Friday, and then wrap up merging to full WildFly on
Friday. That will let us spend the time until the planned Wed Dec 15 WF 26
Final tag chasing down any unexpected problems.
If you have something you really need to get into WF 26, please get your PR
in a state where it's ready for merge; get tests passing and get any code
reviews done.
If you're working on something where this is problematic, please let me
know ASAP.
--
Brian Stansberry
Project Lead, WildFly
He/Him/His
4 years
Skipping supplied Jandex index for CDI in EE9 mode
by Kabir Khan
My latest attempt to upgrade SmallRye Reactive Messaging failed in the
WildFly Preview testsuite.
After some investigation, I found the cause to be that they now include the
jandex index in their jars. This index contains javax annotations to define
the CDI beans. If Weld finds a jandex index, it will use that. However, in
EE9 preview mode, it searches for jakarta annotations in that index.The end
result was that no CDI beans were found in the Reactive Messaging provider
jar.
I've worked around this in my https://github.com/wildfly/wildfly/pull/14953,
by adding a method to WeldCapability to ignore the precalculated jandex
index for modules containing jars with a jandex index.
I am mentioning this because the jandex index was added to help with some
build time config checking for Quarkus. So it would not surprise me if
other SmallRye projects, and maybe other projects consumed by Quarkus
follow suit.
My changes have not been reviewed yet, so there might be some small
changes but the overall concept will most likely be kept.
Thanks,
Kabir
4 years
