Conflicting access to org.eclipse.jdt.internal.compiler.parser

[malakeel]

I have a small project with module-info.java having:

requires transitive jdk.compiler;
requires transitive java.compiler;
requires transitive java.logging;

requires org.eclipse.osgi;
requires org.eclipse.equinox.common;

requires org.eclipse.jdt.core;
requires org.eclipse.jdt.core.compiler.batch;

The code I am trying to compile:

import javax.tools.DiagnosticCollector;
import javax.tools.JavaCompiler;
import javax.tools.JavaFileObject;
import javax.tools.SimpleJavaFileObject;
import javax.tools.ToolProvider;

import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.jdt.core.dom.AST;
import org.eclipse.jdt.core.dom.ASTParser;
import org.eclipse.jdt.core.dom.CompilationUnit;

String source = """
		import mypackage.Log;
		public class HelloWorld {
			public static void empty() {
				 }
				 public void another(){
				  Log.DEBUG("message", 1, 2 ,3);
				 }
		}
		""";
ASTParser parser = ASTParser.newParser(AST.JLS17);
parser.setSource(source.toCharArray());
parser.setKind(ASTParser.K_COMPILATION_UNIT);
CompilationUnit unit = (CompilationUnit) parser.createAST(new NullProgressMonitor());
org.eclipse.jdt.internal.compiler.parser.Scanner s; // ERROR 
unit.accept(new LogsRouter());

However, I am getting an error in eclipse:

The package org.eclipse.jdt.internal.compiler.parser is accessible from more than one module: org.eclipse.jdt.core, org.eclipse.jdt.core.compiler.batch

If I remove the ERROR line to narrow down the issue, I get:

java.lang.module.ResolutionException: Module org.eclipse.jdt.core contains package org.eclipse.jdt.internal.compiler.parser, module org.eclipse.jdt.core.compiler.batch exports package org.eclipse.jdt.internal.compiler.parser to org.eclipse.jdt.core

My question is how do I require two different modules, accessing the same package ?
Is this an issue with how the jars are built (bug) or I am missing something ?

[iloveeclipse]

Is this an issue with how the jars are built (bug) or I am missing something ?

If I remember right, the jars share few packages historically (the code was written ~ 10 years before module system was invented).

@stephan-herrmann can probably have some idea how to fix that, I'm not a module expert. Maybe some magic in module-info needed.

[stephan-herrmann]

I don't see a simple answer how to consume both jars in their current shape as modules.

How did we get here?

• 25 years ago, JDT/Core produced a single jar org.eclipse.jdt.core_XYZ.jar from which an alternative smaller artifact was extracted at build time, which was then shipped as ecj_XYZ.jar
  • people would consume either ecj or o.e.jdt.core, where the former is a true subset of the latter
• In Extract ECJ compiler code from jdt.core to ecj bundle and make ecj a real plug-in #181 the structure was re-organized: what is shipped as ecj_XYZ.jar was extracted to a separate project / plug-in / jar named org.eclipse.jdt.core.compiler.batch
  • this simplified the build process, enabling us to publish ecj_XYZ.jar by simple renaming of org.eclipse.jdt.core.compiler.batch_XZY.jar
  • for consumers using OSGi not much changed because o.e.jdt.core re-exports o.e.jdt.core.compiler.batch
  • OSGi in particular tolerates the package split created by this reorganization
• Since Java 9 all our jars dutifully declare their Automatic-Module-Name
  • I'm not sure if anybody ever tested consuming these artifacts as JPMS modules, though

What is the problem?

• JPMS does not allow any module to access the same package from two different modules.
• So in a JPMS context o.e.jdt.core cannot require o.e.jdt.core.compiler.batch because
  • o.e.jdt.core would access package ..internal.compiler.parser both from o.e.jdt.core.compiler.batch and from itself

How can this be solved right now?

• I'm afraid consuming o.e.jdt.core as a module is simply not possible with the published jars.
• Consumers could re-package jdt.core by merging both jars into one (the inverse of Extract ECJ compiler code from jdt.core to ecj bundle and make ecj a real plug-in #181)
• Alternatively consumers will have to consume jdt.core from the unnamed module with would require use of --add-reads to make their own module read ALL-UNNAMED (both at compile time and at runtime).

Can we improve this?

• I think we could indeed rename the following packages inside o.e.jdt.core:
  • org.eclipse.jdt.internal.compiler
  • org.eclipse.jdt.internal.compiler.parser
• this would resolve the package split
  • if currently the implementation relies on any in-package access across the bundle boundary, perhaps we have to make a few more things public, but that shouldn't be a problem, given the packages are already "internal".
  • this might break a few clients accessing classes in a package that is being renamed
    • external clients in this category have been warned, they are violating access restrictions
    • "internal clients" under the JDT umbrella are already mentioned as x-friends
• long term it would only be fair to add proper, tested module-info.jar to our artifacts so viability as JPMS modules is checked at build time