Hi All,
Just FYI
I did a Java 8 build (dist - to be more spcific, that involves $ ant
artifacts) from 4.0 trunk (after git pull) on Sunday morning (so 9th of
June) - there were no issues for me
I did it on both Windows and Linux (Debian) machines
Maybe there were commits since then.. I have not checked... But if not
then it is interesting...
cheers
Attila
On 11.06.2019 12:40 PM, Aleksey Yeshchenko wrote:
No, this is not intentional. At the very least for 4.0 we are going to keep
compatibility with Java 8.
On 11 Jun 2019, at 10:04, Tommy Stendahl <tommy.stend...@ericsson.com> 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?
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 table
org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
/var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big-Statistics.db
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:504)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:375)
at
org.apache.cassandra.io.sstable.format.SSTableReader$2.run(SSTableReader.java:571)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoSuchMethodError:
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at
org.apache.cassandra.utils.memory.BufferPool.allocateDirectAligned(BufferPool.java:528)
at
org.apache.cassandra.utils.memory.BufferPool.access$600(BufferPool.java:46)
at
org.apache.cassandra.utils.memory.BufferPool$GlobalPool.allocateMoreChunks(BufferPool.java:279)
at
org.apache.cassandra.utils.memory.BufferPool$GlobalPool.get(BufferPool.java:248)
at
org.apache.cassandra.utils.memory.BufferPool$LocalPool.addChunkFromGlobalPool(BufferPool.java:354)
at
org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:397)
at
org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(BufferPool.java:143)
at
org.apache.cassandra.utils.memory.BufferPool.takeFromPool(BufferPool.java:115)
at org.apache.cassandra.utils.memory.BufferPool.get(BufferPool.java:94)
at
org.apache.cassandra.io.util.BufferManagingRebufferer.<init>(BufferManagingRebufferer.java:45)
at
org.apache.cassandra.io.util.BufferManagingRebufferer$Unaligned.<init>(BufferManagingRebufferer.java:117)
at
org.apache.cassandra.io.util.SimpleChunkReader.instantiateRebufferer(SimpleChunkReader.java:60)
at
org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:319)
at
org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:500)
... 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
(https://stackoverflow.com/questions/48693695/java-nio-buffer-not-loading-clear-method-on-runtime)
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: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
