Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] Unable to run Servlet TCK on Java 11
Hi
I'd like to add a bit to the discussion :).
Great to see this finally discussed (I mentioned this [1] but didn't get any response :) )
I finished by running TCK only with jdk9 (and adding some hackhish --add-modules=jdk.incubator.httpclient )
So I looked at the code. The current TCK is already using 3 different http client implementations (commons-httpclient 3, apache httpclient4 and the JDK one)  which I would say it's not optimal.
Using Apache HttpClient 5.0 would mean one more :).

I would prefer to see using only one client (yes I know this can be a huge work ) and a client which has the same API for http1 and http2 (that will make the work easy).
Options I see:
- jdk new client (but have some issues jdk8 vs jdk11)
- apache httpclient 5.0 (not sure it's the same API for http1/2)
- jetty httpclient which have same API for http1/2 (and Jetty is an Eclipse project)

Olivier

On Sat, Jun 20, 2020 at 12:08 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On 6/19/20 11:02 AM, Steve Millidge (Payara) wrote:
>  From my perspective GlassFish is aiming to certify on JDK 11. The
> current milestone runs on JDK 8 however the next phase of work is to get
> that running (and hopefully compiling) on JDK 11.

IMO, we should setup our TCK CI jobs to run with either JDK 8 or 11, so
we can get more eyes on the JDK 11 failures.

Scott

>
> Steve
>
> *From:*jakartaee-tck-dev-bounces@xxxxxxxxxxx
> <jakartaee-tck-dev-bounces@xxxxxxxxxxx> *On Behalf Of *Scott Stark
> *Sent:* 19 June 2020 14:26
> *To:* jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
> *Subject:* Re: [jakartaee-tck-dev] Unable to run Servlet TCK on Java 11
>
>  From the release plan:
>
> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan
>
> The TCK requirement is that it MUST be run against Java 11, but may
> additionally use 8:
>
>
>       Java SE Version
>
> For inclusion in Jakarta EE 9, specification’s APIs MUST be compiled at
> the Java SE 8 source level. However, compatible implementations of the
> Jakarta EE 9 Web Profile and Full Profile MUST certify compatibility on
> Java SE 11. Compatible Implementations MAY additionally certify and
> support Java SE 8.
>
> ---
>
> So option 3 would seem to be the best approach in my view. Tag the
> current TCK source so that running a Java SE 8 version of the TCK could
> look to use that if it is desired.
>
> Is GlassFish going to certify against Java SE 8?
>
> On Fri, Jun 19, 2020 at 8:08 AM Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
>
>     Hi,
>
>     I am currently working the Servlet TCK and have hit an issue when
>     running on Java 11.
>
>     The Servlet TCK tests HTTP/2 functionality. To do this is uses an HTTP/2
>     client provided by http.jar. This appears the Java 9 module
>     jdk.incubator.http ported to Java 8. I can't find the source code for
>     ported version anywhere. The issue is that the ported code references
>     sun.misc.InnocuousThread which isn't present in Java 11.
>
>     I have looked at several potential solutions:
>
>     1. Avoid the code that triggers loading of InnocuousThread
>     This isn't possible.
>
>     2. Switch to a different HTTP/2 client. Apache HttpClient 5.0 supports
>     HTTP/2 but that would require an upgrade to HttpClient 5.0 for at least
>     all of the Servlet 5.0 TCK. It should be a safe upgrade but there are
>     risks attached to an upgrade. I dismissed this option due to the risks.
>
>     3. Provide a Java 11 version of these TCK tests that uses the
>     java.net.http API. This should be fairly easy to write but it would then
>     require the Servlet TCK to be compiled with Java 11. I am assuming that
>     a change to compiling with Java 11 is not an option at this stage.
>
>     4. Use reflection to provide a Java 8 compilable solution that uses Java
>     11 features when running on Java 11. This looks possible but is a lot of
>     work. It appears to be made more complex by changes in the API between
>     the incubator stage in Java 9 and the final version in Java 11.
>
>     5. Use BCEL to remove the references to InnocuousThread in http.jar.
>     This looks doable at this stage. There may be further complications once
>     the InnocuousThread issues are fixed.
>
>     My current thinking is:
>     - explore option 5
>     - if it works, provide the code I use to 'patch' http.jar in a text file
>        along side the HTTP/2 tests along with the patched JAR in a PR
>
>     Thoughts on my proposed solution? Suggestions of a better solution?
>
>     Thanks,
>
>     Mark
>     _______________________________________________
>     jakartaee-tck-dev mailing list
>     jakartaee-tck-dev@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
>     To unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>
>
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev


--
Olivier

Back to the top