NoSuchMethodError on ByteBuffer.position calls
Closed this issue · 13 comments
ByteBuffer.position calls (and possibly other ByteBuffer method calls) result in a java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; error under a Java 8 JRE. The root cause may be the one reported in this issue — namely, that compiling the bytecode with a Java 9 (9+?) JDK with --release 8 results in incorrect bytecode for Java 8.
I specifically ran into the error when using ByteBufferInputStream:
java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at it.unimi.dsi.io.ByteBufferInputStream.map(ByteBufferInputStream.java:127)
at it.unimi.dsi.io.ByteBufferInputStream.map(ByteBufferInputStream.java:113)
...
Ouch. That's bad. But the issue you report claims that -source 8 -target 8 don't work, whereas --release 8 works.
I admit I didn't read the whole thread. In any case, the issue manifests in the latest dsiutils release. Hopefully the fix is simply a matter of changing how it's compiled! Cheers, and thanks for sharing your work on this library!
I just fixed the build file. Could you try to build the new jar and tell me whether it works for you?
Will do.
I assume that ant jar is the correct target? It tells me to run ant ivy-setupjars but then I run into this error:
BUILD FAILED
/Users/anovstrup/dsiutils/build.xml:14: impossible to ivy retrieve: java.lang.RuntimeException: problem during retrieve of it.unimi.dsi#dsiutils: java.lang.RuntimeException: Multiple artifacts of the module org.slf4j#slf4j-api;1.7.30 are retrieved to the same file! Update the retrieve pattern to fix this error.
at org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:238)
at org.apache.ivy.Ivy.retrieve(Ivy.java:561)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:113)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.Project.executeTarget(Project.java:1374)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.Main.runBuild(Main.java:827)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
It's been a long time since I've used ant, unfortunately. It's not obvious to me what this means. :/
That was fixed a long time ago, it's weird. Is it possible that you have an old Ivy version?
Anyway, try here: http://vigna.di.unimi.it/dsiutils-2.6.18.jar
That worked! Thanks!
Thank you for the report. I added your name to the CHANGES file—please tell me if you want me to delete it.
By the way, I was able to get it to build the jar with ant by downgrading the slf4j dependency to 1.7.25. I guess other dependencies depend on the older version of that library, and the retrieve pattern doesn't distinguish among different versions.
It's possible. In the last few years, I'm sorry to say managing SLF4J dependencies has been a nightmare.
@vigna Do you know when a release with this fix is likely to hit Maven Central? Thanks again!
Er, I'm waiting for JSAP to released under ASF, so the whole chain of libraries does not depend on LGPL-only software (which is a problem with JGraphT, to which we are contributing). I wrote to the author today, let's see whether it happens.
It's done! It should appear soon.