Exporting a package with no Java sources

[Alexander Udalov]

> 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