In 2.0, ScannerImpl throws NoSuchMethod when using JDK8,

Issue #573 resolved
Peter Moore created an issue

ScannerImpl.class in 2.0 is using JDK 7 byte codes, but it contains a reference to a method that was introduced in JDK 9. This causes a NoSuchMethod error when it attempts to load that reference at runtime.

6 of the tests fail when using JDK8 because of this:

[ERROR] Errors:
[ERROR]   PyErrorsTest.testLoaderErrors:56 » NoSuchMethod java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
[ERROR]   PyErrorsTest.testLoaderStringErrors:78 » NoSuchMethod java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
[ERROR]   LongUriTest.testLongURIEscape:37 » NoSuchMethod java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
[ERROR]   NonAsciiCharsInClassNameTest.testLoad:38 » NoSuchMethod java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
[ERROR]   UriEncoderTest.testDecode:32 NoSuchMethod java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
[ERROR]   UriEncoderTest.testFailDecode:40 NoSuchMethod java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
[ERROR] Tests run: 1111, Failures: 0, Errors: 6, Skipped: 1

You can reproduce this with the following steps:

  • With JAVA_HOME set to a JDK11 instance, do ‘mvn clean install’
  • Then comment out the net.revelc.code.formatter element from pom.xml (it depends on jdk11 and for some reason it tries to run during the test phase)
  • With JAVA_HOME set to a JDK8 instance, do ‘mvn test’

This can happen if the code was compiled with target=JDK7, but with a JDK9 or later bootstrap classpath . (Basically the JDK9+ compilers will use static analysis to resolve overloaded calls at compile time when it can. So using the wrong bootstrap classpath can leave references to the compiling JDK’s methods rather than the target method.

My maven skills weren’t up to fixing the build of the multi-release jar. So I did a some brute force changes just to get a pure jdk7 jar (commenting out revelc, module-info-info, and test source and target settings to jdk11. (See atttached pom.xml) That produced a jar that passed all the tests.

This link and this link might be of help to fix to do a proper fix…

Comments (7)

  1. Alexander Maslov

    fixes Java7 compatibility

    As we are using java11 to build this project, utilize -release parameter for javac to prevent leakage of bootstrap classes implementation specifics into the generated bytecode.

    resolves #573

    → <<cset e8fbb2102045>>

  2. Log in to comment