Hi,
so when I run one of the tests in Eclipse, the stack trace is more complete:
java.lang.NoSuchMethodError:
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at org.apache.uima.util.impl.DataIO.decodeUTF8(DataIO.java:68)
at org.apache.uima.util.impl.DataIO.readUTFv(DataIO.java:124)
at
org.apache.uima.cas.impl.BinaryCasSerDes4$Deserializer.deserialize(BinaryCasSerDes4.java:1647)
at
org.apache.uima.cas.impl.BinaryCasSerDes4$Deserializer.access$200(BinaryCasSerDes4.java:1472)
at
org.apache.uima.cas.impl.BinaryCasSerDes4.deserialize(BinaryCasSerDes4.java:281)
at
org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:569)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:381)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:312)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:236)
at
de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:211)
at
de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:527)
at
de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test4Preinitialized(BinaryCasWriterReaderTest.java:150)
DataIO.java:68:
68: in.position(in.position() + length);
69: return sb.toString(); // doesn't copy the string char array
The signature of Buffer.position(int) in Java 1.8 is:
public final Buffer position(int newPosition) {...
... and ByteBuffer does not override it.
E.g. looking at Java 10, I can see this method signature in ByteBuffer overiding
the position(int) method from Buffer using a co-variant return type:
ByteBuffer position(int newPosition) {
super.position(newPosition);
return this;
}
The trouble is that when we compile UIMAv3 against a recent Java, DataIO binds
against
this co-variant override which causes the exception when we actually trying to
run that
on a Java 8 then.
The verbose option logs all the loaded classes to the console, but I'm not sure
what information would be of interest to you.
Cheers,
-- Richard
> On 10. Nov 2018, at 20:42, Marshall Schor <[email protected]> wrote:
>
> Hi, you're very kind to keep trying things :-) One more thing to try:
>
> Rerun the failing scenario, but start the JVM with the -verbose:class JVM
> parameter, so we could see what was loading the class that caused the error.
> The JVM loads classes in parallel by default I think, so in the trace it might
> not be the immediately preceding class...
>
> Cheers. -Marshall
