[MCOMPILER-481] JPMS Regression: cannot access <class> (requires static module not include anymore)

[jira-importer]

Simone Bordet opened MCOMPILER-481 and commented

Version 3.8.1 is not affected.

The problem lies in how the module-path is constructed by the maven-compiler-plugin – not sure what changes from 3.8.1 caused this.

In 3.8.1:

-d
  /home/simon/tmp/compiler-bug/app/target/test-classes
-classpath
  /home/simon/tmp/compiler-bug/app/target/test-classes
  /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
  /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
  /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
  /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
  
--module-path
  /home/simon/tmp/compiler-bug/app/target/classes
  /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
  /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
  /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
  /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
  
-sourcepath
  /home/simon/tmp/compiler-bug/app/src/test/java
  /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
  
-s
  /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
-g
-nowarn
--release
  11
-encoding
  UTF-8
--patch-module
  compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
  /home/simon/tmp/compiler-bug/app/src/test/java
  /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
  
--add-reads
  compiler.bug.app=ALL-UNNAMED 

In 3.9.0:

-d
  /home/simon/tmp/compiler-bug/app/target/test-classes
-classpath
  /home/simon/tmp/compiler-bug/app/target/test-classes
  /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
  /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
  /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
  /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
  /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
  /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
  /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
  
--module-path
  /home/simon/tmp/compiler-bug/app/target/classes
  /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
  
-sourcepath
  /home/simon/tmp/compiler-bug/app/src/test/java
  /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
  
-s
  /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
-g
-nowarn
--release
  11
-encoding
  UTF-8
--patch-module
  compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
  /home/simon/tmp/compiler-bug/app/src/test/java
  /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
  
--add-reads
  compiler.bug.app=ALL-UNNAMED 

Running with 3.9.0 yields:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile (default-testCompile) on project compiler-bug-app: Compilation failure
[ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38] cannot access org.eclipse.jetty.util.ajax.JSON
[ERROR]   class file for org.eclipse.jetty.util.ajax.JSON not found 

Class JSON is in {}jetty-util-10.0.7.jar{}.

In 3.9.0 this jar is missing from the module-path, causing the error.

Attached you can find a reproducer: switch the maven-compiler-plugin version from 3.8.1 (works) to 3.9.0 (does not work) in the main POM.

---

Affects: 3.9.0

Attachments:

• compiler-bug.tar.gz (1.55 kB)

Issue Links:

• MCOMPILER-482 JPMS regression: optional transitive module is not found
  ("is duplicated by")

• MJAVADOC-677 Using "requires static transitive" makes javadoc goal fail
  ("is caused by")

• MCOMPILER-482 JPMS regression: optional transitive module is not found

• MCOMPILER-523 MCOMPILER-481 IT fails with Maven 3.9.0

• SUREFIRE-2057 JPMS Regression: requires static module not include anymore

Remote Links:

• GitHub Pull Request #82
  

1 votes, 8 watchers

[jira-importer]

Simone Bordet commented

The setup is that module "app" depends on module "service".

Module "service" has an interface and a default implementation that depends optionally (requires static) on the JSON class (present in the jetty-util-ajax-10.0.7.jar).

Module "app" wants to perform some test, so it has to bind to an implementation (only for the tests – the source still depends only on the interface declared in module "service").

I would have expected that putting jetty-util-ajax-10.0.7.jar in the classpath with --patch-module and --add-reads compiler.bug.app=ALL-UNNAMED would be enough, but apparently it is not, so this may well be a javac compiler bug?

The only alternative I see is to keep track of requires static dependencies, and if a Maven module declares them as a dependency in the POM, then they get added to the module-path?

Robert Scholte, Olivier Lamy, Christian Stein any idea?

Thanks!

[jira-importer]

Robert Scholte commented

Thanks for test-project, that really helps to understand the issue. The handling of static required modules has changed a bit. I need some time to figure out how we want to handle an optional dependencies in this way.

[jira-importer]

Simone Bordet commented

The more I think about this, the more I'm surprised at why --add-reads compiler.bug.app=ALL-UNNAMED is not enough...

[jira-importer]

Olivier Lamy commented

requires static are not include anymore per default (ResolvePathsRequest has includeStatic field false per default).

BTW I tried to change m-compiler-p to ResolvePathsRequest.setIncludeStatic(true) but doesn't work.

Robert Scholte  This commit has some issues codehaus-plexus/plexus-languages@868b3d7 I'm investigating.

Simone Bordet not sure why you need static

requires static org.eclipse.jetty.util.ajax;

Thanks for the test project. As there is no license included do you mind if I include it as a test in the maven-compiler-plugin code?

 

 

[jira-importer]

Robert Scholte commented

Based on the test, it is about supporting "static transitive", which is very unusual but valid. I should have added a cross-link to the original issue in one of the plugins.

[jira-importer]

Robert Scholte commented

ResolvePathsRequest.setIncludeStatic(true) did fix it for me, still wondering if this is the right approach.

[jira-importer]

Robert Scholte commented

Found it, it was MJAVADOC-677 that required this change.

[jira-importer]

Olivier Lamy commented

Robert Scholte  I started a branch called MCOMPILER-481-requires-static-included draft PR #82

This PR include the sample project as a new IT test.

simple change ResolvePathsRequest.setIncludeStatic(true) do not fix the problem

I made some other changes in plexus-java see draft PR codehaus-plexus/plexus-languages#106 the changes fix this problem but there is now 2 test failures

still investigating

 

[jira-importer]

Robert Scholte commented

This is how I think it should work for compilation:
Based on the module descriptor:

• direct static required modules should always be included
• indirect required modules should always be included
• indirect static required modules should not be included

And I agree with Simone Bordet: it is very weird that --add-reads compiler.bug.app=ALL-UNNAMED doesn't work.

To me the adjusted separation between 3.8.1 and 3.9.0 now looks better, maybe we've now hit an issue in the compiler.

[jira-importer]

Simone Bordet commented

Robert Scholte I was thinking a variation of your algorithm above, like this:

From module-info.java files:

1. required modules should be included in module-path
2. transitively resolved required modules should be included in module-path
3. direct static requires modules should be included in module-path
4. indirect static required modules should not be included in module-path

From the POM:

1. every dependency that belongs to any of the categories above (included the last one) should be included in module-path, if not already
2. every dependency that does not belong to the categories above should be included in the class-path.

For my specific case, jetty-util-ajax belongs to category module-info(4), and will be included in the module-path by pom(1), but junit belongs to category pom(2), so it can remain in the class-path (with the usual {}--add-reads <module>=ALL-UNNAMED{}).

Thoughts?

[jira-importer]

Simone Bordet commented

??And I agree with Simone Bordet: it is very weird that --add-reads compiler.bug.app=ALL-UNNAMED doesn't work.??

I'll send an email to compiler-dev, linking this issue.

In any case, it will be fixed for Java 19, perhaps backported, so we still need a workaround in Maven, right?

[jira-importer]

Robert Scholte commented

Simone Bordet smart to add those numbers :) I just don't understand the add-reads is ignored in this case by the compiler.

[jira-importer]

Robert Scholte commented

Let's see what we'll get back from the compiler-dev list. The ResolvePathsRequest has an option to enforce extra modules, maybe we need to expose that as a workaround.

[jira-importer]

Simone Bordet commented

https://mail.openjdk.java.net/pipermail/compiler-dev/2022-January/018989.html

[jira-importer]

Simone Bordet commented

There was a reply in the compiler-dev thread.

IIUC, when the compiler.bug.service module is imported as a dependency, it does not import (because it's a requires static) the jetty-util-ajax jar.

So when compiling the module compiler.bug.app, the "app" module sees the JSON class because of --add-reads compiler.bug.app=ALL-UNNAMED, but the "service" module still does not see it because it's not in the module-path and neither there is an --add-reads for the "service" module.

So it seems a legit Maven Compiler Plugin issue/ feature that needs to be supported.

In light of this information, is my algorithm or Robert Scholte's algorithm the right solution, or something else?