Update build to current Java version

[fixtradingcommunity]

Update build to current Java version

[donmendelson]

I have discovered in Project Conga that many tools such as Maven plug-ins still do not support Java modules that were introduced in Java 9. Since XML was moved out of the Java base library into a separate module, it is certain that we would need to use modules even if we do not create our own for Orchestra.

[donmendelson]

I propose to defer this until after the release of RC4.

[donmendelson]

Issue: JAXB utility xjc has been removed from the JDK 11 distribution. A newer or different Maven plugin is needed that references it as an external dependency.

[donmendelson]

Deferring until Maven plug-ins mature and libraries take account of module system.

[brainopener]

Master (dbb1a4d) builds and tests pass on OpenJDK 11.0.6 with these dependencies added to the root pom.xml:

        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
        </dependency>
        <dependency>
            <groupId>com.sun.xml.bind</groupId>
            <artifactId>jaxb-core</artifactId>
            <version>2.3.0.1</version>
        </dependency>
        <dependency>
            <groupId>com.sun.xml.bind</groupId>
            <artifactId>jaxb-impl</artifactId>
            <version>2.3.2</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>1.1.1</version>
        </dependency>
        <dependency>
            <groupId>javax.annotation</groupId>
            <artifactId>javax.annotation-api</artifactId>
            <version>1.3.2</version>
        </dependency>

[donmendelson]

Thanks @brainopener. I'm thinking that I'll create the next release build keeping Java 8 minimum. Then update for the next build. (We expect to publish Orchestra version 1.0 Draft Standard very soon.)

[donmendelson]

@brainopener I expect the Sun code is frozen in amber. Considering switching to the org.glassfish implementation of JAXB going forward, which should be maintained. Do you have any experience with this?

[brainopener]

@donmendelson
I have no experience with it.

I can confirm that Master (2953a2a) builds and tests pass on AdoptOpenJDK 11.0.6+10 with these dependencies added to the root pom.xml. In this set, notice the org.glassfish.jaxb dependency.

        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>2.3.2</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>1.1.1</version>
        </dependency>
        <dependency>
            <groupId>javax.annotation</groupId>
            <artifactId>javax.annotation-api</artifactId>
            <version>1.3.2</version>
        </dependency>

[donmendelson]

Hmm. I'm running into the problem described here jakartaee/jaxb-api#78. I don't understand how they closed that issue.

[brainopener]

@donmendelson

I tried this in a sandbox environment. Here's the setup:

• AWS spot instance in Oregon region
• Ubuntu 18.04 OS
• Forked fix-orchestra and made changes to pom.xml.

Here are the commands that I ran on it:

sudo apt update
sudo apt-get install graphviz git openjdk-11-jdk maven -y
git clone https://github.com/brainopener/fix-orchestra.git
cd fix-orchestra
mvn package 

What I see is that Maven builds it and runs the tests successfully.

The shell log is here.
A video of the process is here.

[donmendelson]

@brainopener thanks for your help. I'm making progress on building the Maven repository module as a Java module for Java 11+ and having an application use it. The goal is to build with just modules rather than classpath so we can use jlink and jpackager for images, installers, etc.

FYI I am splitting off the validator and compressor utilities into a separate module to reduce dependencies of just repository.

[donmendelson]

It's apparent that this code can be compiled in Java 11 and 14, but many libraries and tools are not ready for prime time. I was hoping to build an application with runtime image and installer using jpackager in Java 14. This requires Java modules but many libraries are not yet modular. Jakarta implementations of java.xml.bind and related dependencies are now being built with module declarations, but are in beta or milestone versions. I'll keep this work in a fork, but will wait for dependencies and tools to settle down.

[donmendelson]

Surveys show that the majority of firms are still using Java 8. We don't want to prevent them from using Orchestra code. Meanwhile, Java 9 and later moved XML out of the main Java library and added a module system. The ideal is to work for Java 8 and later versions that require module declarations. Investigating whether a multi-release jar might be a solution.