- edited description
- attached pom.xml
In 2.0, ScannerImpl throws NoSuchMethod when using JDK8,
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)
-
reporter -
- changed status to open
-
-
assigned issue to
-
assigned issue to
-
- changed status to resolved
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>>
-
-
assigned issue to
-
assigned issue to
-
@Peter Moore can you please try the latest SNAPSHOT ? (2.1-SNAPSHOT)
-
reporter I’ve tried it and it looks good.
- Log in to comment