Does Cassandra support Java 10?

Question

We're planning on migrating our environment from Java 8 to OpenJDK 10. Doing this on my local machine, I've found that Cassandra will no longer start for me, giving the following error :

I can't find any solid information online that says it is definitely not supported.

This post from 4 months ago suggests that they do not support Java 10, but doesn't say it is confirmed, and is more inferred. There is also a comment on it from another user saying they have managed to get it running on Java 11.

The final comment on this ticket on datastax says "We've updated our CI matrix to include Java 10 and everything works except for the aforementioned OSGi testing issues." I'm not sure what to take away from that, but it seems to imply that it is working with Java 10 now, as the ticket is marked as resolved.

This ticket, they discuss support for Java 11. There are a few comments discussing the need to even support Java 10, but they don't really give a definitive answer on whether they will or not.

Finally this blog discusses a way to get Java 11 working with cassandra. However I notice this is using Cassandra 4.0. Has this officially been released? I notice on their website they say the release date is tbd and says the current stable release is 3.11.3, and there is no mention of it on their compatibility page.

I currently installed Cassandra on windows via Datastax, but I have also tried cloning the current git repository and running it from there, but I get the same error message (although on their github they do seem to say it has only been tested with Java 8).

Do they simply not support 10 then? Also if anyone knows if they plan to release 4.0 soon, and if that will definitely support 11 (and I assume 10 ?), that would be a massive help.

Answer 1

Cassandra 4.0 has explicit support for both Java 8 and Java 11. In fact, they even split-up the configuration files as such:

$ pwd
/Users/aaron/local/apache-cassandra-4.0-SNAPSHOT/conf
$ ls -a jvm*
jvm-clients.options jvm11-clients.options   jvm8-clients.options
jvm-server.options  jvm11-server.options    jvm8-server.options

The reason for support of these specific versions is two-fold. First of all, Java 8 has been the de-facto standard for Cassandra for a few years now. Users expect that it will still work on Java 8 in the future.

Given the new 6 month release cycle of Java, Java 9 and Java 10 will no longer be "current" when Apache Cassandra 4.0 comes out. Plus, the tests which run during the build have shown to be picky about which version of Java they work with. Therefore, the decision was made to go support Java 8 and 11 for 4.0, as work on Java 9 and 10 seemed to be lower-priority.

That's not to say that Cassandra 4.0 won't run on Java 9 or 10. In fact, CASSANDRA-9608 even has a patch submitted which should cover it. But the fact remains that Java 8 is included due to its longstanding use in the Cassandra user base. Java 11 will be the current JDK/JRE at the time 4.0 releases. If you want to be sure that your cluster will run well, I'd pick one of those two.

But until 4.0, the most recent patch of Java 8 is really the only option.

Answer 2

Released versions of Cassandra support only Java 8 - support for higher versions will be in the Cassandra 4.0 that isn't released yet. You can track progress in the CASSANDRA-9608

Answer 3

With Cassandra 3.11.4 we have been able to execute the Cassandra engine with Java 11, but there has been some gotchas:

• If for any reason you are still using CMS for garbage collection, it would be the time to move to G1; this is set up in the jvm.options file.
• Also in jvm.options, you will need to disable the ThreadPriorityPolicy as it was deprecated with Java 9
• With the unified logging of gc activity, introduced with Java 9, you will need to remove gc specific parameters in jvm.options. Some of those parameters are:
  • -Xloggc
  • -XX:+PrintGCDetails
  • -XX:+PrintGCDateStamps
  • -XX:+PrintHeapAtGC
  • -XX:+PrintTenuringDistribution
  • -XX:+PrintGCApplicationStoppedTime
  • -XX:+PrintPromotionFailure

• nodetool still requires Java 8 to be able to execute.

  • We have both JVM installed, and used alternatives to set Java 11 as the default. This is also the value of the JAVA_HOME variable
  • We have a new variable called JAVA8_HOME that points to that version
  • We updated the nodetool script (in our case it was in /usr/bin/nodetool) to use JAVA8_HOME when setting the JAVA variable

• For a cluster that was using offheap_buffers for memtable_allocation_type (it is defined in cassandra.yaml), we had to change it to use offheap_objects