Compatibility Issues - scottcarnold/pmdb GitHub Wiki

Putting together a full application front to end can at times be a challenge due to compatibility issues between Java modules, the Java application server, the Java version, the development environment and IDE being used, and the operating systems of the various environments. These challenges also provide some insight into why a project does not always utilize the latest versions of every artifact. As a point of interest, this page documents a few of those challenges encountered during the development of this project.

Eclipse - Long path name problems (Eclipse bug 559701)

Eclipse was chosen as the primary IDE for the project. The primary development computers are running Windows 7. The latest versions of Eclipse use some path names that exceed limits of the operating system. Until resolved, this limited the Eclipse version to Eclipse JEE 2019-12. This also limits Java support to no later than OpenJDK 13.

Payara JDK Support

Payara was chosen as the primary application server to run the application. The later versions of Payara currently further limit the Java version to no later than OpenJDK 11.

Payara stax2 Issue (Payara GitHub issue 4060)

An internal issue with Payara and stax2 cause issues when using jackson. This necessitated either finding a different application server, implementing a workaround, or downgrading Payara to an earlier version. For the time being, the Payara version was downgraded to 5.183. This further limited the Java version. Java version was set for Oracle JDK 8u191 (at the time, this was a convenience as 8u191 was already set up on all of the systems being used for the project).

TLS Connection Failure with Oracle JDK 8u191 (Payara GitHub issue 3284)

A separate issue relating to a TLS failure necessitated another minor Java version change from 8u191 to 8u181. At this point, most of the problems encountered are in one way or another linked to Payara, so moving to a different application server will be considered in the future. For now, the application is stable with Payara 5.183 and OracleJDK 8u181. (Update: I now run the Spring MVC version of PMDB on a WebLogic server, so issues related to Payara no longer apply.)

JPA Repositories for DynamoDB

The spring-data-dynamodb component of the project provides Spring JPA repository functionality for AWS DynamoDB. However, this handy integration between Spring and AWS has not been updated for the AWS SDK2. While I initially worked with the AWS SDK 2.13.18, in comparison to AWS SDK1 with spring-data-dynamodb, the quality of the Spring integration convinced me that the latter choice of using AWS SDK1 with spring-data-dynamodb is the better choice for the time being. This project is therefore using AWS SDK 1.11.784.

Travis CI JDK

A notable deficiency of this setup in combination with the use of Travis CI is that OracleJDK 8 cannot be used with Travis CI, and even if it could, it is unlikely the specific version 8u181 could be selected. For now, Travis CI is setup to build the war with OpenJDK 8. Presumably, this should work fine on any application server, at least until it doesn't (the issues on this page serving as an example of various conflicts one can encounter).

Acceptable Limits

It is a good idea to have a plan as to what range of technology versions are acceptable for a project. Using technologies that are too old can have serious impacts due to obsolescence, lack of support, and increasing difficulty of upgrading over time. Using brand new technologies comes with it's own challenges related to integration and immaturity.

For this project, and I think as a general rule, it is good to err on the side of the new. For this project, I initially started with Java 14, the newest at the time. But there were no features or needs beyond Java 8 for this project (Java 8 being the lower limit for streams and lambda expression), and ultimately I settled on Java 8 due to the various integration challenges noted above. I will likely upgrade it in the future, but first decisions need to be made on how the various challenges should be addressed, and what level of effort is acceptable for them. Sometimes, simply waiting for vendors to fix certain bugs is the most efficient solution to upgrade challenges. Other times, workarounds may need to be implemented or entirely different products selected.