3

I am preparing the migration to Java 11 of the entire project portfolio of my team. All applications are based upon a framework that has been developed in-house over the years, with some parts being over 12 years old.

I have followed the recommendations in this post (and this web page from Oracle – it did not help at all), using versions-maven-plugin-version to update all dependencies to their latest GA versions.

There's only one JDK installed on the machine (11.0.4) and Eclipse is configured for source level 1.8, target 11 and release 11. I am not yet considering the problem of transitioning from 1.8 to 11 in runtime environments: for now, I just want to sort out compilation issues.

I currently have two issues:

  1. "error: package com.sun.rowset is not visible. (package com.sun.rowset is declared in module java.sql.rowset, which does not export it)"
  2. "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml"

Problem 1

NOTE: This problem is solved, see EDIT section at the bottom of this post.

The first problem stems from the fact that someone in the past had the brilliant idea to use class com.sun.rowset.CachedRowSetImpl which is not API (and which probably wasn't when they started using it).

What I have done, using other questions and the given answers as a basis, was to configure Maven with this:

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.release>11</maven.compiler.release>

I'm probably poking in the dark here, but that configuration had no effect, whether in Eclipse or on the command line. I'll add tests around that incorrect usage so that I can replace the class with another one that is actually API.

Problem 2

The second problem is more crucial to me. We use many packages, mainly for XML processing, that generate that error. Here are some of these packages:

org.w3c.dom.Attr
org.w3c.dom.Document
org.w3c.dom.Element
org.w3c.dom.Node
org.w3c.dom.NodeList
org.xml.sax.SAXException
javax.xml.parsers.DocumentBuilder
javax.xml.parsers.DocumentBuilderFactory
javax.xml.parsers.ParserConfigurationException
javax.xml.transform.OutputKeys
javax.xml.transform.Result
javax.xml.transform.Source
javax.xml.transform.Transformer
javax.xml.transform.TransformerException
javax.xml.transform.TransformerFactory
javax.xml.transform.dom.DOMSource
javax.xml.transform.stream.StreamResult
javax.xml.transform.stream.StreamSource
javax.xml.validation.Schema
javax.xml.validation.SchemaFactory
javax.xml.validation.Validator

One solution is to remove the artifacts that provide the matching packages from the Maven dependencies. Unfortunately, doing so create errors elsewhere, in that the removal of the dependencies makes some other packages unavailable. For instance, if I leave xml-apis among the dependencies, I have the "package x is accessible from more than one module" error. If I exclude it from all dependencies that pull it as a transitive dependency, I get a "xxx cannot be resolved to a type" error.

Dependency exclusion could be a solution but the portfolio resting on that framework is extensive and the exclusion would mean hunting down potentially hundreds of locations where incriminated dependencies could exist as transitive dependencies.

Question

My question is about how to proceed to solve problem #2.

For the time being, I have resorted to specifying source and target levels of 1.8, which isn't a viable option but it's the only option I've found so far that allows the compilation to succeed on JDK 11.

[EDIT] Problem 1 is solved thanks to this answer to another question.

AbVog
  • 1,435
  • 22
  • 35
  • Not 100% sure but it looks like a name conflict. At least two modules are providing say `javax.xml.parsers.DocumentBuilder` so it's not clear which one should be used. Here is something about it: https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html – Miku Aug 09 '19 at 08:31
  • Are you trying to organise your projects as Java modules? Or are you just switching Java versions? – J Fabian Meier Aug 09 '19 at 08:44
  • @Miku: what I phrased as "One solution is to remove the artifacts that provide the matching packages from the Maven dependencies." is exactly what the link you provided is about; I was also speaking of dependency exclusion. – AbVog Aug 12 '19 at 12:21
  • @jf-meier At this point, I'm just switching Java versions. Organizing the portfolio (or just that thin framework) as modules is for later. – AbVog Aug 12 '19 at 12:21
  • Hi! Did you manage to solve this by any chance? – Mostafa Zeinali Jul 28 '20 at 12:57
  • Not solved yet unfortunately. At this moment, I have suspended the migration because of more pressing matters in the company but I'll have to deal with the issue before year's end. – AbVog Jul 28 '20 at 16:42

1 Answers1

1

I hit my head on the problem 2 today.

In my case, it was enough to avoid importing

<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>

This artifact/jar includes the same (XML related) classes, which clash with the Java 11 lib. This is because we get the error "package x is accessible from more than one module".

In my case I did not do had to do anything more.

In your case,("xxx cannot be resolved to a type") I'd guess you need to ensure to import the module java.xml , when compiling.

This page suggests

This is possible by creating a file .mvn/jvm.config in the project's folder and putting the options in there. Here's a simple example:

--add-modules java.xml.bind
--add-opens java.base/java.lang=ALL-UNNAMED
--illegal-access=deny

--add-modules is the javac option to include modules in Java.

OGrandeDiEnne
  • 872
  • 7
  • 14
  • Thanks! I added an exclusion to my dependency group `org.docx4j` artifact `docx4j-export-fo` – joninx May 14 '21 at 11:25