Java 11 support

[cyrille-artho]

There is a branch java-10-gradle that we use for work to support Java 11 (that started with Java 10 support).

To reproduce the current state, try to install OpenJDK version 11 and compile the code from that branch, and run the tests with ./gradlew check.

Currently 16 unit tests are still failing there. Fixes are very welcome. Some of these problems below are already referenced in an issue. If someone starts to work on a particular test, please create a separate issue referring to one or two of these failing tests:

    CountDownLatchTest. testCountDown
    ExecutorServiceTest. testShutdown
    SemaphoreTest. testResourceAcquisition
    ObjectStreamTest. testSimpleReadbackOk
    RuntimeTest. testAvailableProcessors
    StackWalkerTest. testCallerClass
    URLClassLoaderTest. testThrownException
    DateFormatTest. testConversionCycle
    DateFormatTest. testFormatWithTimeZone
    DateFormatTest. testSetAndGetTimeZone
    SimpleDateFormatTest. testFormatWithTimeZone
    RecursiveClinitTest. testNewInstance
    ProxyTest. testAnnoProxy
    ProxyTest. testBasicProxy
    InterruptTest. testPark
    SAXParserTest. testSimpleParse 

[cyrille-artho]

How to help with failing tests for Java-11 support

1. Make sure Java 11 is enabled by default, e.g.,

export JAVA_HOME="`/usr/libexec/java_home -v11.0.2`"

on Mac OS X, similar setting on Linux.

2. Build and run the unit tests on the branch relating to Java 10/11:

git checkout java-10-gradle
git pull
./gradlew clean check

3. Look at the overall summary in build/reports/tests/test/index.html for the summary you see above in this post.

4. To look at a particular unit test failure, look at the XML report, e.g.,

less build/test-results/test/TEST-gov.nasa.jpf.test.java.concurrent.CountDownLatchTest.xml

Parts of the log relating to the failure:

    <failure message="java.lang.AssertionError: JPF found unexpected errors: gov.nasa.jpf.vm.NoUncaughtExceptionsProperty" type="java.lang.AssertionError">java.lang.AssertionError: JPF found unexpected errors: gov.nasa.jpf.vm.NoUncaughtExceptionsProperty
        at gov.nasa.jpf.util.test.TestJPF.fail(TestJPF.java:164)
        at gov.nasa.jpf.util.test.TestJPF.noPropertyViolation(TestJPF.java:816)
        at gov.nasa.jpf.util.test.TestJPF.verifyNoPropertyViolation(TestJPF.java:830)
        at gov.nasa.jpf.test.java.concurrent.CountDownLatchTest.testCountDown(CountDownLatchTest.java:41)

The fourth line in the stack trace points to the test in question, here: src/tests/gov/nasa/jpf/test/java/concurrent/CountDownLatchTest.java:41.

In the test log, you can find the output of JPF in the CDATA section:

<system-out><![CDATA[

Inside that section, you can see why the test actually fails:

====================================================== error 1
gov.nasa.jpf.vm.NoUncaughtExceptionsProperty
java.lang.UnsatisfiedLinkError: cannot find native java.lang.invoke.MethodHandleNatives.registerNatives
        at java.lang.invoke.MethodHandleNatives.registerNatives(no peer)
        at java.lang.invoke.MethodHandleNatives.<clinit>(MethodHandleNatives.java:101)
        at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1070)
        at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1098)
        at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:2021)
        at java.lang.invoke.MethodHandles$Lookup.findVarHandle(MethodHandles.java:1514)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.<clinit>(AbstractQueuedSynchronizer.java:2307)
        at java.util.concurrent.CountDownLatch.<init>(CountDownLatch.java:201)
        at gov.nasa.jpf.test.java.concurrent.CountDownLatchTest.testCountDown(CountDownLatchTest.java:43)
        at java.lang.reflect.Method.invoke(gov.nasa.jpf.vm.JPF_java_lang_reflect_Method)
        at gov.nasa.jpf.util.test.TestJPF.runTestMethod(TestJPF.java:648)

So the reason for this test failing is in a class that is used inside the code (and not directly related to CountDownLatch): java.lang.invoke.MethodHandleNatives. This code is part of the extended Java reflection functionality, which has been mostly rewritten for Java 11. The new version is completely incompatible, so all code inside JPF that relies on it has to be rewritten.

To fix this, it may be a good idea to start closer to the source where the test fails:

• CountDownLatch uses AbstractQueuedSynchronizer in its constructor; that class in turn uses MethodHandles.
• CountDownLatch is currently taken from the underlying Java library. Possible solutions can work in two ways:

(a) You write a model class for JPF, which replaces the build-in library class of the host JVM with a simplified version that is as close as possible to the original, yet compatible with JPF. This allows you to rewrite code in a way that avoids dependencies with problematic code that has native methods which JPF cannot execute.
(b) You instead look at some of the dependencies and write model classes for them. Candidates can be any of the classes higher in the stack frame.

Finding out which solution works best depends on each case and may take some trial and error.

[puneetkathar1]

who ever is thinking to give it a try by solving all the errors one by one, just don't waste your time. I have been trying this since 20 days, and errors are still coming. There are infinite errors.

[cyrille-artho]

@puneetkathar1 : Thank you for trying to resolve some of these test failures. Some of them are indeed quite difficult to eliminate, but we have had some success; Malte contributed a patch that resolves two issues (one was build-related, the other one required changes in the model classes).
The remaining failing unit tests are not the only, and not the ultimate, measure of Java 11 compatibility. Some of them show a problem that lies a few layers underneath (when you look at the stack trace).

It is therefore also useful for us if you can make a step towards isolating such a problem better, and create a new unit test that highlights a smaller-scale problem failing. Even if fixing such a new test will not fix on of the remaining 16 unit tests, it will improve Java 11 compatibility for us.

[mmuesly]

I spend some time on coming up with an idea for:

    DateFormatTest. testConversionCycle
    DateFormatTest. testFormatWithTimeZone
    DateFormatTest. testSetAndGetTimeZone
    SimpleDateFormatTest. testFormatWithTimeZone

Hopefully, I might fix them soon. If anyone considers to work on them, I might provide some hints.

[cyrille-artho]

mmuesly's PR fixed a lot of issues at once. Thanks a lot! Now 11 failing tests left:

    ObjectStreamTest. testSimpleReadbackOk
    RuntimeTest. testAvailableProcessors
    StackWalkerTest. testCallerClass
    DateFormatTest. testConversionCycle
    DateFormatTest. testFormatWithTimeZone
    DateFormatTest. testSetAndGetTimeZone
    SimpleDateFormatTest. testFormatWithTimeZone
    RecursiveClinitTest. testNewInstance
    ProxyTest. testAnnoProxy
    ProxyTest. testBasicProxy
    SAXParserTest. testSimpleParse

[iirekm]

+1

[Ln11211]

I spend some time on coming up with an idea for:

    DateFormatTest. testConversionCycle
    DateFormatTest. testFormatWithTimeZone
    DateFormatTest. testSetAndGetTimeZone
    SimpleDateFormatTest. testFormatWithTimeZone

Hopefully, I might fix them soon. If anyone considers to work on them, I might provide some hints.

Hello @cyrille-artho , I might try them after I take a look at them(and hopefully understand the code), well @mmuesly , hints please?

[mmuesly]

@Ln11211 excuse the delay.

If you run the debugger across these test cases, you should find a similar place that fails. Setting runDirectly=true; as first line in the test allows to run the tests on the native VM instead. By observing the difference, you should find a point in the local resolving code that has some strange invocation targets for lambda expressions. That's the first point to get started.

[Ln11211]

mmuesly's PR fixed a lot of issues at once. Thanks a lot! Now 11 failing tests left:

    ObjectStreamTest. testSimpleReadbackOk
    RuntimeTest. testAvailableProcessors
    StackWalkerTest. testCallerClass
    DateFormatTest. testConversionCycle
    DateFormatTest. testFormatWithTimeZone
    DateFormatTest. testSetAndGetTimeZone
    SimpleDateFormatTest. testFormatWithTimeZone
    RecursiveClinitTest. testNewInstance
    ProxyTest. testAnnoProxy
    ProxyTest. testBasicProxy
    SAXParserTest. testSimpleParse

Hello @cyrille-artho , I tried to build and run the tests and I got 13 failed tests. The two new failed tests are from the class URLClassLoaderTest. Can you confirm ?

[Ln11211]

@Ln11211 excuse the delay.

If you run the debugger across these test cases, you should find a similar place that fails. Setting runDirectly=true; as first line in the test allows to run the tests on the native VM instead. By observing the difference, you should find a point in the local resolving code that has some strange invocation targets for lambda expressions. That's the first point to get started.

Yeah, you are right, Setting runDirectly=true; helped the Test pass and Like you said I tried finding where the test is failing, I followed the procedure @cyrille-artho followed for CountDownlatch test. I have a lot of questions, is there a chat room where I can ask people 1on1? I know there is a mailing list but, @mmuesly , do you use Discord?

[gaurangkudale]

Hi @Ln11211
Javapathfinder also have Discord server group

[cyrille-artho]

We mostly use the Java Pathfinder Google Group and this issue tracker for communication, as it is difficult to find a suitable time slot for communication. This applies especially in the middle of academic terms, as most of us work at universities. We usually have 1 on 1 meetings for summer projects.

[ThisTestUser]

Hi, I have a possible solution for one of the failing cases (testSimpleReadbackOk), please see #325. I'm not sure if this fixes it in Java 11 though.

Update: The issue is much more complex in Java 11, as there are some missing methods in java.lang.Class and java.lang.Constructor that need to be added first.

[ThisTestUser]

String concatenation is currently not handled properly in Java 11 also. There is currently no test for this (see #327).

[cyrille-artho]

Thanks, we were aware of the string concatenation but did not have a good unit test for it. I've merged that PR (#327).
PR #325 causes another test to fail (on Java 8); please take a look.

[cyrille-artho]

Current list:
[ ] ObjectStreamTest. testSimpleReadbackOk
[ ] DateFormatTest. testConversionCycle
[ ] DateFormatTest. testFormatWithTimeZone
[ ] DateFormatTest. testSetAndGetTimeZone
[ ] SimpleDateFormatTest. testFormatWithTimeZone
[ ] SAXParserTest. testSimpleParse

Other:
A couple of warnings about illegal access operations using reflection have to be addressed as well; these warnings will be errors in future releases.

[cyrille-artho]

Varadraj works on the (Simple)DateFormatTest failues, Daohan on the others.

[cyrille-artho]

We made great progress! Current status:

[ ] ObjectStreamTest. testSimpleReadbackOk: works on some JDKs but not all
[ ] SAXParserTest. testSimpleParse: works on some JDKs but not all (as per an earlier attempt that is not merged yet)

[cyrille-artho]

We now support all unit tests (on OpenJDK 11), so the remaining tasks are:

• Fix a method dispatch error
• Check if any important functionality from master is missing
• Update documentation (wiki) and CI configuration

[cyrille-artho]

Documentation and CI configuration are pending.

[cyrille-artho]

CI configuration is updated, only the wiki update is pending.

[cyrille-artho]

We are all set for Java 11 now!

[ghost-cai]

I used the master branch.
OpenJDK version 11

I have executed the command gradle build, and I got the test error.

java.lang.AssertionError: JPF found unexpected errors: gov.nasa.jpf.vm.NoUncaughtExceptionsProperty

Has the issue been fixed? I have saw the same error in this issue.