jna-platform, xalan, batik-script InvalidModuleDescriptorException

Alan Bateman Alan.Bateman at oracle.com
Mon Apr 17 08:42:43 UTC 2017

On 15/04/2017 00:09, Rahman USTA wrote:

> Hi Alan, Mandy,
> Thank you for the hint about keeping classical jars in classpath.
> I use Intellij Idea in development and Maven for building the project. 
> IntelliJ Idea has an early support for Java 9 but it should involve a 
> bit more. For example I didn't see a way to choose which jars will be 
> in classpath and which jars will be in module path.
> As Maven, I also didn't see a way for classpath/modulepath seperation.
This may be something that Robert Scholte or others working on Maven can 
comment on. My understanding is that the Maven Compiler Plugin puts the 
build dependences on the module path when compiling a project that has a 
module-info.java. This means the dependences that aren't explicit 
modules (don't contain a module-info.class) are turned into automatic 
modules. It could instead just add the libraries for the modules that 
are directly or transitively required and leave any remaining 
(non-module) libraries on the class path (with `--add-reads 
<module>=ALL-UNNAMED` to provide the bridge for cases where the 
automatic modules are exposing types on the class path). A combination 
of the module path and class path can be very useful during migration, 
esp. bottom-up. It can also be used when migration top-down but this is 
more complicated and may not be something that all developers want to 
get into.

That said, the exceptions you included were run-time exceptions. As with 
compile-time, you can leave libraries on the class path that won't work 
as automatic modules. That may allow you to make progress until the 
issues with the libraries you found have been fixed.


More information about the jigsaw-dev mailing list