Compiling with 2.24.0 fails: module not found: org.jspecify

[xzel23]

Description

I have a modular (Jigsaw) project that uses log4j2. Compilation fails after updating to 2.24.0 from 2.23.1 with the error "".

Configuration

Version: 2.24.0

Operating system: macOS 14.6.1

JDK:

openjdk 21.0.4 2024-07-16 LTS
OpenJDK Runtime Environment (build 21.0.4+9-LTS)
OpenJDK 64-Bit Server VM (build 21.0.4+9-LTS, mixed mode, sharing)

Logs

Running my gradle build, I get this:

23:21:38: Executing 'build'...

> Task :utility-logging:processResources NO-SOURCE
> Task :utility-fx-web:generateCatalogAsToml FROM-CACHE
> Task :generateCatalogAsToml FROM-CACHE
> Task :utility-db:generateCatalogAsToml FROM-CACHE
> Task :utility-logging:generateCatalogAsToml FROM-CACHE
> Task :utility:generateCatalogAsToml FROM-CACHE
> Task :utility-fx-icons-ikonli:generateCatalogAsToml FROM-CACHE
> Task :utility-fx-db:generateCatalogAsToml FROM-CACHE
> Task :utility-fx:generateCatalogAsToml FROM-CACHE
> Task :utility-fx-web:processResources NO-SOURCE
> Task :utility-fx-controls:generateCatalogAsToml FROM-CACHE
> Task :compileJava NO-SOURCE
> Task :utility-fx-db:processResources NO-SOURCE
> Task :utility-db:processResources
> Task :utility-fx:processResources
> Task :utility-fx-controls:processResources
> Task :utility-fx-icons-ikonli:processResources

> Task :utility-fx-icons:compileJava FAILED

> Task :utility-logging:sourcesJar
> Task :utility-fx-icons-ikonli:sourcesJar
> Task :utility-fx-db:sourcesJar
> Task :utility-fx-web:sourcesJar
> Task :utility-fx:sourcesJar
> Task :utility-fx-controls:sourcesJar
error: module not found: org.jspecify
1 error
> Task :utility-db:sourcesJar
> Task :cabe

> Task :utility:compileJava FAILED
23 actionable tasks: 14 executed, 9 from cache
error: module not found: org.jspecify
1 error

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':utility-fx-icons:compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
> Run with --info option to get more log output.
> Run with --scan to get full insights.
==============================================================================

2: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':utility:compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
> Run with --info option to get more log output.
> Run with --scan to get full insights.
==============================================================================

BUILD FAILED in 448ms
23:21:39: Execution finished 'build'.

Reproduction

Sorry, still have not had the time to create a minimal project. I think any project using modules working with 2.23.1 should expose the error - I still need to investigate. But changing the log4j2 version is the only change I did before running into this error and changing back to 2.23.1 fixed it. Compile with version 2.23.1, then try again using 2.24.0.

My project does (obviously) not use jspecify, adding it as a dependency will probably fix it.

I see this in the log4j-core module-info.class and think jspecify should be a transitive dependency and the static might have to be removed:

        requires static transitive org.jspecify;

[ppkarwasz]

@xzel23,

Reproduction

Sorry, still have not had the time to create a minimal project. I think any project using modules working with 2.23.1 should expose the error - I still need to investigate. But changing the log4j2 version is the only change I did before running into this error and changing back to 2.23.1 fixed it. Compile with version 2.23.1, then try again using 2.24.0.

My project does (obviously) not use jspecify, adding it as a dependency will probably fix it.

I see this in the log4j-core module-info.class and think jspecify should be a transitive dependency and the static might have to be removed:

        requires static transitive org.jspecify;

Thanks for reporting this. The problem is due to the way JPMS resolution process works:

• At compile time the transitive module dependencies of at least your direct dependencies are enumerated to create an observability graph.
• At runtime the static module dependencies are treated as optional and no error occurs if they are missing.

JSpecify is an annotation library, so it is I am not sure why BND considers JSpecify a transitive dependency, but we'll add the appropriate exclusions in the next Log4j release to obtain:

requires static org.jspecify;

In the meantime you can workaround the problem, by adding JSpecify as a compile-only dependency:

compileOnly 'org.jspecify:jspecify:1.0.0'

[rickardoberg]

This issue really messed up our builds. Could you consider adding perhaps some testing and CI to this project before running releases? That would be great, thanks.

[vy]

@rickardoberg, I understand your frustration and thanks so much for the feedback. See #2930 – there we are working on the solution and the test to avoid similar issues in the future. We will issue 2.24.1 in ~2 weeks, we want to wait until then to catch other last minute issues slipped through our attention.

[agentgt]

@ppkarwasz

My concern with:

requires static org.jspecify;

over this

requires org.jspecify;

I talked about in this comment here:

jspecify/jspecify#495 (comment)

I don't think Log4J2 is currently doing in reflective check of something being @Nullable (to indicate optional plugin element for example) but if you do later on requires static will not work in a jlink-ed application.

[agentgt]

@rickardoberg, I understand your frustration and thanks so much for the feedback. See #2930 – there we are working on the solution and the test to avoid similar issues in the future. We will issue 2.24.1 in ~2 weeks, we want to wait until then to catch other last minute issues slipped through our attention.

@vy Perhaps log4j2 should have a test module or example module (does not need to get deploy to maven central) that creates a JLink application. That is really the ultimate test if the modules (module-info) are correct.

FWIW here is my logging library doing that: https://github.com/jstachio/rainbowgum/tree/main/test/rainbowgum-test-jlink

Feel free to copy the jlink maven plugin part of the pom particularly this part: https://github.com/jstachio/rainbowgum/blob/0e6499536aa7978828397add2d545d4d7e1052b3/test/rainbowgum-test-jlink/pom.xml#L14 (that is it is not a normal java jar artifact).

On every build we build a jlink app to make sure rainbowgum is jlink-able.

[ppkarwasz]

@agentgt.

@vy Perhaps log4j2 should have a test module or example module (does not need to get deploy to maven central) that creates a JLink application. That is really the ultimate test if the modules (module-info) are correct.

We have a sample JLink application in our samples repository. I was concentrated on our sample GraalVM application, so I admittedly dropped the ball on this one.

Feel free to submit a PR to our Github workflows to trigger the build of the samples repo each time a new snapshot is generated.

[xzel23]

Tested with current 2.24.1 from apache staging (built September 24 2024) and can confirm this is fixed. Thank you!