[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [glassfish-dev] Fixes that allow GlassFish 5.1 to run on both JDK 8 and JDK 11.
|
Sorry, I misrepresented the work below -- In general, we don't expect
the TCK itself will need to change to support independent versions of
Java SE between the CI and the VI. Sorry for that confusion. Generally,
we expect this work will be confined to the continuous integration
scripts themselves. (Also, CI is intended to be Compatible
Implementation, not Continuous Integration. That is probably also a
potential source of confusion.)
-- Ed
On 1/29/2020 5:48 PM, Ed Bratt wrote:
Sawamura Hiroki:
Is a version release of GlassFish that does not pass the TCK acceptable?
Generally, we should try to avoid this -- if not outright disallow this.
The TCK committer team have started working on updates in the TCK
(itself and the CI jobs) to support running the VI (the test
Application Server) with against the CI (the compatible
implementation) with each product using different versions of the Java
runtime. This is a preliminary to achieving what you are working
toward (running the VI on JDK 11 and the CI on JDK 8).
This work is just getting started and probably ought to be discussed
on the jakartaee-tck-dev discussion list. I have added that list for
introductions. Perhaps we can prune the discussion distribution, once
folks have a chance to decide where it makes most sense to continue.
Generally, this TCK work is just getting started but I would hope we
can complete this in time to be useful for an effort like this.
The work I describe above is separate from modifications to the TCK in
support of the name-space changes.
-- Ed
On 1/29/2020 4:51 PM, sawamura.hiroki@xxxxxxxxxxx wrote:
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
_______________________________________________
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
_______________________________________________
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