Monthly Archives: September 2021

Sakai Development moving to Java 11

Since Sakai has moved to Java 11 for the Sakai 22 and later releases, we will need to update our developer environments.  I also made the following changes.

  • Use the org.mariadb database connector and Hibernate dialect (even if I am using MySQL 5.7).  The connector is free and automatically deployed by Sakai so there is no extra fuss downloading the com.mysql connector and hand-installing it in Tomcat.
  • Upgrade Maven to 3.8.1 or later
  • On my fresh-install Linux environments I am switching to MariaDB as my dev database server.  If I have an existing MySQL (i.e. MAMP on Mac or Aurora on AWS) I will just keep using it but switch to the MariaDB connector.

I have setup and tested four different environments in the post-JDK11 environment:

  • Matt Jones’ docker-build solution.  This is very cool – especially for Windows.  Matt mounts folders from your computer’s file system into his (build/database/sakai) docker containers so you can edit files outside of the docker containers and then build / run all inside docker containers with a zero footprint install on your computer other than docker itself.  Also your database persists even when you have no docker containers running.  The container and mounted files slows this down a bit – but if you have a super fast Windows or modern MacBook box with a lot of memory and SSD, it is plenty quick.
  • My MacBook running natively installed Java, Tomcat, and MAMP using my sakai-scripts code.  For Mac development it is faster than Matt’s docker solution especially for my circa-2013 MacBooks that I refuse to upgrade.
  • A simple self contained Ubuntu image running under docker using my sakai-scripts code.  I use this to make sure I can quickly test my scripts or Sakai’s build under ubuntu without spinning up an EC2 node or DigitalOcean Box.  This is different from Matt’s docker approach because everything (including the MariaDB server and data) is in the docker – it is nice for quick tests because it is a zero-install other than docker on your main computer.
  • An ubuntu server running on Digital Ocean / EC2 using my sakai-scripts code like

If you want to figure out things like shell settings or other configuration to adapt your own setup, you can take a look at some of the files in my sakai-scripts repo.  If you used these scripts before, there was a complex step of getting all the environment variables set in your profile (mac or linux).  Now each script sets its environment variable and does its thing – much better and easier to fix / upgrade when things change a little.

You can examine these scripts and extract bits to use in your environment.

  • Start with the it contains the overall outline of manual and automated steps.  This shows how to setup (a) a MackBook, (b) ubuntu in a stand-alone docker, and (c) ubuntu on a stand-alone server.
  • Take a look at to see what prerequisites are needed on ubuntu.  Because I use sdman the installs are much simpler – thanks Matt and Earl for teaching us about this.  Using sdman also allows you to switch back to JDK-8 if you need to.  It is the logical equivalent of Python virtual environments.
  • Take a look at to see things like needed environment variables to make maven work.  Without these maven will run out of memory whilst building.
  • Take a look at to see the relatively complex set of environment variables needed to set up Java to run Sakai.  These variables are adapted from the Matt / Earle recommendations.  Matt designed these to be tweak able and there are some examples of things like setting up a debugger if you want that.

I hope you find this helpful.  I would also like to explore moving these scripts and Matt’s docker stuff into the core repository in a “dev” folder.  It is kind of silly to have these in hard-to-find locations in contrib and my repo.




Sakai 22 moving to Java 11

(This was originally from Earle Neitzel on the Sakai dev-list)

The time has finally come for Sakai to adopt and move to Java 11.

A big part of this decision is inline with the libraries that Sakai uses, once all the significant libraries have transitioned to running in a newer JDK Sakai itself becomes eligible for the same. Sakai software (like most software) is like lego’s and the blocks all need to have the same shape and size in order to work together. So once all the fundamental blocks (like spring, hibernate, elasticsearch, ignite, server side UI frameworks) support a newer JDK, then Sakai can look at adopting that JDK.

JDK 5 Dec 14 2006 (approx)
JDK 6 Feb 20 2012 SAK-20908
JDK 7 Oct 27 2014 SAK-28016
JDK 8 March 29, 2015 SAK-25903
JDK 11 Sept 24 2021 SAK-33595

In the past, it was customary to limit newer language syntax in order to preserve compatibility when merging changes to previous versions. I propose we do this for at least 1 Sakai version which would mean once the 23 branch is cut then we could allow newer syntax. I would also revisit this at that time to see if it should be extended to 2 Sakai versions. (Most IDE’s will allow you to set the syntax level to help prevent you from using newer syntax)

Jakarta package name
So in conjunction upgrading to jdk 11, jdk 9+ removed much of the javax namespace (aka JEE) it means that many of these packages are now separate libs which need to be included. On top of that Oracle has given the Java EE to Eclipse with the restriction that they cannot use the word “Java” hence the need to rename the packages to Jakarta. Given many of our libs are still using the javax package names we can use jakarta libs that keep the package name space (like activation and validation) but newer jakarta packages are changing the package names as well this last part is causing some issues as some of the libs are still on versions using the javax package name. I propose that until Sakai is on newer libs that support the newer package names that we stay on the javax namespace. This means that i reverted a recent contribution SAK-45950 by David Horrowitz to stay on the javax package name, I apologize but believe it’s the right thing to do at this time.

Building Sakai with JDK 11
The source can only be built using JDK 11 moving forward. So you will need to download and use a respective JDK. I propose that Sakai standardize on the OpenJDK project as all other projects use that project as a base and should ensure our compatibility with other JDK flavors.

This project makes that task simple.

Running Sakai with JDK 11
Here will list the options we will need to use to run Sakai in JDK 11.
In your setenv.(sh|bat) you will need to add the following lines to JAVA_OPTS or CATALINA_OPTS:
–add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
–add-exports=java.base/ \
– \
–add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
–add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
–add-opens \

Next you will want to select a Garbage Collector to use this may depend on the JDK that your using. See the following page for some info