[jira] [Commented] (CASSANDRA-9608) Support Java 9

["Robert Stupp (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510196#comment-16510196 ] 

Robert Stupp commented on CASSANDRA-9608:
-----------------------------------------

Finally found some time to work on this patch and clean it up. It supports running C* and included tools against both Java 8 and Java 11.

Building:
 * Building C* requires either Java 8 or Java 8+11. There are two new source folders: {{src/java8}} and {{src/java11}} for version dependent Java sources. Both folders just contain a single class at the moment. {{src/java}} + {{src/java8}} are build with the Java 8 SDK - {{src/java11}} is built with the Java 11 SDK. To build C*, set {{JAVA_HOME}} to the location of the Java 11 SDK home and set the env var {{JAVA8_HOME}} to the Java 8 SDK home (OpenJDK is fine for both); make sure that {{PATH}} env var points to the Java 11 {{java}} + {{javac}}. The resulting cassandra.jar is a multi-release jar - i.e. it contains the Java 8 class files as usual plus the Java 11 specific class files (which "overload" the Java 8 ones) in {{META-INF/versions/11}}. Supplying JDKs for both Java 8 and 11 is necessary, as the Java 11 {{javac}}, even if invoked with {{--release 8}}, fails to compile the C* sources (use of "forbidden" classes like {{sun.misc.Unsafe}}) - so the build just uses two JDKs.
 * Release builds - i.e. builds that depend on the {{artifacts}} ant target - require two JDKs. Other, non-release targets, like {{jar}} work with Java 8 only or Java 8 + 11. C* built with only Java 8 does *not* work on Java 11 - startup will fail.
 * ant version 1.9.7 or newer (1.10 is fine as well) is required
 * Unit tests and dtests run against both 8 + 11
 * ecj, as used in the {{eclipse-warnings}} ant target, doesn't work with Java 11 (JPMS), so that target just doesn't run with Java 11.

Changes:
 * Java version requirements: either Java 8 (update 151 or newer) or Java 11. Requirement checks are moved to {{cassandra.in.sh}}. JVM specific options are now split into  {{jvm.options}}, {{jvm8.options}} and {{jvm11.options}}.
 * There's a new {{clients.in.sh}} file, which is sourced from tools scripts (nodetool, sstable*, etc). It does a Java version requirement check as well and loads the JVM specific options from the new files {{jvm-clients.options}}, {{jvm8-clients.options}} and {{jvm11-clients.options}}.
 * IntellJ IDEA {{ant generate-idea-files}} updates.
 * Library updates:
 ** asm: 6.1.1
 ** ecj: 4.6.1
 ** jamm: 0.3.2
 ** ohc: 0.5.1
 ** chronicle (in a separate, but necessary commit)
 *** chronicle-*: as per chronicle-bom 1.16.23, except:
 *** chronicle-core: 1.16.3-SNAPSHOT - contains fixes for Java 11, should be updated to a release-version before 4.0 is released
 * Hack to prevent the ugly {{WARNING: An illegal reflective access operation has occurred}} messages on startup of C* and its tools. The hack basically "tells" {{IllegalAccessLogger}} that the first warning has already been logged although nothing has been logged.
 * Incorporated [~jasobrown]'s idea to make the park-nanos configurable. By using a multi-release jar, it was possible to keep the {{monitorEnter}}/{{monitorExit}} implementation for Java 8 - the spin-lock approach is implemented for Java 11.
 * Logs of changes to only use {{FileUtils.createTempFile}} methods. Background: Java 11's temporary files contain _unsigned_ 64 bit numbers - this fails for a bunch of tests, especially those that generate commit log files. Took the freedom and centralized all temp-file/dir creations.
 * Various changes that were already present in the previous patch version - including updates regarding {{Cleaner}} 
 * Windows: I've changed a few Windows files but not all as I have no access to a Windows machine

If this patch makes it in mostly as it is now, the way for features that require Java 11 is:
 * Abstract the feature in the "common" source folder ({{src/java}}).
 * Implement the Java version dependent feature in {{src/java11}} for Java 11 and in {{src/java8}} for Java 8
 * An example is {{AtomicBTreePartition}} - it extends {{AtomicBTreePartitionBase}}, which has different implementations for Java 8 and 11. {{AtomicBTreePartitionBase}} "sneaked into" the class hierarchy between {{AtomicBTreePartition}} and {{AbstractBTreePartition}}.

Tests:
 * Verified that the patch builds and runs with OpenJDK 8u172, OpenJDK 11-ea+17 and a nightly build from last night (hg version 075e9982b409) - smoke test: build + start
 * Unit tests look good on internal CI

 

> Support Java 9
> --------------
>
>                 Key: CASSANDRA-9608
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
>             Project: Cassandra
>          Issue Type: Task
>            Reporter: Robert Stupp
>            Assignee: Robert Stupp
>            Priority: Minor
>         Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved. It can be easily solved using this patch:
> {code}
> -        <dependency groupId="net.sourceforge.cobertura" artifactId="cobertura"/>
> +        <dependency groupId="net.sourceforge.cobertura" artifactId="cobertura">
> +          <exclusion groupId="com.sun" artifactId="tools"/>
> +        </dependency>
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods {{monitorEnter}} + {{monitorExit}}. These methods are used by {{o.a.c.utils.concurrent.Locks}} which is only used by {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early development phase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org