I'm getting following issues with Jlink -
Error: automatic module cannot be used with jlink
Error: Modules aws.java.sdk.s3 and aws.java.sdk.core export package com.amazonaws.auth to module listenablefuture
I have tried creating a module-info.java with jdeps or using plugins like moditect to generate module-info for the module and inject it in existing JAR. Didn't work.
Is there any other way to create a JRE that includes automatic modules.
I have a JavaFX application that works as expected. I need to use Apache POI to read and write excel files. The following are the steps I have taken:
Added the required dependency
implementation 'org.apache.poi:poi-ooxml:5.2.3'
Added the module to module-info.java
requires org.apache.poi.ooxml;
Tried to use the library within a function:
#FXML
private void downloadTemplate() {
XSSFWorkbook workbook = new XSSFWorkbook();
}
All this is fine with no issues. However when I try to run the application, I get the following two errors (interchanging)
> Task :Start.main() FAILED
Error occurred during initialization of boot layer
java.lang.module.FindException: Module SparseBitSet not found, required by org.apache.poi.ooxml
and
> Task :Start.main() FAILED
Error occurred during initialization of boot layer
java.lang.module.FindException: Module commons.math3 not found, required by org.apache.poi.ooxml
I can however, clearly see both libraries under 'external libraries'
I am using IntelliJ Community Edition 2022.1.2 and running the project using Java 17.0.1. Any help would be highly appreciated.
SparseBitSet is an automatic module, it has no module-info of its own (probably commons-math3 is as well), and is without an Automatic-Module-Name entry in its manifest.
Gradle puts libraries without a module-info.class or an Automatic-Module-Name in their manifest on the class path, not the module path, so they won't be treated as modules, and the module finder won't find them.
You can:
hack the gradle build to allow the modules to be found. (I don't use Gradle so I have no specific advice on how to do that other than referring to the documentation).
Hack the library jar which you want to be treated as a module to include a module-info.class or an Automatic-Module-Name in its manifest.
Or, switch to maven, which automatically places automatic modules on the module path.
The easiest way to do this, IMO, is to create a new JavaFX project in Idea, then add the required dependencies as maven dependencies and add your code.
Or, as swpalmer suggests in the comments, request that library maintainers update their codebase to make their libraries modular.
And, when you run your app, make sure all jars are on the module path, not the class path.
Or, make your app non-modular by removing the module-info.java from it, then manually place the JavaFX modules on the module-path and add them with the --add-modules switch.
FAQ
Are you SURE that automatic modules are put on the class path by Gradle?
From the Gradle documentation section Building Modules for the Java Module System:
To tell the Java compiler that a Jar is a module, as opposed to a
traditional Java library, Gradle needs to place it on the so called
module path. It is an alternative to the classpath, which is the
traditional way to tell the compiler about compiled dependencies.
Gradle will automatically put a Jar of your dependencies on the module
path, instead of the classpath, if these three things are true:
java.modularity.inferModulePath is not turned off
We are actually building a module (as opposed to a traditional
library) which we expressed by adding the module-info.java file.
(Another option is to add the Automatic-Module-Name Jar manifest
attribute as described further down.)
The Jar our module depends on is itself a module, which Gradles
decides based on the presence of a module-info.class — the compiled
version of the module descriptor — in the Jar. (Or, alternatively, the
presence of an Automatic-Module-Name attribute the Jar manifest)
It is the third point that is key. Java can treat a library with no module-info.class and no Automatic-Module-Name in the Jar manifest as an automatic module if it is on the module path. However, Gradle will by default, only place libraries which fulfill one of those two conditions on the module path.
Using jewelsea's answer above, I have been able to solve the problem. I am posting the answer here to help anyone else who encounters the problem in future.
So, the overall problem is, as said in the answer above, both SparseBitSet and commons-math3 are automatic modules with no module-info of their own. The solution that worked for me was to convert them into the modules expected by the project. Here are the steps I took:
Use a gradle plugin 'extra-java-module-info'. The github page didn't show how to import it to a normal gradle file so here it is:
plugins {
id 'org.gradlex.extra-java-module-info' version '1.0'
}
Note the names that your application expects for the modules. In my case, from the error messages thrown, they were 'SparseBitSet' and 'commons-math3'
Locate the said libraries on the sidebar under 'external libraries' and note the 'jar' file names. In my case, they were 'commons-math3-3.6.1.jar' and 'SparseBitSet-1.2.jar'.
Add a section 'extraJavaModuleInfo' to your gradle files and use the parameters as follows: module('jar file name', 'name expected by your project', 'jar version'), as shown in the blue rectangle in the image above.
extraJavaModuleInfo {
module('commons-math3-3.6.1.jar', 'commons.math3', '3.6.1')
module('SparseBitSet-1.2.jar', 'SparseBitSet', '1.2')
}
That's it. Try to sync and run your project. Thanks jewelsea.
Following up on How to define qualified exports to unknown modules? I've posted a testcase with two modules: core and plugin.
core tries to expose a package to plugin using qualified exports but the compiler complains that plugin does not exist. Following up on Alan Bateman's recommendation, I tried adding --module-source-path <path-of-plugin> --module plugin pointing from core to plugin but the compiler complains:
module plugin not found in source path
Why isn't the compiler able to find module plugin?
I figured it out through trial and error.
Use --module-source-path ${project.basedir}/../*/src/main/java to make sure the compiler can see the source-code of both modules.
Use --module core to make sure that the compiler only builds core in spite of seeing all modules.
Tell maven-jar-plugin to package classes from classes/${module.name} instead of just classes because module-source-path causes the output to be prefixed by the module name. I have not found a way to disable this prefix.
The fixed code can be found at https://bitbucket.org/cowwoc/qualified-exports-testcase/
Caveat: This technique only works if the module directory name (the component resolved by *) matches the Java module name. In this particular example the module core had its sources in directory core/src/main/java. If, on the other hand, the directory name was core but the corresponding Java module was org.bitbucket.core then the compilation would fail with module org.bitbucket.core not found in module source path.
I have a library compiled with jdk7. Now, I want to import it in a jdk9 module.
We are using maven to manage the dependencies, but after adding the library into the dependency. We still can’t find the classes in the library. But if we remove the module-info.java, everything is ok.
Here is the problem: we have to deliver a jdk9 module, but we have a lot of jdk7 library dependencies. Is it possible? If it is, how? If it isn’t, is there any alternative way?
package is declared in the unnamed module, but the jdk9 module doesn’t read it it says that your explicit module (which contains module-info) tries to access something in classpath, but in jdk9 it`s forbidden. Instead you can move your jar from classpath to module-path and make it automatic module which can refer both classpath and explicit modules
When I run a main class in IDEA, it puts the module and its dependencies on a module path. Is it possible to change it to a classpath?
If you don't define a module-info, IDEA would set the application and your dependencies on the classpath. Since you have a module-info it's an explicit module so it has to be on the module path. Normally you would handle your dependecies now as automatic-modules.
Howsoever, your dependencies at least have a good reason to be on the classpath. We discussed that here Why Java 9 does not simply turn all JARs on the class path into automatic modules?
For example, mymodule depends on an automatic-module which however needs a jar that can't become an automatic-module yet. On commandline it would like this:
java -cp legacy.jar -p "mymodule.jar;automodule.jar;" -m mymodule/com.example.mymodule.Application
IMO intellij doesn't currently support that. As a workaround to run the entire application on the classpath at least, you could rename the model-info for disabling/not to be a jigsaw-module for a moment.
To answer the question, the heuristic IDEA uses to run an application with a module path is currently slightly off (IDEA 2018.01). It apparently takes more into consideration than it should.
See IDEA-187390 and IDEA-193714 for details.
So if your current project does not have a module-info file and you still end up with a module path the current case that I know is that you are running the main class from a dependency. Just build a small wrapper inside your project and run the main class from there, that brings you back to the classpath.