jna-platform, xalan, batik-script InvalidModuleDescriptorException
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
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