Hi Attila, I just realized that the build I was using was two weeks old, but now I have double checked with the latest trunk and there is no changes in this area and I get the same behavior.
One explanation might be that "artifacts" dosen't fail, if just do nothing due to the “unless=java.version.8”, the failure is in mvn-install: [artifact:mvn] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file (default-cli) on project standalone-pom: File not found /repos/Ctrunk/cassandra/build/apache-cassandra-4.0-SNAPSHOT-dist.pom: /repos/Ctrunk/cassandra/build/apache-cassandra-4.0-SNAPSHOT-dist.pom (No such file or directory) -> [Help 1] I think that the apache-cassandra-4.0-SNAPSHOT-dist.pom should have been generated in the artifacts step. /Tommy On tis, 2019-06-11 at 14:00 +0200, Attila Wind wrote: 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<mailto: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<mailto:dev-unsubscr...@cassandra.apache.org> For additional commands, e-mail: dev-h...@cassandra.apache.org<mailto:dev-h...@cassandra.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org<mailto:dev-unsubscr...@cassandra.apache.org> For additional commands, e-mail: dev-h...@cassandra.apache.org<mailto:dev-h...@cassandra.apache.org>
