On 03/07/2017 12:57, Alexander Udalov wrote:
:
Thanks, a dummy class certainly workarounds the problem of javac
reporting a compilation error here. However, I hope there's a better
way because it'd be a bit strange to force users to create a dummy
Java class in every exported package in pure X modules (replace X with
any JVM language that is not Java).
Moreover, as pointed by Jonathan in his answer, I failed to recognize
a larger problem initially, that it wouldn't be possible to refer to
non-Java classes from Java sources anyway. So what I'm really looking
for instead, is the way to "augment" the module currently compiled by
javac with a directory containing class files, emitted by another
compiler.
Still, this workaround could prove helpful for example if there are
not many exported packages in a module (which I assume would be true
for many modules out there), and there are no Java sources in that
module.
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.
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.
-Alan
