10

I created a simple JMOD file with the jmod tool like this

$JAVA_HOME/bin/jmod create --class-path classes test/samples.jmod

Next, I tried to execute a class within that module by running:

java -mp test -m de.mypackage/de.mypackage.Test

Which resulted in the following exception: 

Error occurred during initialization of VM
java.lang.module.ResolutionException: JMOD files not supported: test/samples.jmod
  at java.lang.module.Resolver.findWithBeforeFinder(java.base@9-ea/Resolver.java:729)
  at java.lang.module.Resolver.resolveRequires(java.base@9-ea/Resolver.java:86)
  at java.lang.module.Configuration.resolveRequiresAndUses(java.base@9-ea/Configuration.java:370)
  at java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base@9-ea/ModuleDescriptor.java:1986)
  at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:263)
  at java.lang.System.initPhase2(java.base@9-ea/System.java:1928)

If I just set my classes directory (that I used to create the JMOD file) as modulepath, everything is working as expected.

Is it generally not possible to have JMOD files on the modulepath? And if this is the case, is there any reason for that?

Omid
  • 5,823
  • 4
  • 41
  • 50
Jan Gassen
  • 3,406
  • 2
  • 26
  • 44

1 Answers1

9

See http://openjdk.java.net/jeps/261#Packaging:-JMOD-files

JMOD files can be used at compile time and link time, but not at run time. To support them at run time would require, in general, that we be prepared to extract and link native-code libraries on-the-fly. This is feasible on most platforms, though it can be very tricky, and we have not seen many use cases that require this capability, so for simplicity we have chosen to limit the utility of JMOD files in this release.

Lagrang
  • 669
  • 4
  • 17
  • 1
    That makes Jigsaw less versatile in the Cloud than e.g. OSGi. Hope it could get addressed eventually, otherwise compared to OSGi and other module systems Jigsaw would risk becoming another "java.util.logging" equivalent, that is part of the JDK but used a lot less than other superior alternatives. – Werner Keil Feb 13 '17 at 15:04
  • I think that Jigsaw has another goals than OSGi. Main aim is JDK modularization which give us more fast startup, less memory consumption and overall more performance. For applications it gives more clean dependency management and enhanced visibility rules. – Lagrang Feb 13 '17 at 16:51
  • 2
    A little, but what I heard about "auto-module" and how Jigsaw plans to override that in the META-INF/MANIFEST I guess it could be synergetic for JARs that should both work as Java 9 modules and prior to that (or in addition) also as OSGi bundles. The goals may not be the same, but ideally you should only need ONE JAR not two for separate module systems ;-) – Werner Keil Feb 14 '17 at 17:42