Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration to Java 17 #64

Open
marco-brandizi opened this issue Jun 17, 2022 · 3 comments
Open

Migration to Java 17 #64

marco-brandizi opened this issue Jun 17, 2022 · 3 comments
Assignees
Labels

Comments

@marco-brandizi
Copy link
Member

We've almost completed this, adding this issue keep track of the introduced changes, and keeping the issue opened until the migration is finalised.

Essentially, we can't merge this into master right now, since Neo4j isn't compatible with Java 17. For now, I've disabled a number of Neo4j-related Ondex components, just to work with the rest and ensure it can be built and run under J17.

Notes on this on comments below.

@marco-brandizi
Copy link
Member Author

marco-brandizi commented Jun 17, 2022

I should have fixed the JAXB problems with the damn Java modules. See my branch here. That one now builds and the binaries it produces seem to be running right.

How I did it, TLDR

I've replaced the Glassfish-based implementation of the XML binding libraries (used by JAXB) with a new implementation provided by the Jakarta project. The old one was a dead project and it was producing the issues with the Java modules.

How I did it, details

OXL files define node attribute types (called attribute names in Ondex) in a dynamic way,
ie, by setting properties like name and data type. The latter points to a Java class
(java.lang.String, Java.lang.Integer, etc) and it's then passed to the JAXB libraries, to map
XML to/from Java objects.

Now, a few of text .oxl files have attributes mapped to java.awt.geom.Point2D as data type
(no idea why, probably they used to save coordinates from the desktop GUI). When the old
JAXB-related lib named above tried to map from XML to Point2D objects, the problem with modules
arose.

Essentially, that was happening because such library is buggy and doesn't define its own module
correctly (as far as I could understand). Because it's also unmaintained, I did the upgrades
above. Actually, I wanted to do them a when I migrated from 8 to 11, but at the time I didn't
cause the Jakarta alternative has changed the javax.xml.bind namespace (they use jakarta.* now,
due to a dispute with Oracle). Now I've changed all the import statements in the .java files.

In detail. the done replacement can be seen in the root POM:

<!-- Since JDK 11, we need this as a separate lib -->
<dependency>
	<groupId>jakarta.xml.bind</groupId>
	<artifactId>jakarta.xml.bind-api</artifactId>
	<version>4.0.0</version>
</dependency>
<!--This is the implementation of jakarta.xml.bind-api -->
<dependency>
	<groupId>com.sun.xml.bind</groupId>
	<artifactId>jaxb-impl</artifactId>
	<version>4.0.0</version>
</dependency>						
<!-- TODO:remove we switched to Jakarta in JDK 17
<dependency>
	<groupId>javax.xml.bind</groupId>
	<artifactId>jaxb-api</artifactId>
	<version>2.3.1</version>
</dependency>
<dependency>
	<groupId>org.glassfish.jaxb</groupId>
	<artifactId>jaxb-runtime</artifactId>
	<version>2.3.2</version>
</dependency> -->

Other notes

  • As said above, Neo4j still doesn't work with Java 17, so we're waiting for their upgrades before finalising our J17 branch, by re-enabling Neo4j. According to this, that should come by October 2022.

  • Let's keep the branch started by JoJi for a while (I always archive them,
    anyway), it seems to be an example of what to do to make things compatible with modules. In
    general, I definitely want to avoid that, but, if we're really forced to it, acquired experience might be useful.

    • In the case at issue, in practice the module issues have been fixed by the Jakarta people.
  • In that branch, I've seen something related to JDOM, with a new JDOM dependency introduced somewhere. No idea why, I doubt it's actually needed.

  • In that branch, I've seen an attempt to introduce SLF4J as the logging system, migrating from
    Log4j 1. We shouldn't do that, in Ondex or Knetminer, for several reasons:
    Log4 2 is a successor of SLF4j and it's more advanced, so that's where we should possibly migrate the logging system, the gradual
    way to do it is by means of bridges, not by changing all the existing code. There is already
    a ticket for this, see Migrate to Log4j 2 using the 1/2 bridge. #63 (but not sure if and when we'll actually do it).

@marco-brandizi
Copy link
Member Author

@jojicunnunni, please verify that it builds and runs on your PC. After the build, run the GUI (available at ondex-knet-builder/installer/target/installer-6.0-SNAPSHOT-packaged-distro.zip) and the workflow tool (at ondex-knet-builder/ondex-mini/target/ondex-mini-6.0-SNAPSHOT-packaged-distro.zip.

@marco-brandizi
Copy link
Member Author

marco-brandizi commented Jun 20, 2022

More updates: since the Neo4j upgrade to J17 isn't expected before Oct 2022, it's sensible to do this sooner than later:

  • merge all the J17-required changes (essentially, the swap from Grlassfish JAXB to the Jakarta version) into master.
  • keep using the so-modified master with J11 until the next Neo4j arrives.

The above changes are compatible with J11 (except for minor details like the compiler level in the POM), embedding them now into master will avoid that we diverge too much from the J17 branch by the time we'll be ready for completing this migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants