Openjdk-tests: Invalid JTReg Test: java/net/CookieHandler/B6791927.java

[adam-thorpe]

This test sets a cookie with an expiry date of Sat 09-Nov-2019 (which has now expired lol), which is causing the test to fail. My guess is that whoever wrote the test wasn't expecting it to be used however many years later. Setting a future date allows this test to pass.

Test: https://github.com/ibmruntimes/openj9-openjdk-jdk13/blob/openj9/test/jdk/java/net/CookieHandler/B6791927.java

java.lang.RuntimeException: Expiration date shouldn't be 0
    at B6791927.main(B6791927.java:46)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
    at java.base/java.lang.Thread.run(Thread.java:831)

[adam-thorpe]

Interesting to note that this is passing on jdk8 with the latest builds, not sure why this is the case but testing locally will cause the failure

[smlambert]

https://bugs.openjdk.java.net/browse/JDK-8234007

[smlambert]

Before raising issues in this repo when hitting a problem with openjdk / jtreg tests, its best practice to look in JBS to see if there has already been a report upstream (in the repo and bug reporting system from where the test material came). (see https://github.com/AdoptOpenJDK/openjdk-tests/blob/master/doc/Triage.md#check-for-an-existing-issue).

[adam-thorpe]

To be fair, the issue wasn't created in the bugs database when I raised this issue. However, I don't think I checked and need to get into the habit of doing so anyway. I'll close this then

[smlambert]

Ha, fair enough, but in the case where you discover an openjdk test case is (clearly) wrong, it should get reported it upstream (you would have been ahead of the crowd).

See https://github.com/AdoptOpenJDK/openjdk-tests/wiki/Guidance-for-Creating-OpenJDK-Test-Defects, and AdoptOpenJDK has a # jbs slack channel to ask for help from people who can raise issues in JBS.

[M-Davies]

@smlambert Have there been any changes to which branch of the extensions repo's we test on over the christmas period? This test is not fixed on the openj9 branch and has started failing again (with the same error) since 26/12/2019

[smlambert]

I believe only recent change to where we pull test material from came on Nov 20th, https://github.com/AdoptOpenJDK/openjdk-tests/pull/1447

However, the test was re-included 14 days ago, so 20/12/2019... https://github.com/AdoptOpenJDK/openjdk-tests/pull/1517

Is there a plan to backport or pull in the fix to the extensions repo, if its already been delivered upstream (as in https://bugs.openjdk.java.net/browse/JDK-8234007 is resolved)?

[M-Davies]

There is no plan that I know of yet, it was believed to be fixed after JDK-8234007 was merged into the master branch of the extensions repo. Since it appears that the nightlies are using the openj9 branch over the master branch, pulling the fix into the openj9 branch would resolve the issue?

[smlambert]

whatever branch that is being used to build the sdk, is the branch we must pull test material from (to avoid skew). So yes, the expectation is that pulling fix into the branch used to build nightlies would resolve it.

[adam-thorpe]

We build and test using the openj9 branch. Changes from upstream are merged into master and then the tags are checked to see if we have a newer build (current tag in master/upstream is 13.0.1+9). This is why we are still seeing the test fail in the openj9 branch on jdk13... When the tag is updated for 13.0.2 the change will be merged into staging and openj9