Hi Sander, > Have you tried using `--patch-module` during compilation of the Java sources > (as described in http://openjdk.java.net/jeps/261)? Not sure if it works with > class files in the patch directory as well, but it sounds like it could > address your usecase.
This fixes my problem completely (apart from the minor fact that --patch-module's "use in production settings is strongly discouraged", according to the JEP). I've confirmed with the Gradle team that this approach would be fine to compile a mixed-language module. Thank you! On Mon, Jul 3, 2017 at 3:14 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > 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
