when saying "The package javax.xml is accessible from more than one module: <unnamed>, java.xml", pls say which jar or class-folder contains the "unnamed"

[ralfhauser]

Otherwise, when moving from jdk 1.8 to 11, wasting hours !

[ralfhauser]

see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=560635#c8

[ralfhauser]

if the class is present on the classpath, with the following test script, you would see

find /usr/share/tomcat/lib/*.jar > jars.txt me:/tmp$ tcsh me:/tmp> foreach a ( cat jars.txt ) foreach? grep javax.xml.namespace.QName $a foreach? end

Binary file /usr/share/tomcat/lib/xml-apis-1.4.01.jar matches

when moving the listed jars out of the classPath, nothing is found with the script anymore

But even though the script has no hits anymore, eclipse is still unhappy :(

How to turn off this module-check ?

[iloveeclipse]

How to turn off this module-check ?

Switch to Java 8 as compilation target? You are aware, that this is nothing invented by Eclipse, it is Java 9+ module system, so if you compile against Java 9+ you have to resolve all the module related conflicts.

[ralfhauser]

Switch to Java 8 as compilation target?

Thanks a lot - this helped

For all desperate ones (until java9+/eclipse tell you where in which jar the "unnamed" still sit), it must look like this

[ralfhauser]

When removing non-j9+-compatible jars, the Navigation-"Open Type" shows them for quite a while (even twice, when e.g. being a symlink or 1) there is a variable to a directory containing the file even though the variable has not been extended for the particular jar, or 2) when there was a variable extended for a non-versioned symlink )

Only after physically removing the jars from those directories, closing and re-opening the project (restarting eclipse v2022-06 (4.24.0) Build id: 20220609-1112) they finally didn't show anymore.

[ralfhauser]

Even when finally only showing the Type in the jdk

the compilation still fails

(unclear what still is "unnamed")

[stephan-herrmann]

Hint for anyone planning on addressing this issue: There's a technical reason why this enhancement was not immediately implemented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=560635: the compiler proper has no knowledge what so ever about jar files (stuff like jar files / directories is handled by the respective NameEnvironment - note the different implementations for different contexts).

This implies that new data flows would need to be implemented:

(1) When the compiler receives a class file represented by an implementation of IBinaryType that type would need to carry information about a containing jar file, if any. All call paths for creating any implementation of IBinaryType would need to be checked for the need of adding this information.

(2) When a PlainPackageBinding is created, information about an enclosing jar would need to be read from a class file in that package. Unfortunately, creating of a PlainPackageBinding does not have any class file at hand for extracting that information.

Since adding such data flows is a non-trivial task, it might be worth to check the following alternative: rather than recording the necessary info up front, IModuleAwareNameEnvironment could provide new API to ask for containing jars only when a conflict has already been detected. Here the existing API hasCompilationUnit() might serve for inspiration.

At a first glance this alternative might be easier to implement, but note that this API would need to be implemented by all implementors of IModuleAwareNameEnvironment.

[stephan-herrmann]

NameEnvironment is mentioned in https://wiki.eclipse.org/JDT_Core_Programmer_Guide/ECJ#Interfacing_with_other_components as a separate component. Please let me know if more documentation about this beast is needed.