cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Tunnicliffe <>
Subject Re: Java8 compatibility broken in 4.0
Date Tue, 11 Jun 2019 10:48:55 GMT

> On 11 Jun 2019, at 10:04, Tommy Stendahl <> wrote:
> Hi,
> I can't find a way to build 4.0 artifacts so I can run Cassandra using Java8. Building
the artifacts ("ant artifacts" or "ant mvn-install") requires building with Java11 but since
CASSANDRA-15108 the result is not Java8 compatible anymore, is this intentional or was this
done by mistake?

This was unintentional, it looks like we just missed removing the “unless=java.version.8”
from the artifacts & _artifacts-init targets in build.xml.
I’ve tested that with those removed, it’s just a matter of having the appropriate target
jdk specified in $JAVA_HOME (and using -Duse.jdk11=true or $CASSANDRA_USE_JDK11=true if building
with jdk11).

We’ll fix this in trunk, but in the meantime removing those conditions should unblock you.


> I also tried to change this back and force Java11 to build Java8 compatible code but
it seams that there are some  changes in the ByetBuffer implementation in Java11 that breaks
when execution in a Java8 jvm, when I started Cassandra it throws a NoSuchMethodError when
trying to open the sstables.
> 2019-05-28T16:20:24.506+0200 [SSTableBatchOpen:4] ERROR o.a.c.i.s.format.SSTableReader$2:576
run Corrupt sstable /var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big=[CompressionInfo.db,
TOC.txt, Statistics.db, Summary.db, Index.db, Data.db, Filter.db, Digest.crc32]; skipping
> Corrupted: /var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big-Statistics.db
>        at
>        at
>        at$
>        at java.util.concurrent.Executors$
>        at
>        at java.util.concurrent.ThreadPoolExecutor.runWorker(
>        at java.util.concurrent.ThreadPoolExecutor$
>        at
>        at
> Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
>        at org.apache.cassandra.utils.memory.BufferPool.allocateDirectAligned(
>        at org.apache.cassandra.utils.memory.BufferPool.access$600(
>        at org.apache.cassandra.utils.memory.BufferPool$GlobalPool.allocateMoreChunks(
>        at org.apache.cassandra.utils.memory.BufferPool$GlobalPool.get(
>        at org.apache.cassandra.utils.memory.BufferPool$LocalPool.addChunkFromGlobalPool(
>        at org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(
>        at org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(
>        at org.apache.cassandra.utils.memory.BufferPool.takeFromPool(
>        at org.apache.cassandra.utils.memory.BufferPool.get(
>        at<init>(
>        at$Unaligned.<init>(
>        at
>        at
>        at
>        at
>        ... 8 common frames omitted
> The reason for this is that some methods in the ByteBuffer implementation in Java11 returns
a Bytebuffer but in Java8 and before they returned a Buffer. I found a bit of information
on Stackoverflow (
so there seams to be a way to fix this even if the resulting code looks ugly to me.
> My question is, are we intentionally giving up Java8 comparability in 4.0 or do we still
want to support Java8?
> Regards,
> Tommy

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message