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
y
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 comp
On 7/3/17 6:36 AM, Sander Mak wrote:
On 3 Jul 2017, at 15:23, Alexander Udalov
mailto:alexander.uda...@jetbrains.com>> wrote:
But in circumstances where the destination
directory could be different for class files compiled by Java and
non-Java, I see no way to make the Java compiler read th
On 3 Jul 2017, at 15:23, Alexander Udalov
mailto:alexander.uda...@jetbrains.com>> wrote:
But in circumstances where the destination
directory could be different for class files compiled by Java and
non-Java, I see no way to make the Java compiler read the class files
compiled by the non-Java co
> 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
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 mo
Hi Alan,
> I don't think so, but a dummy class/interface will do (it doesn't have to be
> public). There is a lengthy discussion on this topic in JIRA from 2016 that
> would be useful to link to (but I can't find it just now because JIRA is
> down for maintenance).
Thanks, a dummy class certainly
Hi Jonathan,
> Converting the error to a warning (as was suggested in the original post
> in this thread) would not address the case where the Java source code
> needs to refer to types declared in class files generated from non-Java
> sources.
You're right. For some reason, I was thinking of pa
Right now, javac only looks in one location (i.e. directory + its
subdirectories) for the compiled classes for a module.
It is too late to change this for JDK 9, and even if we could, I think
we are already pushing the limits of what can be specified on the
command line to configure the differ
On 01/07/2017 10:09, Peter Levart wrote:
Hi Alexander,
Have you tried to put a package-info.java into the exported package? It
might work.
I don't think so, but a dummy class/interface will do (it doesn't have
to be public). There is a lengthy discussion on this topic in JIRA from
2016 that w
Hi Alexander,
Have you tried to put a package-info.java into the exported package? It
might work.
Regards, Peter
On Jun 30, 2017 6:42 PM, "Alexander Udalov"
wrote:
> I'm trying to figure out how to compile a mixed-language (in this
> case, Java + Kotlin) JVM module and having a problem in case
I'm trying to figure out how to compile a mixed-language (in this
case, Java + Kotlin) JVM module and having a problem in case the
module tries to export a package without any .java sources in it. The
javac error I get is:
src/module-info.java:2: error: package is empty or does not exist: foo
12 matches
Mail list logo
