JDK 18 General Availability, and oracle-actions/setup-java

[David Delabassee]

Greetings!

JDK 18 has been released (General Availability) on March 22nd as 
planned, the release cadence is working like clockwork! As a small token 
of gratitude, some of you have been specifically acknowledged in the 
"The Arrival of Java 18" announcement [1]. On behalf of the entire team, 
let me extend our thanks to all of you.


With JDK 18 released, the focus should now be on making sure your 
project(s) compile and work on JDK 19. As always, if you face any issue 
with early-access builds of JDK 19 please let us know. To help you in 
this task, we have just released a GitHub action to install the OpenJDK 
Early-Access builds. For more information, please check the heads-up below.


I'll conclude with a short teaser, i.e. JavaOne is Back! [2] Stay tuned 
for more details.


[1] https://inside.java/2022/03/22/the-arrival-of-java18/
[2] https://www.oracle.com/cloudworld/javaone/


## Heads-Up: oracle-actions/setup-java

To help you test your project(s), we have released a GitHub Action [3] 
to download and install various JDK builds produced by Oracle. In 
addition to the latest OpenJDK GA builds (GPL v2 W/CPE) and the Oracle 
JDK builds (NFTC license), this action can also download and install 
OpenJDK early-access builds, and early-access builds of OpenJDK projects 
(ex. Project Loom, Project Valhalla, etc.).


When doing tests using EA builds, it is key to always use the upstream 
EA builds from jdk.java.net as issues should be logged against those 
upstream builds, and ideally against a specific build version. This 
GitHub action is actively following the OpenJDK EA builds releases. 
Please make sure to check the announcement [4] for more details, and 
short FAQ.


To help you isolate regression between different EA builds, we are 
working to add support for archived builds. If you have feedback, please 
either issue the Issue tracker [5] or just send me a mail.


[3] 
https://github.com/marketplace/actions/setup-java-development-kits-built-by-oracle

[4] https://inside.java/2022/03/11/setup-java/
[5] https://github.com/oracle-actions/setup-java/issues


## General Availability of Java 18 / JDK 18

JDK 18 is now Generally Available [6]. The OpenJDK builds which are 
provided under the GNU General Public License v2, with the Classpath 
Exception are available [7], the JDK 18 Release Notes are also available 
[8].


[6] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-March/006458.html
[7] https://jdk.java.net/18/
[8] https://jdk.java.net/18/release-notes

Along with hundreds of smaller enhancements and over a thousand bug 
fixes, JDK 18 includes following JEPs:

- 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

Thanks to everyone who contributed to JDK 18, whether by designing and 
implementing features or enhancements, by fixing bugs, or by downloading 
and testing the early-access builds.



## JDK 19 Early-Access builds

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


[9] https://jdk.java.net/19/
[10] https://jdk.java.net/19/release-notes

### JEPs targeted to JDK 19, so far:
- JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422

### Recent changes that maybe of interest:
- JDK-8283415: Update java.lang.ref to use sealed classes
- JDK-8280494: (D)TLS signature schemes
- JDK-8282081: java.time.DateTimeFormatter: wrong definition of symbol F
- JDK-8281181: Do not use CPU Shares to compute active processor count
- JDK-7192189: Support endpoint identification algorithm in RFC 6125
- JDK-8277474: jarsigner does not check if algorithm parameters are disabled
- JDK-8280357: If the users home directory is invalid, system property 
user.home is set to $HOME

- JDK-8277204: Implement PAC-RET branch protection on Linux/AArch64
- JDK-8282411: Add useful predicates to ElementKind
- JDK-8282131: java.time.ZoneId should be a sealed abstract class
- JDK-8281375: Accelerate bitCount operation for AVX2 and AVX512 target


## Topics of Interest:

- “Java 18 is Here!” - Inside Java Podcast
https://inside.java/2022/03/22/podcast-023/

- “The Simple Web Server” - Inside Java Podcast
https://inside.java/2022/03/04/podcast-022/

- “Finalization Deprecation” - Inside Java Podcast
https://inside.java/2022/01/12/podcast-021/

- All About JDK 18 - Inside Java Newscast
https://inside.java/2022/03/10/insidejava-newscast-021/

- JDK 18 - Security Enhancements
https://seanjmullan.org/blog/2022/03/23/jdk18

- JDK 18 - Programmer's Guide to Snippets
https://docs.oracle.com/en/java/javase/18/code-snippet/index.html

- JDK

Pull request 683

[Atul Pendse]

Hi,

Can someone please help make progress on PR 683
, or point out what I
should be doing next?

Thanks,
Atul

Re: The roadmap to Log4j 3.0.0

[Gary Gregory]

Hi Matt,

Why isn't the code in log4-plugins in log4j-core?

Gary

On Sun, Mar 27, 2022, 16:59 Matt Sicker  wrote:

> Hey all, after making a lot of serious progress toward what I’ve been
> alternatively referring to as the “Mean Bean Machine” or the “Great
> Inversion”, I’m finally coming to a logical conclusion of this (only have a
> couple remaining plugin types to refactor). While it took a few tries using
> different APIs and approaches to using dependency injection, I’m feeling
> good about this current iteration as it’s been fairly successful so far at
> applying inversion of control to places that were otherwise using ad hoc
> configuration mechanisms or other static method factories to enable a
> unified approach to configuring things.
>
> With this in place, I believe we only have a few remaining high level
> tasks to complete before we can release 3.0.0 (including any potential
> early-release alpha/beta versions). Please feel free to comment on any of
> these or add other items.
>
> * The log4j-core module still needs to be further broken into modules such
> that log4j-core only requires java.base (and log4j-api and log4j-plugins).
> * The rest of the Log4j modules that don’t already have a module-info.java
> file need one.
> * There are dozens (possibly hundreds) of commits that have only been
> applied to release-2.x which need to be copied to master.
> * The new JSON configuration factory based on an embedded JSON parser
> (from the JSON Template Layout module) needs to be merged into log4j-core
> to replace the Jackson variant (which would be moved to its own module just
> like the other configuration factories that require more than java.base).
> * The LoggerContext properties configuration proposal from Ralph needs to
> be implemented.
> * The website and docs need to be updated, though this task is shared with
> the same issue for 2.x.
>
> Based on these remaining issues to resolve, I’d estimate that we can most
> likely make a 3.0.0 release before ApacheCon this year (which is Oct 3-6)
> which could make great timing for getting a talk or two accepted at
> ApacheCon (the first and last time I had a talk accepted for this was for
> the 2.0 release). If that’s the case, then I also have a tentative schedule
> we can try to follow:
>
> 1. Make an alpha or beta release of 3.0.0 by June.
> 2. Preferably more than one beta depending on feedback.
> 3. Work on cutting 3.0.0 by September.
>
> Hopefully this timeline isn’t overly optimistic, but I believe we’ve
> finally passed some of the toughest parts of the roadmap (Java modules and
> the Great Inversion being two of them). It’d also be great to try to have a
> Log4j release with a Java 11 baseline before Java 11 itself is EOL, but
> that’s not a _requirement_ per se.
> —
> Matt Sicker
>
>

Re: The roadmap to Log4j 3.0.0

[Matt Sicker]

Originally, it was because most of that code had to be there where the 
annotations were. Now some of that code can be moved back to core, though some 
of it would still need to remain for the annotation processing stuff. Ralph had 
suggested recently that the plugin code could form a useful basis for other 
projects like Flume, too, which itself might make sense in Commons, but 
otherwise, it’s still mainly in the plugins module out of convenience (core 
tests take too long for rapid iteration of the DI system, but now that it’s in 
place, it’s not as necessary).

—
Matt Sicker

> On Mar 28, 2022, at 14:21, Gary Gregory  wrote:
> 
> Hi Matt,
> 
> Why isn't the code in log4-plugins in log4j-core?
> 
> Gary
> 
>> On Sun, Mar 27, 2022, 16:59 Matt Sicker  wrote:
>> 
>> Hey all, after making a lot of serious progress toward what I’ve been
>> alternatively referring to as the “Mean Bean Machine” or the “Great
>> Inversion”, I’m finally coming to a logical conclusion of this (only have a
>> couple remaining plugin types to refactor). While it took a few tries using
>> different APIs and approaches to using dependency injection, I’m feeling
>> good about this current iteration as it’s been fairly successful so far at
>> applying inversion of control to places that were otherwise using ad hoc
>> configuration mechanisms or other static method factories to enable a
>> unified approach to configuring things.
>> 
>> With this in place, I believe we only have a few remaining high level
>> tasks to complete before we can release 3.0.0 (including any potential
>> early-release alpha/beta versions). Please feel free to comment on any of
>> these or add other items.
>> 
>> * The log4j-core module still needs to be further broken into modules such
>> that log4j-core only requires java.base (and log4j-api and log4j-plugins).
>> * The rest of the Log4j modules that don’t already have a module-info.java
>> file need one.
>> * There are dozens (possibly hundreds) of commits that have only been
>> applied to release-2.x which need to be copied to master.
>> * The new JSON configuration factory based on an embedded JSON parser
>> (from the JSON Template Layout module) needs to be merged into log4j-core
>> to replace the Jackson variant (which would be moved to its own module just
>> like the other configuration factories that require more than java.base).
>> * The LoggerContext properties configuration proposal from Ralph needs to
>> be implemented.
>> * The website and docs need to be updated, though this task is shared with
>> the same issue for 2.x.
>> 
>> Based on these remaining issues to resolve, I’d estimate that we can most
>> likely make a 3.0.0 release before ApacheCon this year (which is Oct 3-6)
>> which could make great timing for getting a talk or two accepted at
>> ApacheCon (the first and last time I had a talk accepted for this was for
>> the 2.0 release). If that’s the case, then I also have a tentative schedule
>> we can try to follow:
>> 
>> 1. Make an alpha or beta release of 3.0.0 by June.
>> 2. Preferably more than one beta depending on feedback.
>> 3. Work on cutting 3.0.0 by September.
>> 
>> Hopefully this timeline isn’t overly optimistic, but I believe we’ve
>> finally passed some of the toughest parts of the roadmap (Java modules and
>> the Great Inversion being two of them). It’d also be great to try to have a
>> Log4j release with a Java 11 baseline before Java 11 itself is EOL, but
>> that’s not a _requirement_ per se.
>> —
>> Matt Sicker
>> 
>> 

Re: The roadmap to Log4j 3.0.0

[Piotr P. Karwasz]

Hello,

On Sun, 27 Mar 2022 at 23:59, Matt Sicker  wrote:
> * There are dozens (possibly hundreds) of commits that have only been applied 
> to release-2.x which need to be copied to master.

The `log4j-1.2-api` code seems synchronized between `master` and
`release-2.x` up to January 20th. Since part of the desynchronization
that occurred afterwards is my fault and some of my changes are built
on top of Gary's, I can take care of the cherry-picking. Probably a
comparison of the two codes will be necessary at the end.

Piotr