I've been helping to migrate a large Java 8 project ( 100s of plugins/projects integrated as one SWT application to Java 11 ( version Version: 2019-06 (4.12.0) ).

I've been getting Eclipse error messages along the lines of

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

Googling around I learned that these situations always existed, but Eclipse hasn't reported them until now. It seem to be the root of the problem is that Java improved. If you make a "Hello World" program into an executable, you don't need to bundle all of the java libraries with it, only the modules you need. So now there is a module path. If you have a library listed in the module path AND the class path you get the kind of errors I did.

That is my superficial understanding, I'm looking for a deeper one.

Does the module path make the classpath obsolete in an application?

Are there tools for Eclipse to tell you were a conflicting library is located ( or a missing library )?

What is the best practice for resolving these conflicts? Removing the redundant entry from the classpath or module path?

The tiny bit of knowledge I got was from Stackoverflow. If there is a doc that explains it in more depth please point me to it. Bonus points if it explains the mechanics of it "like I am 5"

Edit:

I found the redundant jar by using Ctrl Shift T to open the type editor and the searching on that name.

I have a number of Java 11 module-enabled projects using maven for build. Every time I run a maven update it moves the Maven Dependencies object from the Modulepath to the Classpath, creating linkage errors. I then have to manually edit properties of the project and move it back to Modulepath, which then fixes the errors.

The issue is referenced in the Stack Overflow post here. I've tried to place a modulePath entry in the POM file as described in the answer in that article, but eclipse does not recognize that element under the configuration tree.

I tried updating the version of the maven-compiler-plugin to the latest 3.11.0, which does offer a tantalizing useModulePath entry:

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <release>11</release>
        <useModulePath>true</useModulePath>
    </configuration>
</plugin>

But that doesn't appear to change the behavior. The article here claims that moving the entry from Classpath to Modulepath has no effect, but that is demonstrably false because it removes the third attribute line in the .classpath file:

<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
    <attributes>
        <attribute name="maven.pomderived" value="true"/>
        <attribute name="org.eclipse.jst.component.nondependency" value=""/>
        <attribute name="module" value="true"/>
    </attributes>
</classpathentry>

This approximately matches the change referenced in the first article:

<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
    <attributes>
        <attribute name="maven.pomderived" value="true"/>
        <attribute name="module" value="true"/>
    </attributes>
</classpathentry>

It also causes problems in the eclipse workspace about indirectly referenced class files - the following is an example:

The type software.amazon.awssdk.awscore.client.builder.AwsClientBuilder cannot be resolved.  It is indirectly referenced from required .class files.

If it's not that it's something else - that's just the first error I wrote down to demonstrate the error. My current eclipse version is 2022-06 (4.24.0) and current build ID is 20220609-1112.

I've been having to make the manual change after every rebuild for years - I don't remember it ever working after I moved to maven. I've just ignored it until now, but I'm trying to tie up loose ends before bringing in another developer.

I posted this a few days ago in r/javahelp, but this sub might be more appropriate.