Exporting a package with no Java sources

[Alexander Udalov]

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.Bateman at 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