I was THIS close to running Ceylon modules with Java 9:
atlantis stephane 18:04 compiler-java $
$HOME/no-backup/src/jdk1.9.0-jigsaw/bin/java -modulepath mlib -m
com.redhat.ceylon.compiler.java.test.interop.java9.user
Error occurred during initialization of VM
java.lang.module.ResolutionException: Cycle detected: ceylon.language ->
com.redhat.ceylon.compiler.java -> ceylon.language
at java.lang.module.Resolver.visit(java.base@9.0/Resolver.java:693)
at java.lang.module.Resolver.visit(java.base@9.0/Resolver.java:702)
at java.lang.module.Resolver.visit(java.base@9.0/Resolver.java:702)
at
java.lang.module.Resolver.detectCycles(java.base@9.0/Resolver.java:678)
at java.lang.module.Resolver.resolve(java.base@9.0/Resolver.java:209)
at java.lang.module.Resolver.resolve(java.base@9.0/Resolver.java:173)
at
java.lang.module.Configuration.resolve(java.base@9.0/Configuration.java:229)
at
jdk.internal.module.ModuleBootstrap.boot(java.base@9.0/ModuleBootstrap.java:180)
at java.lang.System.initPhase2(java.base@9.0/System.java:1263)
So yeah, we support cyclic modules, and in particular our language
module (equivalent of java.base) depends on the compiler which depends
on the language module.
Any plans to relax this, or is there a command-line switch to disable
this check?
PS: for the curious, yes Ceylon modules now generate a module-info.class
and we retrofitted our distrib jars with them too, for the experiment
(this has not been tested at compile-time though, so they might be
incomplete module descriptors so far).
Cheers.
