Hi, As an experiment, I tried to backport part of CASSANDRA-9608 and CASSANDRA-14607 that are needed to run Cassandra 3.11 on Java 11. For the most part it was quite straightforward; the results are available at https://github.com/apache/cassandra/compare/cassandra-3.11...kornelpal:cassandra-3.11-java11
To minimize the scope and risk, I only backported code changes needed to run on Java 11, not changes needed to compile on Java 11. I also did not update library versions and did not backport the script and config changes. Those might be higher risk, and Cassandra administrators should be able to manually replace library binaries and apply config changes from 4.0 for Java 11 support. Both "ant test" and "ant long-test" had the same results with and without the changes on Java 8 that is very promising. AtomicBTreePartition was somewhat challenging; CASSANDRA-14607 replaced all the relevant changes made in CASSANDRA-9608 and CASSANDRA-15367 has a 4.0 specific version. I changed CommitLogReader - that is not present in 4.0 - to use FileUtils.createTempFile for consistency. I did not apply the UFSecurityTest changes as those were failing, probably because are dependent on a newer library version. I believe that these changes could enable Cassandra 3.11 to run on modern Java versions with reasonable effort and with no code changes, while also would bring the shared code base closer to 4.0 that would reduce the risk and complexity of future code changes on the 3.11 branch. Could you please comment on whether this or a similar change could be accepted to the mainline Cassandra 3.11 source code. Thank you, Kornel --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
