We Keep Coding

ECLIPSE ERROR: The package javax.xml is accessible from more than one module: , java.xml [duplicate]

When referencing simple .jar files, Eclipse shows an error stating:
The package java.awt is accessible from more than one module: <unnamed>, java.desktop
This happens for instance when javax.awt or javax.swing is included in the .jar files.
The simplest example would be the following:
package test;
import javax.swing.JDialog;
public class Test {
public static void main(String[] args) {
new JDialog();
}
}
Adding a .jar file to the classpath with only the folder structure javax/swing (no files needed) will cause the error to appear. I'm using JDK 10/12 (neither works). Setting the compiler compliance to 1.8 makes the whole thing work again.
On another machine with Eclipse 2018-09 this works with compiler compliance set to 10.
I'm on Eclipse 2019-03, on a (for testing purposes) freshly installed Eclipse 2018-09 it works fine. Why?
Edit June/2020 (Solution)
As the answers correctly stated, this is a restriction built into Java ages ago and only recently was forced upon us. I came into contact with it while migrating a big project with dozens of dependencies to Maven. There were libraries from around the year 2000! There were 'meta libraries' which consisted of several libraries packaged together.
So there was no other way than to identify what was still needed (into the trash with the rest!), update libraries which violate the rules or find replacements for them. This took me many, many hours.
In the end it worked out and we've got a nice Maven project to work with.

This is caused by
a JAR on the Classpath that contains the package java.awt that also exists in the system library but the
JRE System Library is on the Modulepath
In the Java Platform Module System (JPMS) it is not allowed to use the same package in more than one module. If the Modulepath and the Classpath is used, everything on the Classpath is handled as the <unnamed> module (in your case the package java.awt exists in the system module java.desktop and also via the JAR on the Classpath in the module <unnamed>).
Since the JRE System Library cannot be moved from the Modulepath to the Classpath (see this answer by Stephan Herrmann for details), you only have the following options:
Set the compiler compliance to 1.8 (as you already mentioned)
Rebuilt the JAR to avoid Java system library package names inside the JAR (if reflection is used, additional code changes may be necessary):
If you have the source code, change the package names (e.g. change the package and subpackae java to java_util and javax to javax_util) and recreate the JAR
If you have only the .class files you have to decompile the .class files first

Since I'll bet lots of people will be running into this problem with modular Java, I'll help and give the real answer.
This error happens when
you have a dependency in your project
that contains code
using packages
that are also in the modules
being referenced by your project
If your project has set the source compatibility to something like Java 12, it will start enforcing the rule, that has been there all along in Java:
"Don't use packages that belong to the JDK in your own code."
Unfortunately, lots of developers and vendors have done that over the years. Can't do that anymore.
If you set your project to Java 12 source compatibility, Eclipse adds the JDK modules which include everything "java.*" and "javax.*" and even "jdk.*", "org.w3c.*". These packages may be in use by your dependencies or their transitive dependencies.
How to fix
You need to:
look at which package its complaining about
and expand the "Projects and External Dependencies" node in the Package Explorer.
Find out which dependency is using that package.
Then you can simply exclude that dependency from your project.
Or you could get the source of that dependency, if available, and rebuild the jar with changed packages. Otherwise you have to remove that dependency and find a replacement for that technology. Pain huh?
If its a transitive dependency you can often just exclude it. Here is an example of that for Gradle based projects.
GradleConfig.xml:
configurations {
all*.exclude group: 'xml-apis'
}

In my case, it was because I included a dependency (Apache Tika) in the POM.xml file.
I had to force the exclusion of the module that contained the classes with errors while imported at that dependency:
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.24.1</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
It worked for me that way.

I found a simple solution to troubleshoot this in Eclipse. Hit Ctrl + Shift + T in Eclipse to open the Open Type prompt. Then type the name of the package that is causing the issue. For me, it was org.w3c.dom. Now the search results will show all the locations from where this package is being loaded. Remove every JAR from the classpath that comes in the result other than the JDK 11 library.
My project being a legacy one, I had to remove a lot of JARs from the build path. Also, my project does not use Maven. So removing the JARs was a fairly straightforward step. The steps might vary for other build tools like ANT, Maven, Gradle, etc. I have just explained the troubleshooting steps above.

See also: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml where I answered:
Disappointingly I don't see any compiler flags to show what jar the problem is with
Even -Xlint:module doesn't seem to show up anything useful and eclipse doesn't shed any light on the issue
Instead to find where java.awt comes from I've been using this script:
mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
for i in deps/*.jar; do if unzip -l $i| grep -q java.awt; then echo $i; fi ; done
Strictly you don't have to specify the scope test as that's the default but I've included it as you might want to use compile instead

I think my flavour of the problem might be useful.
I got this error for classes under javax.xml.stream, by old Maven projects that depend on artifacts like xml-apis, stax-api, or geronimo-stax-api.
Technically, the problem is what others have already said: those artifacts expose the javax.xml.* package without any awareness of Java modules (they were invented later), so the package is automatically assigned to the unnamed module, which conflicts with the same package being included in the JDK's most recent versions, where the package has its own module name, and therefore the same package results in two different modules, which is forbidden.
That said, the practical solution is essentially to work with Maven exclusions to remove those dependencies from your project and let it use the JDK version instead (or, of course, remove them as direct dependencies, if that's your case). Use the equivalent if you're working with another build system.
In theory, the more recent flavours of these packages offered by the JDK might be non backward-compatible, in practice, I doubt such JSR specifications changed much over the years and so far, I haven't seen any issue with their replacement.

Since this is ranks quite high on Google I'm going to drop this here in case it's helpful for someone.
I've found some interesting behaviour with Java 11 and the xmlbeans library. The xmlbeans library is a transitive dependency of Apache POI, a very popular library for working with Microsoft Office documents, it is used to handle the internal XML structures of the newer Office formats. I've tested it with Apache POI 3.9 and it works perfectly fine, despite the error shown by Eclipse. So, I guess in Java 11 this rule it's not fully enforced.

For Apache POI version 5.0.0 using Maven, in the pom.xml:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>5.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.0.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
Fixed: "The package javax.xml.parsers is accessible from more than one module"

I met a similar issue with the eclipse IDE while upgrading JDK from 1.8 to 11, "The package org.w3c.dom is accessible from more than one module: , java.xml". upgrading eclipse from 2019 to 2021 and setting system JDK home to 11 does not solve it. I don't think it's caused by "org.w3c.dom" existing in different jars of the classpath,dut to "Order and Export" should ordered the search sequence.
After several hours of searching and investigating, this issue is fixed by setting the Java Compiler - Compiler compliance level to 1.8(default is 11).

You can do what other people suggest which is to exclude xml-apis which worked fine with me, but if your are using and an old jaxb-api replace them with jakarta.xml.bind-api:
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.3</version>
</dependency>
and of course upgrade your jaxb-impl to match the same api:
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.3</version>
</dependency>

Steps below helped me,
Right click Eclipse project > Properties > Java Build Path
In Libraries tab, remove all the external jar files under Modulepath and add them under Classpath (you can just select all the jars and drag them under Classpath)
Click Apply and Close
Hope it help you too.

Wow, this was a tough one!
Some helpful tips (a summary of my journey through this maze):
This started when I migrated from Java 1.8 to 11.0.11
Right out of the gate this caused problems. I needed to change the syntax for how to specify the Java version for the maven build plug in as shown below:
Before
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
After
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
After that, everything compiled at a command prompt. However, when opening the project in Eclipse, I got a bunch of errors as shown in the next section.
Getting "<class> cannot be resolved to a type" errors
When I got errors in Eclipse and not at the command line I immediately started looking at configuration settings in Eclipse to no avail. After some googling I came to this post. The post at https://www.eclipse.org/forums/index.php/t/1110036/ was also very helpful.
Finding what resources were the problem
The answer to this post by #Anu suggesting using <shift><ctrl>T to bring up the type search window was very helpful using this I was able to see what resources were causing the problem (i.e. any resource that is also included in the JDK, in my case it was the ErrorHandler in the xml-apis jar). Type the name of one of the resources giving a "cannot be resolved to type" to see the name of the jar file, in my case the jar is xml-apis-1.4.01.jar.
All of this is shown in the screen shot below (click on the image to get a cleaner view).
Finding the Dependency that contains the offending jar
We can now use the information from https://www.eclipse.org/forums/index.php/t/1110036/ to find the dependency in our pom.xml file that contains the offending resource.
Open the pom.xml file in Eclipse and select the "Dependency Hierarchy". In the filter type the name of the jar file we found in the previous step (in my case it was xml-apis).
This will pull up the dependencies creating the problem. A screen shot of the Dependencies Hierarchy filtered for "xml-apis". From this we can see the offending dependencies in our pom.xml file are xercesImpl and xlsx-streamer.
Solving the problem
We can now add exclusions to these dependencies that will resolve the problem as shown below.
<dependency>
<groupId>com.monitorjbl</groupId>
<artifactId>xlsx-streamer</artifactId>
<version>2.1.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.12.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
And this fixes the current problem.

For anyone who suffer with this problem when refering to the org.w3c or javax.xml imports, be careful with this one module dependency: xml-apis it conflicts with java default xml classes.
One big project who references it is called DynamicJasper

Here's the image of my app
It seems to me the real problem here is that the JDK (in my case, JDK-19) has org.w3c.dom embedded in it, so everything else that was doing the correct thing by referencing libraries from external-lib, rather than embedding is now broken. I removed xml-apis and xerces, but it still complains about org.w3c.dom. the only place it is referenced in my project is the JDK.
Removing jar files, (xml-apis.jar and xerces_2_5_0.jar) Does not fix the issue. I cannot remove batik, project depends upon it.
I have a standard Java build, no maven. There is no decompiling/removing a valid reference that can be done with 3rd party software like batik.
Any suggestions on how to remove the embedded org.w3c.dom from JDK-19 so I can build?

I had this problem with the Stanford Core NLP package. As mentioned above adding an exclusion in the pom.xml solved the problem:
<dependency>
<groupId>edu.stanford.nlp</groupId>
<artifactId>stanford-corenlp</artifactId>
<version>4.5.2</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>

First of all, make sure your pom is actually correct by running
mvn install
if that works, and eclipse still complains look at build path and find the library it is holding onto that is not in your pom.
Sometimes I just
rm .classpath
rm -rf .settings
rm -rf project
mvn eclipse:clean eclipse:eclipse

The package org.xml.sax is accessible from more than one module: - need to keep maven dependancy [duplicate]

I'm developing on a Maven project (branch platform-bom_brussels-sr7) in Eclipse. When I recently tried switching the Java Build Path for the project to JDK 10, Eclipse build can no longer find classes such as javax.xml.xpath.XPath, org.w3c.dom.Document, or org.xml.sax.SAXException. It seems only XML related classes are impacted, mostly from the Maven dependency xml-apis-1.4.01.
Trying a Maven build from Eclipse works without errors. Ctrl-LeftClick on one of the supposedly missing classes finds the class and opens it in the Eclipse editor. It seems only the Eclipse build is impacted.
I tried several things, but none helped. I tried:
Project Clean
Different Eclipse Versions: Oxygen and Photon.
Running Eclipse itself with JDK 8 and JDK 10.
Changing Compiler Compliance level for the project. It builds with compliance level 8 and 10 under JDK 8 build path and fails for both with JDK 10 in build path.

I assume that the project being migrated from Java 1.8 still has no module-info.java. This implies you are compiling code in the "unnamed module".
Code in the unnamed module "reads" all observable named and unnamed modules, in particular it reads module "java.xml" from the JRE System Library. This module exports package like java.xml.xpath.
Additionally, you have xml-apis.java on the classpath, which contributes another set of packages of the same names (java.xml.xpath and friends). These are said to be associated to the unnamed module, like your own code.
This situation violates the requirement of "unique visibility" as defined in JLS §7.4.3 (last paragraph). In particular every qualified type name Q.Id (JSL §6.5.5.2) requires that its prefix Q is a uniquely visible package (I'm disregarding the case of nested types for simplicity). Ergo: the program is illegal and must be rejected by compilers.
This leaves us with one question and two solutions:
(1) Question: Why is javac accepting the program?
(2) Solution: If you add module-info.java to your project, you can control via requires which module your project reads, either requires java.xml; or requires xml.apis; (where "xml.apis" is the automatic module name of "xml-apis-1.4.01.jar).
(3) Solution: Short of turning your project into a module, you can still avoid the conflict by excluding java.xml from the set of observable modules. On the command line this would be done using --limit-modules. The equivalent in Eclipse is the "Modularity Details" dialog, see also the JDT 4.8 New&Noteworthy (look for Contents tab). Since java.xml is implicitly required via a lot of other default-observable modules, it may be a good idea to push everything except for java.base from right ("Explicitly included modules") to left ("Available modules") (and selectively re-add those modules that your project needs).
PS: Eclipse still doesn't provide an ideal error message, instead of "cannot be resolved" it should actually say: "The package javax.xml.xpath is accessible from more than one module: javax.xml, <unnamed>.
PPS: Also weird: how come that changing the order between JRE and a jar on the classpath (such ordering is not a concept supported by javac nor JEP 261) changes the behavior of the compiler.
EDITs:
Alex Buckley confirmed that the given situation is illegal, despite what javac says. Bug against javac has been raised as JDK-8215739. This bug has been acknowledged months before the release of Java 12. As of 2019-06 it has been decided that also Java 13 will ship without a fix. Similarly for Java 14. The bug was temporarily scheduled for Java 15, but this plan has been dropped on 2020-04-20.
Eclipse error message has been improved to mention the real problem.
In Eclipse 2019-06 the UI used for Solution (3) has been revamped. Up-to-date documentation can be found in the online help.
As of 2022-12 there's yet another perspective on this issue as described in my other answer. It doesn't invalidate what's said here, but let's things appear in a different light.

In my case the problem was that xercesImpl : 2.10.0 was a (transient) dependency. This jar bundles org.w3c.dom.html.HTMLDOMImplementation.
As far as I understand the org.w3c.dom package then becomes available from two modules, causing the build to fail.
In case one of the dependencies (direct or transient) has classes in one of the 25 packages exported by the java.xml module your build will fail.
Excluding xercesImpl (and also the offenders listed below) in Maven solved the issue for me:
<dependency>
<groupId>xyz</groupId>
<artifactId>xyz</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
...
</exclusion>
</exclusions>
</dependency>
Thanks to Rune Flobakk for giving the hint here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928#c73
Other offenders:
batik-ext : 1.9 (bundles org.w3c.dom.Window)
xom : 1.2.5 (bundles org.w3c.dom.UserDataHandler)
stax-api : 1.0.2 (bundles javax.xml.stream.EventFilter)
xml-apis : 1.4.01 (bundles org.w3c.dom.Document)
xml-beans : 2.3.0 (bundles org.w3c.dom.TypeInfo)

While the accepted answer (by myself) is still correct, a further twist of the story was recently brought to my attention:
The original intention may have been to actually support the situation at hand.
See this quote in the original design document "The State of the Module System" (SotMS):
If a package is defined in both a named module and the unnamed module then the package in the unnamed module is ignored.
That document is dated 2016/3/8 08:18, and already at that time was marked "This document is slightly out of date". Moreover, it is not legally binding for any implementation. Still that document has some relevance since what's quoted above is precisely what javac appears to implement (and still implements many years after JDK-8215739 was filed).
IOW, the conflict is not so much a conflict between 1st and 2nd implementation, but a conflict even within Oracle, so it seems. 2 Votes for supporting the situation (SotMS and javac) and only one vote for disallowing (JLS).
Since Eclipse committers are not inclined to resolve this conflict within Oracle, the recent 2022-12 release of Eclipse has a new compiler option: by adding the following line to a project's .settings/org.eclipse.jdt.core.prefs, a user may opt to ignore JLS in this regard:
org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage=ENABLED
This option puts the decision into the user's hands: do they want JLS-semantics or SotMS/javac semantics (in this particular issue)? Still we were not quite ready to provide a UI option for it, to avoid that users made this choice thoughtlessly, without the background information as provided here.
Personally, I'm not particularly happy about this situation, as it aggravates the fact that Java is not one, but several languages.

This seems to have been reported as Eclipse Bug 536928. Maybe if everyone were to go vote on it it would get them to raise the priority.

What happens here is you have a wildcard import like import org.w3c.dom.*, stating you want to import all classes from package org.w3c.dom. Now, if there's at least one class in org.w3c.dom provided by a second source, Java must not start (as pointed out here).
(By the way, the message "... cannot be resolved" is replaced by a more accurate error message "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" in more recent Eclipse versions, see this merged change request by Stephan Herrmann.)
To resolve this problem
Open the "Open Type" dialog (Ctrl+Shift+T).
Enter the complete import, so org.w3c.dom.* or org.w3c.dom..
Check the entire list for multiple sources. All entries here should contain only something like "jdk-11-...".
Gather all JARs that contain classes you have multiple sources for.
Open the "Dependency Hirarchy" tab from pom.xml.
Search for the JAR file.
Add an exlusion (right click or edit the pom.xml manually).
Example
I had this findbugs dependency in my pom.xml:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>findbugs</artifactId>
<version>${findbugs.version}</version>
</dependency>
Findbugs has two dependencies that need to be excluded:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>findbugs</artifactId>
<version>${findbugs.version}</version>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
</exclusion>
</dependency>

While Stephan Herrmann's answer is the correct one, I'll post my error and how I got it solved if it can help others. I had the error The package javax.xml.namespace is accessible from more than one module: <unnamed>, java.xml and after inspecting the class with the error, it was the javax.xml.namespace.QName import that was complaining. With the "Open Type" dialog, I found out that it was pulled from stax-api through eureka client. This solved it for me :
<exclusion>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
</exclusion>

Have seen something very similar under Eclipse 4.8.0 and JDK 10. E.g.
import org.w3c.dom.Element;
was failing to compile in Eclipse with: The import org.w3c.dom.Element cannot be resolved
Even so, pressing F3 (Open Declaration) on that import, Eclipse was able to open the interface definition - in this case under xml-apis-1.4.01.jar.
Meanwhile, builds from Maven direct were working fine.
In this case the fix was to remove this dependency from the pom.xml:
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.4.01</version>
</dependency>
Then the compile errors in Eclipse melted away. Following F3 again showed the Element interface - now under the java.xml module, under the JRE System Library under the project. Also the Maven build remained fine.
This feels like a problem with Eclipse resolving a class that it finds in both a JDK module and dependent .jar file.
Interestingly, in a separate environment, this time under Eclipse 4.9.0 and JDK 11, all is fine, with or without the xml-apis:1.4.01 dependency.

This is more of a work-around, but from my experience it can be resolved by going to the "Java Build Path", the "Order and Export" tab, and sending the "Maven Dependencies" to the bottom (so it's below the "JRE System Library").

Thanks for this clue. I was having trouble identifying where the conflicting reference was coming from for org.w3c.dom.Document. Found it easily in Eclipse 2020-12 this way: Selected org.w3c.dom.Document within the import statement that Eclipse flagged, right-click and choose Open Type Hierarchy, in the Type Hierarchy dialog right click Document at the top and choose Implementors > Workspace to reveal all the JARs in all projects in the workspace which are bringing in org.w3c.dom.Document (or whatever type you have selected that is accessible from more than one module – MikeOnline yesterday
following the directions above from one of the earlier posts helped us solve our issue.
what we did was replace Document with GenericDocument and Element with GenericElement from batik - and compile errors are gone - now we just have to test to make sure the implementation matches what we had under java 8. Thanks MikeOnline

jdk 9+ brought in changes related to project jigsaw. JDK was broken down into various modules and some modules, javaee, jaxb and xml related, are no more loaded by default. You should add these to your maven build directly, instead of expecting them to be in jre classpath. see this SO question

Eclipse error: The package javax.xml.namespace is accessible from more than one module: <unnamed>, java.xml [duplicate]

I'm developing on a Maven project (branch platform-bom_brussels-sr7) in Eclipse. When I recently tried switching the Java Build Path for the project to JDK 10, Eclipse build can no longer find classes such as javax.xml.xpath.XPath, org.w3c.dom.Document, or org.xml.sax.SAXException. It seems only XML related classes are impacted, mostly from the Maven dependency xml-apis-1.4.01.
Trying a Maven build from Eclipse works without errors. Ctrl-LeftClick on one of the supposedly missing classes finds the class and opens it in the Eclipse editor. It seems only the Eclipse build is impacted.
I tried several things, but none helped. I tried:
Project Clean
Different Eclipse Versions: Oxygen and Photon.
Running Eclipse itself with JDK 8 and JDK 10.
Changing Compiler Compliance level for the project. It builds with compliance level 8 and 10 under JDK 8 build path and fails for both with JDK 10 in build path.

I assume that the project being migrated from Java 1.8 still has no module-info.java. This implies you are compiling code in the "unnamed module".
Code in the unnamed module "reads" all observable named and unnamed modules, in particular it reads module "java.xml" from the JRE System Library. This module exports package like java.xml.xpath.
Additionally, you have xml-apis.java on the classpath, which contributes another set of packages of the same names (java.xml.xpath and friends). These are said to be associated to the unnamed module, like your own code.
This situation violates the requirement of "unique visibility" as defined in JLS §7.4.3 (last paragraph). In particular every qualified type name Q.Id (JSL §6.5.5.2) requires that its prefix Q is a uniquely visible package (I'm disregarding the case of nested types for simplicity). Ergo: the program is illegal and must be rejected by compilers.
This leaves us with one question and two solutions:
(1) Question: Why is javac accepting the program?
(2) Solution: If you add module-info.java to your project, you can control via requires which module your project reads, either requires java.xml; or requires xml.apis; (where "xml.apis" is the automatic module name of "xml-apis-1.4.01.jar).
(3) Solution: Short of turning your project into a module, you can still avoid the conflict by excluding java.xml from the set of observable modules. On the command line this would be done using --limit-modules. The equivalent in Eclipse is the "Modularity Details" dialog, see also the JDT 4.8 New&Noteworthy (look for Contents tab). Since java.xml is implicitly required via a lot of other default-observable modules, it may be a good idea to push everything except for java.base from right ("Explicitly included modules") to left ("Available modules") (and selectively re-add those modules that your project needs).
PS: Eclipse still doesn't provide an ideal error message, instead of "cannot be resolved" it should actually say: "The package javax.xml.xpath is accessible from more than one module: javax.xml, <unnamed>.
PPS: Also weird: how come that changing the order between JRE and a jar on the classpath (such ordering is not a concept supported by javac nor JEP 261) changes the behavior of the compiler.
EDITs:
Alex Buckley confirmed that the given situation is illegal, despite what javac says. Bug against javac has been raised as JDK-8215739. This bug has been acknowledged months before the release of Java 12. As of 2019-06 it has been decided that also Java 13 will ship without a fix. Similarly for Java 14. The bug was temporarily scheduled for Java 15, but this plan has been dropped on 2020-04-20.
Eclipse error message has been improved to mention the real problem.
In Eclipse 2019-06 the UI used for Solution (3) has been revamped. Up-to-date documentation can be found in the online help.
As of 2022-12 there's yet another perspective on this issue as described in my other answer. It doesn't invalidate what's said here, but let's things appear in a different light.

In my case the problem was that xercesImpl : 2.10.0 was a (transient) dependency. This jar bundles org.w3c.dom.html.HTMLDOMImplementation.
As far as I understand the org.w3c.dom package then becomes available from two modules, causing the build to fail.
In case one of the dependencies (direct or transient) has classes in one of the 25 packages exported by the java.xml module your build will fail.
Excluding xercesImpl (and also the offenders listed below) in Maven solved the issue for me:
<dependency>
<groupId>xyz</groupId>
<artifactId>xyz</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
...
</exclusion>
</exclusions>
</dependency>
Thanks to Rune Flobakk for giving the hint here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928#c73
Other offenders:
batik-ext : 1.9 (bundles org.w3c.dom.Window)
xom : 1.2.5 (bundles org.w3c.dom.UserDataHandler)
stax-api : 1.0.2 (bundles javax.xml.stream.EventFilter)
xml-apis : 1.4.01 (bundles org.w3c.dom.Document)
xml-beans : 2.3.0 (bundles org.w3c.dom.TypeInfo)

While the accepted answer (by myself) is still correct, a further twist of the story was recently brought to my attention:
The original intention may have been to actually support the situation at hand.
See this quote in the original design document "The State of the Module System" (SotMS):
If a package is defined in both a named module and the unnamed module then the package in the unnamed module is ignored.
That document is dated 2016/3/8 08:18, and already at that time was marked "This document is slightly out of date". Moreover, it is not legally binding for any implementation. Still that document has some relevance since what's quoted above is precisely what javac appears to implement (and still implements many years after JDK-8215739 was filed).
IOW, the conflict is not so much a conflict between 1st and 2nd implementation, but a conflict even within Oracle, so it seems. 2 Votes for supporting the situation (SotMS and javac) and only one vote for disallowing (JLS).
Since Eclipse committers are not inclined to resolve this conflict within Oracle, the recent 2022-12 release of Eclipse has a new compiler option: by adding the following line to a project's .settings/org.eclipse.jdt.core.prefs, a user may opt to ignore JLS in this regard:
org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage=ENABLED
This option puts the decision into the user's hands: do they want JLS-semantics or SotMS/javac semantics (in this particular issue)? Still we were not quite ready to provide a UI option for it, to avoid that users made this choice thoughtlessly, without the background information as provided here.
Personally, I'm not particularly happy about this situation, as it aggravates the fact that Java is not one, but several languages.

This seems to have been reported as Eclipse Bug 536928. Maybe if everyone were to go vote on it it would get them to raise the priority.

What happens here is you have a wildcard import like import org.w3c.dom.*, stating you want to import all classes from package org.w3c.dom. Now, if there's at least one class in org.w3c.dom provided by a second source, Java must not start (as pointed out here).
(By the way, the message "... cannot be resolved" is replaced by a more accurate error message "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" in more recent Eclipse versions, see this merged change request by Stephan Herrmann.)
To resolve this problem
Open the "Open Type" dialog (Ctrl+Shift+T).
Enter the complete import, so org.w3c.dom.* or org.w3c.dom..
Check the entire list for multiple sources. All entries here should contain only something like "jdk-11-...".
Gather all JARs that contain classes you have multiple sources for.
Open the "Dependency Hirarchy" tab from pom.xml.
Search for the JAR file.
Add an exlusion (right click or edit the pom.xml manually).
Example
I had this findbugs dependency in my pom.xml:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>findbugs</artifactId>
<version>${findbugs.version}</version>
</dependency>
Findbugs has two dependencies that need to be excluded:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>findbugs</artifactId>
<version>${findbugs.version}</version>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
</exclusion>
</dependency>

While Stephan Herrmann's answer is the correct one, I'll post my error and how I got it solved if it can help others. I had the error The package javax.xml.namespace is accessible from more than one module: <unnamed>, java.xml and after inspecting the class with the error, it was the javax.xml.namespace.QName import that was complaining. With the "Open Type" dialog, I found out that it was pulled from stax-api through eureka client. This solved it for me :
<exclusion>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
</exclusion>

Have seen something very similar under Eclipse 4.8.0 and JDK 10. E.g.
import org.w3c.dom.Element;
was failing to compile in Eclipse with: The import org.w3c.dom.Element cannot be resolved
Even so, pressing F3 (Open Declaration) on that import, Eclipse was able to open the interface definition - in this case under xml-apis-1.4.01.jar.
Meanwhile, builds from Maven direct were working fine.
In this case the fix was to remove this dependency from the pom.xml:
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.4.01</version>
</dependency>
Then the compile errors in Eclipse melted away. Following F3 again showed the Element interface - now under the java.xml module, under the JRE System Library under the project. Also the Maven build remained fine.
This feels like a problem with Eclipse resolving a class that it finds in both a JDK module and dependent .jar file.
Interestingly, in a separate environment, this time under Eclipse 4.9.0 and JDK 11, all is fine, with or without the xml-apis:1.4.01 dependency.

This is more of a work-around, but from my experience it can be resolved by going to the "Java Build Path", the "Order and Export" tab, and sending the "Maven Dependencies" to the bottom (so it's below the "JRE System Library").

Thanks for this clue. I was having trouble identifying where the conflicting reference was coming from for org.w3c.dom.Document. Found it easily in Eclipse 2020-12 this way: Selected org.w3c.dom.Document within the import statement that Eclipse flagged, right-click and choose Open Type Hierarchy, in the Type Hierarchy dialog right click Document at the top and choose Implementors > Workspace to reveal all the JARs in all projects in the workspace which are bringing in org.w3c.dom.Document (or whatever type you have selected that is accessible from more than one module – MikeOnline yesterday
following the directions above from one of the earlier posts helped us solve our issue.
what we did was replace Document with GenericDocument and Element with GenericElement from batik - and compile errors are gone - now we just have to test to make sure the implementation matches what we had under java 8. Thanks MikeOnline

jdk 9+ brought in changes related to project jigsaw. JDK was broken down into various modules and some modules, javaee, jaxb and xml related, are no more loaded by default. You should add these to your maven build directly, instead of expecting them to be in jre classpath. see this SO question

The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml

I am unable to import org.w3c.dom.NodeList package to Eclipse. It is showing
The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error message in eclipse.
Please let me know how to fix this ?
Eclipse Version:
Eclipse IDE for Enterprise Java Developers.
Version: 2019-06 (4.12.0)
Build id: 20190614-1200
Java version:
java version "12.0.1" 2019-04-16
Java(TM) SE Runtime Environment (build 12.0.1+12)
Java HotSpot(TM) 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)

I had a similar issue because of a transitive xml-apis dependency. I resolved it using a Maven exclusion:
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>fop</artifactId>
<version>0.95</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
Another dependency that just causes trouble and I don't have a solution other than removing it is this one:
<dependency>
<groupId>com.oracle.database.xml</groupId>
<artifactId>xmlparserv2</artifactId>
<version>${oracle.version}</version>
</dependency>
Use mvn dependency:tree to see who brings in the transitive dependency, and then exclude that from there.

Disappointingly I don't see any compiler flags to show what jar the problem is with
Even -Xlint:module doesn't seem to show up anything useful and eclipse doesn't shed any light on the issue
Instead to find where org.w3c.dom comes from I've been using this script:
mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
for i in deps/*.jar; do if unzip -l $i| grep -q org.w3c.dom; then echo $i; fi ; done
Strictly you don't have to specify the scope test as that's the default but I've included it as you might want to use compile instead

On my side, I've spent a few hours to understand my issue, really closed to this one.
The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml
I wanted to migrate a project from Java 8 to Java 11. A few library issues. Easy to fix. But on this one,
I've tried to create module-info.java → it was worst.
Find a issue on my OS (debian 10)
→ even if Java 11 was default JRE, $JAVA_HOME was not rightly set for
maven build. And when I was thinking it was only an Eclipse issue, I finally consider that it was a global compilation problem. To fix this I had to add following line in ~/.mavenrc
JAVA_HOME=/usr/lib/jvm/default-java
Deep analysis on maven dependencies shows me a third-level dependency on xom.jar which trigger the issue. Dependency was linked to Saxon HE library → an upgrade to VERSION 9.9.X has resolved this boring problem.
Hope this will helps other people.

In my case, it was caused by combining the usage of:
JDK 11
dom4j 2.1.3 library
As pointed out by others, the root cause is that dom4j and its dependencies (e.g., pull-parser) use some packages names (javax.xml.parsers, org.w3c.dom) that have been used by the JDK.
I had to remove dom4j to solve the problem. Just use JDK's own XML api.

In my case, culprit was Apache POI library. Added exclusion as below
<!-- Apache POI Library for Parsing Excel Sheets -->
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.0.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans</artifactId>
</exclusion>
</exclusions>
</dependency>

For Java 9 and higher Delete org.w3c.dom jar file from the class path, and you are done. By the way delete module info file too. You don't need to add the external jar file, its already included in the system library of java 9 and higher.

Just open the configure build path and verify the modules which are all you have added as part of the project, which contains the class files as *
org.w3c.dom
This error, we usually gets in Java due to same kind of multiple API packages added in one project.
As, am using the same version as you mentioned, am not facing any issues., so just make sure that you don't have any duplicate modules.

org.w3c.dom is used in:
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans</artifactId>
<version>2.4.0</version>
</dependency>
Check if this is imported transitively via some other dependency.
Exclude the same
Add dependency for:
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans</artifactId>
<version>2.6.0</version>
</dependency>

In my case I was using:
JDK 14 and xmlbeans.jar library.
I just had to remove the xmlbeans.jar library and it surely solved the issue.

You can use this code (for example in a unit test) to determine all JARs that contain a class:
getClass().getClassLoader().getResources("org/w3c/dom/NodeList.class");
This gives you an Enumeration. The easiest way to print this is:
Collections.list(e).forEach(System.out::println);

If you are in a simple Java Project, not Maven.
Then just remove the dom-jaxb jar from the Libraries.
Steps :
Right click on project -> Properties -> Java BuildPath -> Libraries Tab -> select on jars such as dom-2.3.0-jaxb-1.0.6(version might differ) -> Remove.
Now it will build without error.
The error is occurring because "org.w3c.dom.Document" is coming from both the removed "dom-2.3.0-jaxb-1.0.6" jar and from Java's in-built libraries. Removing additional jar will let it come only from Java's in-built libraries.

You need to manually check and remove all the jars (libraries) which has the possibility of conflicting with java.xml package.
In my case, I edited my .classpath file and removed the following jars and it resolved the issue:
jtidy.jar, castor-0.9.5.4-xml.jar, xercesImpl.jar, xml-apis.jar

In a Gradle land, you can track down which dependencies are contributing to xml-apis by running:
gradlew -q dependencies
(or core:dependencies for the core project in a multi-project environment).
In my case, xml-apis was being requested by both net.sourceforge.htmlunit and xom, so the solution is to exclude xml-apis in your build.gradle as so:
dependencies {
implementation("net.sourceforge.htmlunit:neko-htmlunit:$nekoHtmlUnitVersion") {
exclude group: "xml-apis"
}
testImplementation("xom:xom:$xomVersion") {
exclude group: "xml-apis"
}
// ...other dependencies
}

Sometimes even when you have removed duplicate classes the same error "The package org.w3c.dom is accessible from more than one module" may remain, especially with IDEs.
IT IS NOT always enought to find only org.w3c.dom!!!! You may need to remove duplicate classes which share the same parent package org.w3c.xxx, for example org.w3c.css
We managed to fix it like this:
In IDE search classes starting with: org.w3c
Add pom.xml exclusions or increase library version, since org.w3c has been removed in some newer lib versions
Test compile in both IDE and command line
If the issue persists:
Export all dependencies to file: mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
From jar-files find any classes of org.w3c
Keep adjusting pom.xml

Eclipse can't find XML related classes after switching build path to JDK 10

I'm developing on a Maven project (branch platform-bom_brussels-sr7) in Eclipse. When I recently tried switching the Java Build Path for the project to JDK 10, Eclipse build can no longer find classes such as javax.xml.xpath.XPath, org.w3c.dom.Document, or org.xml.sax.SAXException. It seems only XML related classes are impacted, mostly from the Maven dependency xml-apis-1.4.01.
Trying a Maven build from Eclipse works without errors. Ctrl-LeftClick on one of the supposedly missing classes finds the class and opens it in the Eclipse editor. It seems only the Eclipse build is impacted.
I tried several things, but none helped. I tried:
Project Clean
Different Eclipse Versions: Oxygen and Photon.
Running Eclipse itself with JDK 8 and JDK 10.
Changing Compiler Compliance level for the project. It builds with compliance level 8 and 10 under JDK 8 build path and fails for both with JDK 10 in build path.

I assume that the project being migrated from Java 1.8 still has no module-info.java. This implies you are compiling code in the "unnamed module".
Code in the unnamed module "reads" all observable named and unnamed modules, in particular it reads module "java.xml" from the JRE System Library. This module exports package like java.xml.xpath.
Additionally, you have xml-apis.java on the classpath, which contributes another set of packages of the same names (java.xml.xpath and friends). These are said to be associated to the unnamed module, like your own code.
This situation violates the requirement of "unique visibility" as defined in JLS §7.4.3 (last paragraph). In particular every qualified type name Q.Id (JSL §6.5.5.2) requires that its prefix Q is a uniquely visible package (I'm disregarding the case of nested types for simplicity). Ergo: the program is illegal and must be rejected by compilers.
This leaves us with one question and two solutions:
(1) Question: Why is javac accepting the program?
(2) Solution: If you add module-info.java to your project, you can control via requires which module your project reads, either requires java.xml; or requires xml.apis; (where "xml.apis" is the automatic module name of "xml-apis-1.4.01.jar).
(3) Solution: Short of turning your project into a module, you can still avoid the conflict by excluding java.xml from the set of observable modules. On the command line this would be done using --limit-modules. The equivalent in Eclipse is the "Modularity Details" dialog, see also the JDT 4.8 New&Noteworthy (look for Contents tab). Since java.xml is implicitly required via a lot of other default-observable modules, it may be a good idea to push everything except for java.base from right ("Explicitly included modules") to left ("Available modules") (and selectively re-add those modules that your project needs).
PS: Eclipse still doesn't provide an ideal error message, instead of "cannot be resolved" it should actually say: "The package javax.xml.xpath is accessible from more than one module: javax.xml, <unnamed>.
PPS: Also weird: how come that changing the order between JRE and a jar on the classpath (such ordering is not a concept supported by javac nor JEP 261) changes the behavior of the compiler.
EDITs:
Alex Buckley confirmed that the given situation is illegal, despite what javac says. Bug against javac has been raised as JDK-8215739. This bug has been acknowledged months before the release of Java 12. As of 2019-06 it has been decided that also Java 13 will ship without a fix. Similarly for Java 14. The bug was temporarily scheduled for Java 15, but this plan has been dropped on 2020-04-20.
Eclipse error message has been improved to mention the real problem.
In Eclipse 2019-06 the UI used for Solution (3) has been revamped. Up-to-date documentation can be found in the online help.
As of 2022-12 there's yet another perspective on this issue as described in my other answer. It doesn't invalidate what's said here, but let's things appear in a different light.

In my case the problem was that xercesImpl : 2.10.0 was a (transient) dependency. This jar bundles org.w3c.dom.html.HTMLDOMImplementation.
As far as I understand the org.w3c.dom package then becomes available from two modules, causing the build to fail.
In case one of the dependencies (direct or transient) has classes in one of the 25 packages exported by the java.xml module your build will fail.
Excluding xercesImpl (and also the offenders listed below) in Maven solved the issue for me:
<dependency>
<groupId>xyz</groupId>
<artifactId>xyz</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
...
</exclusion>
</exclusions>
</dependency>
Thanks to Rune Flobakk for giving the hint here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928#c73
Other offenders:
batik-ext : 1.9 (bundles org.w3c.dom.Window)
xom : 1.2.5 (bundles org.w3c.dom.UserDataHandler)
stax-api : 1.0.2 (bundles javax.xml.stream.EventFilter)
xml-apis : 1.4.01 (bundles org.w3c.dom.Document)
xml-beans : 2.3.0 (bundles org.w3c.dom.TypeInfo)

While the accepted answer (by myself) is still correct, a further twist of the story was recently brought to my attention:
The original intention may have been to actually support the situation at hand.
See this quote in the original design document "The State of the Module System" (SotMS):
If a package is defined in both a named module and the unnamed module then the package in the unnamed module is ignored.
That document is dated 2016/3/8 08:18, and already at that time was marked "This document is slightly out of date". Moreover, it is not legally binding for any implementation. Still that document has some relevance since what's quoted above is precisely what javac appears to implement (and still implements many years after JDK-8215739 was filed).
IOW, the conflict is not so much a conflict between 1st and 2nd implementation, but a conflict even within Oracle, so it seems. 2 Votes for supporting the situation (SotMS and javac) and only one vote for disallowing (JLS).
Since Eclipse committers are not inclined to resolve this conflict within Oracle, the recent 2022-12 release of Eclipse has a new compiler option: by adding the following line to a project's .settings/org.eclipse.jdt.core.prefs, a user may opt to ignore JLS in this regard:
org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage=ENABLED
This option puts the decision into the user's hands: do they want JLS-semantics or SotMS/javac semantics (in this particular issue)? Still we were not quite ready to provide a UI option for it, to avoid that users made this choice thoughtlessly, without the background information as provided here.
Personally, I'm not particularly happy about this situation, as it aggravates the fact that Java is not one, but several languages.

This seems to have been reported as Eclipse Bug 536928. Maybe if everyone were to go vote on it it would get them to raise the priority.

What happens here is you have a wildcard import like import org.w3c.dom.*, stating you want to import all classes from package org.w3c.dom. Now, if there's at least one class in org.w3c.dom provided by a second source, Java must not start (as pointed out here).
(By the way, the message "... cannot be resolved" is replaced by a more accurate error message "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" in more recent Eclipse versions, see this merged change request by Stephan Herrmann.)
To resolve this problem
Open the "Open Type" dialog (Ctrl+Shift+T).
Enter the complete import, so org.w3c.dom.* or org.w3c.dom..
Check the entire list for multiple sources. All entries here should contain only something like "jdk-11-...".
Gather all JARs that contain classes you have multiple sources for.
Open the "Dependency Hirarchy" tab from pom.xml.
Search for the JAR file.
Add an exlusion (right click or edit the pom.xml manually).
Example
I had this findbugs dependency in my pom.xml:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>findbugs</artifactId>
<version>${findbugs.version}</version>
</dependency>
Findbugs has two dependencies that need to be excluded:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>findbugs</artifactId>
<version>${findbugs.version}</version>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
</exclusion>
</dependency>

While Stephan Herrmann's answer is the correct one, I'll post my error and how I got it solved if it can help others. I had the error The package javax.xml.namespace is accessible from more than one module: <unnamed>, java.xml and after inspecting the class with the error, it was the javax.xml.namespace.QName import that was complaining. With the "Open Type" dialog, I found out that it was pulled from stax-api through eureka client. This solved it for me :
<exclusion>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
</exclusion>

Have seen something very similar under Eclipse 4.8.0 and JDK 10. E.g.
import org.w3c.dom.Element;
was failing to compile in Eclipse with: The import org.w3c.dom.Element cannot be resolved
Even so, pressing F3 (Open Declaration) on that import, Eclipse was able to open the interface definition - in this case under xml-apis-1.4.01.jar.
Meanwhile, builds from Maven direct were working fine.
In this case the fix was to remove this dependency from the pom.xml:
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.4.01</version>
</dependency>
Then the compile errors in Eclipse melted away. Following F3 again showed the Element interface - now under the java.xml module, under the JRE System Library under the project. Also the Maven build remained fine.
This feels like a problem with Eclipse resolving a class that it finds in both a JDK module and dependent .jar file.
Interestingly, in a separate environment, this time under Eclipse 4.9.0 and JDK 11, all is fine, with or without the xml-apis:1.4.01 dependency.

This is more of a work-around, but from my experience it can be resolved by going to the "Java Build Path", the "Order and Export" tab, and sending the "Maven Dependencies" to the bottom (so it's below the "JRE System Library").

Thanks for this clue. I was having trouble identifying where the conflicting reference was coming from for org.w3c.dom.Document. Found it easily in Eclipse 2020-12 this way: Selected org.w3c.dom.Document within the import statement that Eclipse flagged, right-click and choose Open Type Hierarchy, in the Type Hierarchy dialog right click Document at the top and choose Implementors > Workspace to reveal all the JARs in all projects in the workspace which are bringing in org.w3c.dom.Document (or whatever type you have selected that is accessible from more than one module – MikeOnline yesterday
following the directions above from one of the earlier posts helped us solve our issue.
what we did was replace Document with GenericDocument and Element with GenericElement from batik - and compile errors are gone - now we just have to test to make sure the implementation matches what we had under java 8. Thanks MikeOnline

jdk 9+ brought in changes related to project jigsaw. JDK was broken down into various modules and some modules, javaee, jaxb and xml related, are no more loaded by default. You should add these to your maven build directly, instead of expecting them to be in jre classpath. see this SO question