Community
Participate
Working Groups
On project built with maven, when upgrading from 3.25.0 to 3.26.0, using JDK8, I'm getting > Caused by: java.lang.NoSuchFieldError: MODULE_SOURCE_PATH > at org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.getCompilationUnits (EclipseCompilerImpl.java:153) > at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation (Main.java:4790) > at org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.call (EclipseCompilerImpl.java:94) > at org.eclipse.jdt.internal.compiler.tool.EclipseCompiler$1.call (EclipseCompiler.java:196) > at org.codehaus.plexus.compiler.eclipse.EclipseJavaCompiler.performCompile (EclipseJavaCompiler.java:417) > at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1134) > at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:187) I believe it's due to https://github.com/eclipse/eclipse.jdt.core/blob/f1785daee4bc6e01623be6fc0e0047643df6a3e1/org.eclipse.jdt.compiler.tool/src/org/eclipse/jdt/internal/compiler/tool/EclipseCompilerImpl.java#L153 which uses https://docs.oracle.com/javase/9/docs/api/javax/tools/StandardLocation.html#MODULE_SOURCE_PATH - available only since 9. I'm not sure of the version mapping from https://repo.maven.apache.org/maven2/org/eclipse/jdt/ecj/3.26.0 - so selecting the latest 4.21.
Seems related bug 545001
Seems to be introduced in bug 541269
While bug 541269 added the code in question, see also bug 573283 related to the general issue with "modern" javax API/classes used in ecj compiler. We are using Java 9+ classes in ecj compiler that claims to support execution on Java 8, and it was a pure luck we didn't hit the problem before. However, if I remove javax15api.jar from classpath, I see 55 compilation errors in EclipseCompiler, EclipseCompilerImpl, EclipseFileManager and ModuleLocationHandler. Of course not all of them are relevant if running ecj on Java 8 (callbacks that can be only called on Java 9+ are never called on Java 8). It was just matter of time that a particular execution path would run into a problem on old JDK 8. I think the code in querstion misses if (SourceVersion.latest().compareTo(SourceVersion.RELEASE_8) > 0) guard. But honestly, we should stop doing that - the code is extremely complicated already, without Java 8/9+ dancing, so we should stop supporting Java 8, see bug 572389.
(In reply to Andrey Loskutov from comment #3) > so we should stop supporting Java 8, see bug 572389. That is *not* an option until --release 8 works properly. See bug 574181.
(In reply to Thomas Wolf from comment #4) > (In reply to Andrey Loskutov from comment #3) > > so we should stop supporting Java 8, see bug 572389. > > That is *not* an option until --release 8 works properly. See bug 574181. It *is* an option, for sure, if project decides to do so because it has no resources to maintain existing code. Bug 574181 is unrelated - it can be fixed with ecj running on Java 11.
(In reply to Andrey Loskutov from comment #5) > (In reply to Thomas Wolf from comment #4) > > (In reply to Andrey Loskutov from comment #3) > > > so we should stop supporting Java 8, see bug 572389. > > > > That is *not* an option until --release 8 works properly. See bug 574181. > > It *is* an option, for sure, if project decides to do so because it has no > resources to maintain existing code. Bug 574181 is unrelated - it can be > fixed with ecj running on Java 11. Precisely not. If you need to generate code for a Java 8 target but run ECJ on Java 11, you can get calls to Java-11 only API generated. That's bug 574181. The work-around is to run ECJ on Java 8 when you have to generate code for Java 8. If ECJ doesn't support running on Java 8 anymore, you can't use it in a maven build to generate code for Java 8 unless --release 8 works properly.
(In reply to Thomas Wolf from comment #6) > Precisely not. If you need to generate code for a Java 8 target but run ECJ > on Java 11, you can get calls to Java-11 only API generated. That's bug > 574181. The work-around is to run ECJ on Java 8 when you have to generate > code for Java 8. If ECJ doesn't support running on Java 8 anymore, you can't > use it in a maven build to generate code for Java 8 unless --release 8 works > properly. The project decides if ecj should continue to support running on Java 8 with the next release(s) or not. If there are no people left to maintain ecj, it is not a question "if" but "when" the support will be stopped. Please note, one can always use older ecj version to compile on older Java releases or even switch to javac. Note: this discussion should go either to bug 572389 or to bug 574181.
Since JDT team decided to move to Java 11 with bug 572389, closing this as won't Fix
(In reply to Andrey Loskutov from comment #5) > (In reply to Thomas Wolf from comment #4) > > (In reply to Andrey Loskutov from comment #3) > > > so we should stop supporting Java 8, see bug 572389. > > > > That is *not* an option until --release 8 works properly. See bug 574181. > > It *is* an option, for sure, if project decides to do so because it has no > resources to maintain existing code. Bug 574181 is unrelated - it can be > fixed with ecj running on Java 11. Correct me if I am wrong. Is it only about --release 8? I am sure the issue remains when we use a different more recent release value, right? Which makes bug 574181 a must fix?
