[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Jakarta EE 9.1 testing with Java SE 11 - JSTL Bucket
|
The Bean Validation, Dependency Injection, and CDI TCKs all pass for us with Java 11 without any new wrinkles.
The signature tests are the one thing I haven't run yet. Our automation to set those up currently uses a java.ext.dirs argument, which of course does not exist in Java 11. We're working on a new solution there and should be able to share those results before too long.
The other failures that we have to figure out on our end are the optional JAX-WS tests that require the wsimport tool.
-Brian
Scott Marlow ---02/04/2021 03:12:47 PM---Brian, Thanks for reporting your results, very much appreciated!
From: Scott Marlow <smarlow@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Brian M Decker <bmdecker@xxxxxxxxxx>
Date: 02/04/2021 03:12 PM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] Jakarta EE 9.1 testing with Java SE 11 - JSTL Bucket
Brian,
Thanks for reporting your results, very much appreciated!
Did the 9.1 TCK signature tests pass? How about the Bean Validation, Dependency Injection + CDI TCKs with Java 11?
On 1/29/21 3:38 PM, Brian M Decker wrote:
Now that an early version of the 9.1 TCK is available, it seems like a good time to start discussing potential issues with Java 11 testing. We've been testing using Java 11 & the 9.0.x TCK with Open Liberty for quite some time, and we've had success getting a large percentage of the tests working with little trouble.
One area of obvious difference that we should discuss is in the JSTL bucket. There are 29 tests doing things with Dates, TimeZones, and the like that fail for us when using Java 11.
Did the signature tests pass?Did you also run the Bean Validation, Dependency Injection + CDI TCKs with Java 11?
Typical failure [Note the added comma]:
Goldenfile -
Dec 26, 1997 10:11:34 PM<br>
Server response -
Dec 26, 1997, 10:11:34 PM<br>
Java 9+ changed to using CLDR for locales so there's a handful of minor differences like the above reflected throughout the results. There is a JVM option (-Djava.locale.providers=COMPAT) that reverts the behavior to what was used in Java 8, and the tests pass fine with that in place. Is that the right solution here, or should we be looking at adding/updating golden files in the TCK so they are correct for Java 11?
IMO, the same problem will be seen by applications which also will need to use the -Djava.locale.providers=COMPAT option on Java 11 (thanks for sharing that!).Regarding your question, I suppose that applications will have the same question. do applications need to to rewrite code to be able to run on both Java SE 8 + 11 or depend on the JVM COMPAT option. Both approaches seem valid to me.