Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Old ERP system on Java 11 classpath only
Old ERP system on Java 11 classpath only [message #1804909] Wed, 03 April 2019 07:59 Go to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 825
Registered: July 2009
Senior Member
Migrating an old ERP system to JPMS turned out to be highly problematic (https://stackoverflow.com/questions/55256736/java-11-eclipse-finds-automatic-module-maven-does-not), so I decided to first try and simply replace Java 8 with Java 11, but keep everything on the classpath by not introducing any module-info.java files. That actually went quite smoothly; Maven is compiling this without problems, and the resulting application also starts from the command line.

But when I import that Maven project into Eclipse 2019-03 it complains about a.o. java's xml packages, for example this import:

import javax.xml.namespace.QName;

This makes sense, because the JRE is modularized, and those classes are in the java.xml module which I am not included. But why is Maven then compiling correctly AND the application starting under J11?

I suspect I need to tell Eclipse to "--add-modules=ALL-SYSTEM" for this project, but I'm not sure where or how. I've tried moving all the JDK/JRE modules in the build-path/libraries from implicit to explicit, but that does not help.
Re: Old ERP system on Java 11 classpath only [message #1804964 is a reply to message #1804909] Wed, 03 April 2019 20:43 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Quote:
But when I import that Maven project into Eclipse 2019-03 it complains about a.o. java's xml packages, for example this import:
import javax.xml.namespace.QName;


What error are you seeing? "cannot be resolved", or package "is accessible from more than one module"?

When comparing maven + javac vs. eclipse vs. jvm it is always good to closely inspect the command line used to invoke compiler and vm. Some tools will synthesize some of the new options.
Re: Old ERP system on Java 11 classpath only [message #1804967 is a reply to message #1804964] Thu, 04 April 2019 03:42 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 825
Registered: July 2009
Senior Member
I see a "cannot be resolved".

I understand what you are saying, but in that case I would expect the Eclipse Maven plugin to make sure the Eclipse project is setup to mimick Maven's behavior as close as possible. Just as was done with the src/test folders, compiler version, etc. And it's not that I'm using an obscure tool, so I expect more people will run into this, when migrating to the next LTS Java version.

[Updated on: Thu, 04 April 2019 03:43]

Report message to a moderator

Re: Old ERP system on Java 11 classpath only [message #1804979 is a reply to message #1804967] Thu, 04 April 2019 07:59 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Quote:
I understand what you are saying, but in that case I would expect ...

Slowly. I didn't (yet) imply any conclusion, just mentioned things to look out for, to understand what is the root of your problem.

Quote:
I see a "cannot be resolved".


Interesting. In this case please show us the arguments that Maven passes to the compiler (use mvn -X). And in case it has some variant of "--add-modules" please check your pom, to figure out where this might be coming from.
Re: Old ERP system on Java 11 classpath only [message #1804980 is a reply to message #1804979] Thu, 04 April 2019 08:19 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 825
Registered: July 2009
Senior Member
I've stripped out all the dependencies (there A LOT) and copied the relevant part from the maven output, but I see nothing special about modules in there:

[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile' with basic configurator -->
[DEBUG]   (f) basedir = C:\Users\user\Documents\...\bm
[DEBUG]   (f) buildDirectory = C:\Users\user\Documents\...\bm\target
[DEBUG]   (f) compilePath = [C:\Users\user\Documents\...\bm\target\classes, C:\Users\user\.m2\repository\...
[DEBUG]   (f) compileSourceRoots = [C:\Users\user\Documents\...\bm\java]
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) encoding = Cp1252
[DEBUG]   (f) failOnError = true
[DEBUG]   (f) failOnWarning = false
[DEBUG]   (f) forceJavacCompilerUse = false
[DEBUG]   (f) fork = false
[DEBUG]   (f) generatedSourcesDirectory = C:\Users\user\Documents\...\bm\target\generated-sources\annotations
[DEBUG]   (f) mojoExecution = org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile {execution: default-compile}
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = C:\Users\user\Documents\...\bm\target\classes
[DEBUG]   (f) parameters = false
[DEBUG]   (f) project = MavenProject: nl.reinders:ReindersBM:20190327c @ C:\Users\user\Documents\...\bm\pom.xml
[DEBUG]   (f) projectArtifact = nl.reinders:ReindersBM:jar:20190327c
[DEBUG]   (f) session = org.apache.maven.execution.MavenSession@37854b34
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) skipMultiThreadWarning = false
[DEBUG]   (f) source = 11
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (s) target = 11
[DEBUG]   (f) useIncrementalCompilation = true
[DEBUG]   (f) verbose = false
...
[DEBUG] Command line options:
[DEBUG] 
-d C:\Users\user\Documents\...\bm\target\classes 
-classpath C:\Users\user\Documents\...\bm\target\classes;C:\Users\user\.m2\repository...
-sourcepath C:\Users\user\Documents\...\bm\java;C:\Users\user\Documents\...\bm\target\generated-sources\annotations; 
-s C:\Users\user\Documents\...\bm\target\generated-sources\annotations
-g
-nowarn
-target 11
-source 11
-encoding Cp1252
[INFO] Compiling 615 source files to C:\Users\user\Documents\...\bm\target\classes


Re: Old ERP system on Java 11 classpath only [message #1804985 is a reply to message #1804980] Thu, 04 April 2019 09:29 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 825
Registered: July 2009
Senior Member
I've also posted this on StackOverflow and the first answer is interesting.
https://stackoverflow.com/questions/55489874/eclipse-java-11-classpath-only-not-working-compared-to-maven
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928
https://bugs.openjdk.java.net/browse/JDK-8215739

The classes indeed are also present in xml-apis-1.4.01.jar. If this is the case, the error message is incorrect (or at least inaccurate) because it finds too many. I was able to remove the DataFactory issue in this way, but w3c Document not. Continuing...
Re: Old ERP system on Java 11 classpath only [message #1804986 is a reply to message #1804985] Thu, 04 April 2019 09:36 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Bug 536928 was exactly about reporting the real error instead of "cannot be resolved". The fix was released for 4.11 (2019-03). If you see the wrong error message still in 2019-03, and if you are able to reduce the problem to a sharable project, please consider filing a new bug against JDT/Core. Please make sure you are using the original plugin org.eclipse.jdt.core, not a patched variant, e.g., from groovy-eclipse.
Re: Old ERP system on Java 11 classpath only [message #1804995 is a reply to message #1804986] Thu, 04 April 2019 12:15 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom EugelinkFriend
Messages: 825
Registered: July 2009
Senior Member
After I removed the xmp-apis jar, some of the errors went away. I moved the JRE to the bottom of the classpath, so I can find duplicates by jumping to the first jar that holds it, and then confirm that they are in the JRE as well. But I still have errors for w3c classes (e.g. Document) which do not seem to be duplicate, but Eclipse still think they are: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml
Re: Old ERP system on Java 11 classpath only [message #1804998 is a reply to message #1804995] Thu, 04 April 2019 12:35 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Quote:
But I still have errors for w3c classes (e.g. Document) which do not seem to be duplicate, but Eclipse still think they are: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml


Well, if JDT found the package org.w3c.dom in the unnamed module, this still is an indication that s.t. may be illegal in your build path. Please check if any other classes are found in or below that package. Also looking at the full maven dependencies (tree or flattened) might give a hint. Perhaps you still have xerces on the classpath? There may be more libraries shipping the same.

If you definitely find classes only in sub-package of org.w3c.dom, not in the package itself, this would indicate a bug in JDT, and a reproducing example is more than welcome.
Re: Old ERP system on Java 11 classpath only [message #1808164 is a reply to message #1804909] Tue, 18 June 2019 11:55 Go to previous message
Philip Woodman is currently offline Philip WoodmanFriend
Messages: 1
Registered: June 2019
Junior Member
You probably have some redundant xml api jars on the classpath and javac (incorrectly) doesn't complain because of JDK-8215739, but Eclipse already (correctly) does after bug 536928

At runtime, the JVM seems to ignore packages on the classpath that already appear in a named module, so javac's behavior is actually consistent with that.

To fix your problem: Try "Open Type" to find any copies of javax.xml.namespace.QName in jars on your classpath and exclude those dependencies in your pom.xml

erp software
erp systems

[Updated on: Wed, 10 July 2019 06:47]

Report message to a moderator

Previous Topic:Unreasonable matches for pattern search
Next Topic:How to write a conditional breakpoint expression that is always true, and executes arbitrary code?
Goto Forum:
  


Current Time: Mon Sep 09 18:20:33 GMT 2024

Powered by FUDForum. Page generated in 0.04191 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top