Community
Participate
Working Groups
See the attached reproducer. With a version of Eclipse based on the R4_7_maintenance branch, this example compiled fine, and with R4_8_maintenance, it fails. This may be linked to the revamped handling of module to source associations. This revamped handling fixed implicit module resolution (which is broken in R4_7_maintenance) but then broke this simple case: $ find src -type f -name "*.java" -exec sh -c "echo Source file: {} && cat {}; echo ''" \; Source file: src/com.bar/com/bar/foo/Baz.java // Copyright (c) 2018 Synopsys, Inc. All rights reserved worldwide. package com.bar.foo; public class Baz {} Source file: src/com.bar/module-info.java // Copyright (c) 2018 Synopsys, Inc. All rights reserved worldwide. module com.bar { exports com.bar.foo; } Source file: src/com.bar/com/bar/foo/Baz.java // Copyright (c) 2018 Synopsys, Inc. All rights reserved worldwide. package com.bar.foo; public class Baz {} Source file: src/com.bar/module-info.java // Copyright (c) 2018 Synopsys, Inc. All rights reserved worldwide. module com.bar { exports com.bar.foo; } $ ./runEcj.sh +++ find src/com.bar -type f -name '*.java' ++ /opt/pkg/jdk-9.0.1/bin/javac src/com.bar/com/bar/foo/Baz.java src/com.bar/module-info.java Exit of native javac command: 0 +++ find src/com.bar -type f -name '*.java' ++ /opt/pkg/jdk-9.0.1/bin/java --class-path org.eclipse.jdt.core-3.13.101-SNAPSHOT.jar:org.eclipse.jdt.compiler.apt-1.3.60-SNAPSHOT.jar org.eclipse.jdt.internal.compiler.batch.Main -9 --system /opt/pkg/jdk-9.0.1 src/com.bar/com/bar/foo/Baz.java src/com.bar/module-info.java Exit code of preceding command: 0 +++ find src/com.bar -type f -name '*.java' ++ /opt/pkg/jdk-9.0.1/bin/java --class-path org.eclipse.jdt.core-3.14.0-SNAPSHOT.jar:org.eclipse.jdt.compiler.apt-1.3.200-SNAPSHOT.jar org.eclipse.jdt.internal.compiler.batch.Main -9 --system /opt/pkg/jdk-9.0.1 src/com.bar/com/bar/foo/Baz.java src/com.bar/module-info.java ---------- 1. ERROR in /home/rulch/testing/ecj-regression/src/com.bar/module-info.java (at line 3) exports com.bar.foo; ^^^^^^^^^^^ The package com.bar.foo does not exist or is empty ---------- 1 problem (1 error) Exit code of preceding command: 255 +++ find src/com.bar -type f -name '*.java' ++ /opt/pkg/jdk-9.0.1/bin/java --class-path org.eclipse.jdt.core-3.14.0-SNAPSHOT.jar:org.eclipse.jdt.compiler.apt-1.3.200-SNAPSHOT.jar org.eclipse.jdt.internal.compiler.batch.Main -9 --system /opt/pkg/jdk-9.0.1 --module-source-path src -d out src/com.bar/com/bar/foo/Baz.java src/com.bar/module-info.java Exit code with unnecessary injected module-source-path argument: 0 See the attached reproducer -- adjusting the classpath to use your local JARs will be required. The exact version of 4.8 used is commit eb8f27c4b5, tag S4_8_0_RC3.
(In reply to Ryan Ulch from comment #0) Oops, I posted the source file contents twice -- sorry for the confusion.
This issue still exists in R4_10_maintenance. I don't have the time to develop an understanding of the module/file association code in Eclipse, so I've implemented a hack where I specify a module-source-path but avoid the folder name sanity check (since this sanity check is only explicitly enforced by javac for multi-module compilations) in order to work around this. Is this considered a bug or an implementation difference between javac and Eclipse?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
