[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372821#comment-15372821
]
Robert Stupp commented on CASSANDRA-9608:
-----------------------------------------
[~carlosabad], thanks for your effort! I've already created [a
branch|https://github.com/snazy/cassandra/tree/9608-java9-trunk] and thought I
left a comment about it in this ticket - apologies for that. I basically found
the same issues. But I'm a bit opposed to the use of {{ReentrantLock}} since
there are usually a huge amount of {{AtomicBTreePartition}} instances and each
{{ReentrantLock}} can potentially create lot of dependent objects - tl;dr it
potentially introduces a lot of GC pressure. So, what we would need here is an
exclusive lock, which doesn't need to be fair, that is just good enough - not
sure whether [my
approach|https://github.com/snazy/cassandra/commit/c67c532fec9b2b073ecdf70b50b80440fb972f31#diff-7246e27576858f45f3f2678b9be03bfeR105]
is good enough, though.
Would be glad to have you on board and tackle this ticket!
Many of the tests fail because we evaluate the system property
{{java.vm.version}} in out agent library [jamm at this
line|https://github.com/jbellis/jamm/blob/17fe5661d3706ac8bdcc2cc1a1d747efa00157fa/src/org/github/jamm/MemoryLayoutSpecification.java#L190].
The meaning of the version has changed completely. Before Java 9, it looked
like {{25.92-b14}} but with Java 9 is looks like {{9-ea+121}} - i.e. the
agent's code throws a {{StringIndexOutOfBoundsException}}. A viable solution
(viable workaround is probably a better term, though) could be to let jamm
produce Java 8 byte code and remove the {{java.vm.version}} check and/or change
the code in jamm. We use jamm to calculate on-heap usage of objects.
We might have to support both Java 8 and Java 9 (as soon as Java 9 is GA) for
some period of time - similar to the transition from Java 7 to Java 8, where we
built C* on Java 7 but kind-of supported Java 8 before actually just C* 3.0
required Java 8. I think a major version (maybe 5.x?) would be required for
such a switch. Just want to say, that both the code and the build.xml file need
to work against Java 8 _and_ 9. (Requiring ant 1.9.7 is not an issue imo.)
> Support Java 9
> --------------
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
> Reporter: Robert Stupp
> Priority: Minor
>
> 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
(v6.3.4#6332)
