The package XXXXXX is accessible from more than one module: <unnamed>, XXXXXX

[opcoach]

When we are migrating Eclipse RCP projects on new target platforms using java 17, we can get this stupid error :

The package javax.xml.namespace is accessible from more than one module: , java.xml

This is an example with java.xml.namespace but we can have this error also for javax.xml.bind or other libraries..

Actually it means that java.xml is provided by the JDK (java.xml), and by another 'module' which has no name. This unnamed module is basically a plugin without any module name in the eclipse target platform.

I hesitated to open this bug in the PDE, but I have the feeling, this is a JDT issue... because the information is available at this level...

By the way, I got this error when I am building with maven (which probably do not use the JDT), but also in Eclipse with the jdt compiler ...

Something that could be really handy is to change the error message to give more information.

Namely the jdt should provide the name of the missing module (at least its path or whatever that can be used to recognize it (computed classpath used when the module is compiled for instance))... Without this information we have to look in all the code where the java.xml.namespace is used, if this is a plugin dependency or an import package, deal with transitive dependencies, search in the current target platform which plugin is pulling this dependency which should be used as an 'import package' so as to be directly bound to the idk, etc...

What I would like to see in the error message would be :

The package javax.xml.namespace is accessible from more than one module: (from : xxx/xxx/xxx.jar, and java.xml (from jdk 17)...

[stephan-herrmann]

The package javax.xml.namespace is accessible from more than one module: , java.xml

I assume this was (before gitlab scrubbed html-ish stuff):

The package javax.xml.namespace is accessible from more than one module: <unnamed>, java.xml

Unfortunately this is all that the compiler knows at the point.

There are two reasons to it:

• the actual compiler is agnostic to anything like files, it doesn't have the path to the jar file, when the error is detected. (file handling is left to what JLS calls the "host system", and for ecj different such systems are indeed used in batch compilation vs. IDE use, so that separation of concerns is of actual practical value).
• even if we would try to reconstruct the file from the module, it wouldn't help, because the unnamed module is a aggregator for every single classfile on your classpath.

I think you are best helped by performing a little search in the IDE: Ctrl+T and type the package name followed by a .. This will show all classes in that package and should let you spot where those are contributed from.

[stephan-herrmann]

If no-one has an idea how the compiler could collect the desired information, then likely this will be a wontfix, unfortunately.

[opcoach]

Is there may be an information in the target platform instead of the compiler ?

[stephan-herrmann]

Is there may be an information in the target platform instead of the compiler ?

Perhaps, but how could that be used to augment an error message issued by the compiler?

Or are you thinking of a separate analysis provided by PDE?

[opcoach]

Yes that could be an error raised by the PDE. If we have 2 java modules providing the same packages, the error message will be correct I guess because it will be raised by the JDT.

But when an OSGi bundle (without module name) provides the same java packages than another "named" module (from the JDK or from another "module-bundle" named), the message will not contain the bundle ID, because there could be no module name in some cases...

So we could have 2 solutions:

• If we stay on JDT side: may be we could enhance the jdt message to explain : The package javax.xml.namespace is accessible from more than one module: PATH_TO_A_FILE_IN_THEN BUNDLE, java.xml. JDT should remind the path where the problem occurred (which is usually like the bundle name....) instead of writing 'no module name'. And if there is a module name, it's ok. But as you mentioned it, there is unfortunately not this information.

• If we stay on PDE side: if we can detect this JDT error, and if we are exporting (directly or indirectly ?) the concerned packages we could raise another PDE error like : The JDT found this error, it's probably due to this bundle because it's exporting the same packages than java.xml module. If you want to have a more accurate message from the jdt, please name your modules.

Is there a way to listen to JDT raised errors/warning ?

[stephan-herrmann]

• If we stay on JDT side: may be we could enhance the jdt message to explain : The package javax.xml.namespace is accessible from more than one module: PATH_TO_A_FILE_IN_THEN BUNDLE, java.xml. JDT should remind the path where the problem occurred (which is usually like the bundle name....)

This would require to remember the file name for every class visited by the compiler, which might be undesired overhead, since normally this information is 100% unnecessary.

... instead of writing 'no module name'.

Btw. the compiler isn't saying the module lacks a name, but refers to what JPMS calls "the unnamed module", which is the one module comprising all classes from the classpath.

• If we stay on PDE side: if we can detect this JDT error, and if we are exporting (directly or indirectly ?) the concerned packages we could raise another PDE error like : The JDT found this error, it's probably due to this bundle because it's exporting the same packages than java.xml module. If you want to have a more accurate message from the jdt, please name your modules.

Is there a way to listen to JDT raised errors/warning ?

Errors are reported through markers, so an IResourceChangeListener looking for marker deltas would go a long way, I'd say :)
Look for marker type IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER then attribute IJavaModelMarker.ID would have value of IProblem.ConflictingPackageFromModules