module java.base does not “opens java.io” to unnamed module

The error “module java.base does not ‘opens java.io’ to unnamed module” occurs when you are using Java Platform Module System (JPMS) and your code (or a third-party library) tries to access a non-public member of the java.io package from an unnamed module. This access is not allowed by default due to stronger encapsulation enforced by the JPMS.

Solution

To resolve this issue, you can use the --add-opens JVM argument, which allows you to break the encapsulation of the specified module and package combination for the specified target module. Since your error message refers to an unnamed module, you can use the ALL-UNNAMED target.

Add the following JVM argument to your build configuration, IDE settings, or command line:

--add-opens java.base/java.io=ALL-UNNAMED

For Maven, you can add this argument to the maven-compiler-plugin configuration in your pom.xml:

  
    
      org.apache.maven.plugins
      maven-compiler-plugin
      3.8.1
      
        11
        11
        
          --add-opens java.base/java.io=ALL-UNNAMED
        
      
    
  

In Gradle, you can add this argument to the compileJava task in your build.gradle:

compileJava {
    options.compilerArgs.addAll([
            '--add-opens java.base/java.io=ALL-UNNAMED'
    ])
}

For running the application, add the JVM argument to the java command:

java --add-opens java.base/java.io=ALL-UNNAMED -jar your-application.jar

Or, if you are using an IDE like IntelliJ IDEA or Eclipse, you can add the JVM argument to the Run Configuration settings.

After adding the --add-opens JVM argument, the error should be resolved, and your application should compile and run without issues. Keep in mind that using --add-opens can reduce the security and maintainability of your application, so consider refactoring your code or updating third-party libraries to avoid relying on non-public APIs if possible.

Other Solutions

If you continue to experience issues after adding the --add-opens JVM argument, there are a few additional steps you can consider:

  1. Check your dependencies: Ensure that all your project dependencies are compatible with the Java version you are using. In some cases, third-party libraries may need to be updated to support the latest JDK features and encapsulation requirements. Examine your pom.xml or build.gradle file to confirm that you are using the most recent versions of your dependencies.

  2. Review your code: Inspect your code to ensure that it does not rely on non-public APIs or classes from the java.io package. Refactor your code to use public APIs and classes, as this will improve the long-term maintainability and compatibility of your application.

  3. Create a custom runtime image: If you are using JDK 9 or later, you can create a custom runtime image that includes your application and its dependencies using the jlink tool. This will allow you to create a modular application with named modules, which may help you address the encapsulation issue. To do this, you will need to create a module-info.java file for your application and update your build configuration to use the jlink plugin.

  4. Reach out to the community: If you are still experiencing issues after following the steps above, consider reaching out to the Java community or the developers of the third-party library causing the issue. They may be able to provide additional guidance or suggest alternative solutions to help you resolve the problem.

By following these steps, you can improve the compatibility of your application with the Java Platform Module System and address any remaining encapsulation issues that arise. Remember that relying on non-public APIs and classes can lead to compatibility issues and reduced maintainability in the long run, so always strive to use public APIs and classes whenever possible.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.