> In the module, does the non-Java source code reference the Java code or is > it the other way around? It would be useful for thread to understand the > order that they need to be compiled. As you use the term "augment" then I'm > guessing that the Java code is compiled first, without reference to the > non-Java code.
Let's assume that there are both references from Java to non-Java and from non-Java to Java. The compilation order is therefore fixed: first non-Java sources are compiled, then Java sources are compiled. The non-Java compiler is able to read both Java and non-Java sources, and creates .class files for the latter. The Java compiler, on the other hand, cannot read non-Java source files, so it reads the class files compiled by the non-Java compiler on the first step. This is how build tool plugins work today for Kotlin. Also, this is how it _would_ work with Java 9 without any issues, if the destination directory was guaranteed to be the same. But in circumstances where the destination directory could be different for class files compiled by Java and non-Java, I see no way to make the Java compiler read the class files compiled by the non-Java compiler. If they're passed on the classpath (as they are currently on Java 8 and earlier), the classes there are not accessible in Java because the named module cannot read the unnamed module. If they're passed on the module path, they would be loaded in another module, which is incorrect because semantically it's the same module. The original problem of exporting a package I highlighted in the first post is thus only a consequence to this inability to add compiled class files to the currently compiled module. > Maybe a side point for now but I assume the Kotlin compiler doesn't > understand modules yet and so will compile the source "as if" it's in the > unnamed module. This could mean the resulting module is DOA if it references > types in modules that it won't read when the module is resolved. We're working on this currently and this is going to be fixed by the Kotlin compiler being able to read the module-info.java file of the module being compiled, and determining which references are valid and which are not. Alexander
