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.