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