Re: [jakartaee-tck-dev] Unable to run Servlet TCK on Java 11

[Mark Thomas <markt@xxxxxxxxxx>]

Thanks both, that helps.

Option 3 would be very attractive if the TCK could be built with Java
11. I just tried to build the Servlet TCK and the build failed. Issues
with use of java.endorsed.dirs by the looks of it.

It should be possible to fix the Java 11 build issues with the TCK but
my sense is that that could be a fair amount of work.

I started down the option 4 route last night but stopped to re-evaluate
as the work required continued to grow. It is do-able, but work looks to
be enough to justify at least exploring other options a little more.

Given all of the above, I am going to take a look at option 5 and try
and get a sense of how much work is involved.

As an aside, Apache Tomcat intends to certify with Java 8 and Java 11
for Servlet, JSP, EL and WebSocket.

Mark


On 19/06/2020 14:46, Kevin Sutter wrote:
> I agree with Scott.  Our first priority is to certify with Java 11.
>  But, we need the ability to allow implementations to certify with Java
> 8, if they desire.  So, would Option 3 satisfy both requirements?  This
> approach sounds like it would require two versions of this TCK -- one
> for Java 11 and one for Java 8.  Maybe one of the tricks with Option 4
> or 5 would be a more flexible approach?
> 
> At this point, I don't know if Glassfish will be certifying against Java
> SE 8...  I do know that Open Liberty would like to certify against both
> Java 11 and Java 8.
> 
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Jakarta EE architect @ IBM
> e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)    
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
> 
> 
> 
> From:        Scott Stark <starksm64@xxxxxxxxx>
> To:        jakartaee-tck developer discussions
> <jakartaee-tck-dev@xxxxxxxxxxx>
> Date:        06/19/2020 08:26
> Subject:        [EXTERNAL] Re: [jakartaee-tck-dev] Unable to run Servlet
> TCK on Java 11
> Sent by:        jakartaee-tck-dev-bounces@xxxxxxxxxxx
> ------------------------------------------------------------------------
> 
> 
> 
> 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@apache.org_
> <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@eclipse.org_ <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
>