Exporting a package with no Java sources

[Jonathan Gibbons]

On 7/3/17 9:11 AM, Alexander Udalov wrote:
> 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!
I think that exhortation applies more to use at runtime. If you're using
it at compile/build time to create a well-formed module that does not
itself need the use of --patch-module, that seems less of an issue.


>
> 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