Server error during RefApp 2.13.0 implementation

This implementation of OpenMRS is for a mid-sized hospital and the requirement is to store and process about 30K EMRs. I have been trying to install Reference Application 2.13.0-SNAPSHOT on top of OpenMRS core 2.6.0 with the below system specs:

OS: Ubuntu 22.04.1 LTS

Java: OpenJDK 1.8

Webserver(Tomcat): Version 9.0.58

MySQL: Version 8.0.30

The installation of core went well but after installing the RefApp modules the below error was seen at the browser-

java.lang.UnsupportedClassVersionError: org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Please recommend the right way forward. Thank you!

Further comments:

So, it looks like-

  1. OpenMRS core 2.6.0 is both compiling and running perfectly well on Java 8
  2. Reference Application 2.13.0-SNAPSHOT is compiling without any issues on Java 8 but there seems to be a problem when you run it on Java 8

Reference Application 2.13.0-SNAPSHOT is running here https://qa-refapp.openmrs.org/ on Java 8

How are are you running it?

@dkayiwa The omod files of Refapp were built on a local machine using Java 8 and deployed to a cloud based web server also using the same Java 8 environment. The rest of the specs of the web server have been detailed at the top of this thread here-

Update:

The error does sound like a version mismatch. I have now pointed the deployment web server to use Java 11 run time & this has solved the problem. So, the refapp has been built using Java 8 but needs Java 11 to run.

Not quite sure what really solved the problem but the problem no more exists!

Thanks @dkayiwa

Java 8 is the most tested, and works very well. In your case, you had some components that require Java 11 and that is why i was wondering how you are running it to find out what exactly is it in your pieces that requires Java 11.

I did take another look at the whole deployment process and failed to find anything unusual. I have kept the whole process very simple and straight forward.

→ Built the Refapp using the latest version of the git repo (as on the 16th of october 2022) on a local machine with Java 8 (Maven was also using Java 8)

→ Only the command line was used for building and no IDE was used in this case

→ The deployment environment setting is also very simple with only the bare minimum needed to run the Refapp and detailed at the begining of the thread. The web server and the environment is new and only this build of the Refapp has been deployed on it (nothing else!)

Would be happy to share any other specific details if needed, to get to the root of the issue, if it helps other implementations.

As of now, thinking of using Java 11 JRE for running and hoping that it is fine to do so.

Thanks again!

So this particular issue seems to be due to Ubuntu itself. More specifically, Tomcat 9 is still built (by the Tomcat team) on Java 8, so it supports Java 8. However, if you install Tomcat 9 via the default Ubuntu mirrors, you get the version of Tomcat from Universe. This includes, as a transitive dependence, the Eclipse JDT, which is used to compile JSPs into Java class files. The version of the Eclipse JDT that is bundled in the Ubuntu Universe repo for Jammy requires Java 11+ (see the changelog).

Ultimately, this is a bug in Ubuntu and appears to have already been reported, though it doesn’t look like anything has been done about it.

1 Like

@ibacher That was very insightful indeed!

I see two options ahead for this implementation:

  1. Re-install the webserver from the original sources and make Java 8 as the JRE
  2. Continue to use Java 11 as the JRE on the deployment server

Option 1 would entail redoing the whole implementation process. So, I am thinking of using Java 11 JRE in the testing phase and continue using it if there are no issues (Java 11 should definetly support backporting, would be eager to know if there are contradictory views on this)

Thank you!

As long as you’re using platform 2.4 and above, things should work on Java 11. As @dkayiwa indicated, we haven’t done as extensive testing of the various modules on Java 11, but if things seem to be working, that does seem like the best direction to go in.

I think there is enough clarity on the matter now, to keep moving things forward. I will report back if I do face any specific issues with Java 11 Runtime.

Thanks a lot for all the very useful inputs @ibacher @dkayiwa