Re: [glassfish-dev] Fixes that allow GlassFish 5.1 to run on both JDK 8

["sawamura.hiroki@xxxxxxxxxxx" <sawamura.hiroki@xxxxxxxxxxx>]

Certainly, the amount of fixes required to run GlassFish 5.1 on JDK 11 is not that large, but it may be difficult given the namespace migration and future maintenance...
However, the JakartaEE 8 specification does not appear to have any limitations on the version of JavaSE used to run the application server, but if we create GlassFish 5.2, we'll need to pass TCK 8 to maintain Jakarta EE 8 compatibility. At the time, we'll need to be able to work TCK 8 on JDK 11 or GlassFish 5.1 on JDK 8. When I previously tried to run TCK 8 on JDK 11, it didn't run with only the ts.jte environment file modification.

Is a version release of GlassFish that does not pass the TCK acceptable?

-----Original Message-----
From: Bill Shannon <bill.shannon@xxxxxxxxxx> 
Sent: Wednesday, January 29, 2020 1:19 PM
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>; Sawamura, Hiroki/澤村 大輝 <sawamura.hiroki@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Fixes that allow GlassFish 5.1 to run on both JDK 8 and JDK 11.

When I first saw this issue, I was thinking it was about making GlassFish 6 (the Jakarta EE 9 release) work on both JDK 8 and JDK 11.  The issues with doing this for GlassFish 5 are even worse because none of the components that feed into GlassFish are being updated to run on JDK 11 with their Java EE 8 versions.  Some of them already do, but for those that don't, the Java EE 8 versions will probably never be updated.

Here's the comment I added to the referenced issue:

--- begin comment

I'm not at all convinced that it's worth the effort to make GlassFish work on both JDK 8 and JDK 11.  Part of the problem is that it will require every component that's used in GlassFish to work on both JDK 8 and JDK 11. This might be especially complicated for those components that replace JDK 8 components since they won't really replace them when using the jakarta.* namespace.  Will two versions of JAX-WS / Jakata XML Web Services coexist on JDK 8?  [Obviously this isn't an issue for GlassFish 5, which wouldn't use the jakarta.* versions of the components.]

This is not just about you doing the work to handle JVM options.
This is about every other component committing to do the work to run on JDK 8, and you committing to do whatever else it takes to make all these components work, which is likely much more than just handling JVM options.

--- end comment

I can understand the demand to have a version of GlassFish 5 that works on JDK 11.  It would be reasonable to create a GlassFish 5.2 that *only* runs on JDK 11.  I think that's an acceptable amount of work.  It's not perfect from a customer perspective, but unless you're signed up to do all the work that's implied by the above, that may be the best we can do.



sawamura.hiroki@xxxxxxxxxxx wrote on 1/27/20 11:43 PM:
> Hi All,
> 
> Let me discuss the following issue on this mailing list:
> https://github.com/eclipse-ee4j/glassfish/issues/22884
> 
> I'm trying to modify GlassFish 5.1.0-run-with-JDK11 branch to work with both JDK 8 and JDK 11 because GlassFish 5.1 must pass TCK 8 to be compatible with Jakarta EE 8, but currently TCK 8 only works on JDK 8.
> 
> - Why am I trying to run GF 5.1 on JDK 11?:
>   Next Jakarta EE 9 is a tooling release, only a package migration, no feature additions. So I think most GlassFish users 
>   will continue to use Jakarta EE 8 for a while. On the other hand, Java SE 8 is about six years old, has an outdated API, 
>   and doesn't support the new encryption suite. Thus, GlassFish 5.1's support for Java SE 11, based on Jakarta EE 8, will
>   be valuable to GlassFish users.
> 
> Currently, some projects related to GlassFish are provided with a 
> multi-release jar module that can be run on both JDK 8 and JDK 11 
> (such as: eclipse-ee4j/orb-gmbal-pfl, eclipse-ee4j/jaxb-ri, 
> eclipse-ee4j/metro-jax-ws, eclipse-ee4j/metro-wsit). By using these 
> modules and modifying some of GlassFish's core sources, I think 
> GlassFish will work on both JDK 8 and JDK 11. But, on the other hand, 
> GlassFish 6.x does not require JDK 8 support. So I'd like to modify in 
> a way that allows this mechanism to be used if JDK 8 needs to be 
> supported later and less intrusive if JDK 8 no longer needs to be 
> supported. (For example, I think Idea2 and Idea3 in the above 
> issue(#22884) are relatively unobtrusive modifications.)
> 
> Suggestions and comments would be greatly appreciated.
> 
> Thanks,
> Hiroki
> _______________________________________________
> glassfish-dev mailing list
> glassfish-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/glassfish-dev
>