Enabling Java 9 modularity

[svanteschubert]

Someone who is already using Java 9 modularity might assist us in adding this concept to the ODF Toolkit JARs.

See also: https://www.oracle.com/corporate/features/understanding-java-9-modules.html https://www.baeldung.com/java-9-modularity

[miasma]

At least for my simple use case, adding the following src/main/java/module-info.java seemed to work:

module org.odftoolkit.odfdom {
  requires java.desktop;
  requires java.logging;
  requires java.xml;
  requires java.rdfa;
  requires xercesImpl;
  requires org.json;
  requires org.slf4j;
  requires org.apache.jena.core;
  requires org.apache.commons.compress;
  requires org.apache.commons.lang3;
  requires commons.validator;
  requires serializer;

  exports org.odftoolkit.odfdom;
// and other exported packages
}

I had to disable the tests java/org/odftoolkit/odfdom/pkg/GRDDLTest.java and java/org/odftoolkit/odfdom/pkg/RDFMetadataTest.java since I couldn't figure out how to make the jena-core:tests visible (related: https://github.com/eclipse/jetty.project/issues/3080). While this is nice to have, it still won't work properly until [xercesImpl-2.12.0.jar, serializer-2.7.2.jar, java-rdfa-1.0.0-BETA1.jar, commons-validator-1.6.jar] have also migrated.

[svanteschubert]

Hello Miasma,

Thank you for your contribution and insights. So all our dependent project JARS you mentioned need to be transitioned to JDK 9 prior as well.

1. xercesImpl-2.12.0.jar & serializer-2.7.2.jar mentioned to be working
2. commons-validator-1.6.jar release notes for 1.7 mention a breaking change due to JDK 9 local usage - indicated they have JDK9 on the radar - I have not tested, but optimistic
3. No insight on Jena, likely we have to test the latest version and/or build locally with JDK 9 enabled and contribute it back
4. java-rdfa-1.0.0-BETA1.jar is from Damian Steer, who I once met. I just have written him about JDK 9 modules and the repo of https://repo1.maven.org/maven2/net/rootdev/java-rdfa/1.0.0-BETA1/ as the former repo seems still very old: https://github.com/shellac/java-rdfa (Update: https://github.com/iteggmbh/java-rdfa is the current repo)

Any further information & help is most welcome.

Best regards, Svante

[svanteschubert]

Damian answered the current RDFa GitHub repository, which is also creating the recent Maven artefact is: https://github.com/iteggmbh/java-rdfa

[wetneb]

I am new to Java 9 modularity, but I thought the following workaround could be of interest to others: If your project depends on odftoolkit and your IDE reports compilation errors due to Java modularity, you might want to exclude the xml-apis dependency from odftoolkit, which duplicates native libraries already provided by another module, as follows (for Maven):

     <dependency>
       <groupId>org.odftoolkit</groupId>
       <artifactId>odfdom-java</artifactId>
       <version>0.9.0-RC1</version>
      <exclusions>
        <exclusion>
          <groupId>xml-apis</groupId>
          <artifactId>xml-apis</artifactId>
        </exclusion>
      </exclusions>
     </dependency>

[svanteschubert]

Is anyone able to provide a pull request that enables Java 9 modularity? Or at least provide a pull request where we can iterate upon and list the remaining problems?

[wetneb]

I would like to understand what is the need you are looking into fulfilling here. I think Java 9 modularity can be "enabled" by adding some basic module metadata in module-info.java as mentioned by @miasma, but I do not know if such a setup would actually solve the issue you have in mind?

In other words, I would like to understand in which scenarios it is important to users that this Java 9 modularity is used.

[svanteschubert]

@wetneb Personally, I have no special use case in mind. I am happy to solve it with a patch based on the draft in the beginning. :-) When I did a quick test in VSCode to add the initially mentioned src/main/java/module-info.java I got a lot of errors, that some of the above mentioned would be not modules. That lead to my previous request for feedback/help.

[xzel23]

Hi @svanteschubert, I'll have a look at this later.

[xzel23]

OK... there are some issues here:

• Apache Jena seems to use automatic module names. This is better than nothing, but still not good (automatic module namens are not supported by jlink). But that's a secondary issue and has to be fixed by the Jena project.
• A duplicated package issue with Apache Xerces. This is serious. I'll open a separate issue for this.

The second point means that we probably should do the next release rather sooner than later, because properly fixing that one will bring breaking changes for users.

[svanteschubert]

AFAIR, Xerces is using an Ant script and bundling the JAR in the repository and the deliverables. One of their dependencies is hard to get as source code. I once suggested a Maven build system, but they ignored it, see

1. https://github.com/svanteschubert/xerces-j/tree/maven-prototype
2. https://github.com/svanteschubert/xerces-j/tree/maven-prototype_JDK8-PsychoPath1.2.1

and of course bringing the tests together with the sources, which would fail than... strange...

3. https://github.com/svanteschubert/xerces-j/tree/smoke-testing

The Jena group seems to be more open-minded, but there was some blocker that I can not remember...

[xzel23]

The point is: ODF Toolkit should not rely on a particular implementation such as Xerces. Projects might need a specific implementation for their software. If ODF Toolkit includes Xerces as a dependency, that is asking for trouble: you will end up having to different implementations in your code base, each incompatible with the other one.

So what is the solution? To only rely on the interfaces defined in JAXP. But this cannot be done without a major rewrite of all of the DOM classes, because you cannot extend the Element, Attribute and Component classes. Instead, your classes should delegate to the XML-interfaces. But in ODF Toolkit, the model classes all are XML nodes themselves. I have tried to make the current code independent from the implementation in a compatible way, but this requires so many changes that the amount is not much less than creating a "proper" solution.

The funny thing is that the JDK already includes Xerces (or rather a Xerces based implementation) itself as the default implementation. But the implementing classes are not exposed to avoid people to rely on implementation details. But to be fair, I remember when the XML hype started, everyone was doing it as there were no best practices yet.

[svanteschubert]

@xzel23 You are right, I remember that at that time multiple XML parsers were being used, but with even more errors. By choosing a fixed implementation with a certain version, the support mails at that time were easier to answer, and the overall implementation was stable. I wonder how much the obfuscation of an XML implementation would take?

[xzel23]

@svanteschubert it's not an obfuscation, but all the model classes should not derive from the xml Node class. It depends on how much time I can spend on this - but I think I can create a PR for this. Maybe two weeks, maybe more.

But I think we should first get out a version with the current changes. I have found at least one subtle bug (unrelated to this issue), and the formatting code needs to be fixed. Maybe if that's done, a new release can be prepared and then I'd make a PR for the primitive types and another for this one. We should do it early in the release cycle so that there's enough time to find all potential problems.

[svanteschubert]

@xzel23 Perhaps we should start with a small prototype for show-and-tell and as a test balloon? Might this change become a problem for existing user's and can those problems be addressed in an automated way? (I am pro change, and I think what you suggest is a valid and good, but there are reasons ppl still use JDK 8 and Apache Maven, not switching to JDK 21 now)..Let's test and see!

PS: I will start looking closer at your other issues/PRs early next week!

[xzel23]

We are talking about the class hierarchy here. The base class of all DOM nodes has to be changed, this will not be possible with a small prototype. But I think we should really fix the current issues first and then dive into this one. I have integrated Sonar, and there a lots of issues that seem to be actual bugs that need to be addressed first.