Re: Compat versions

[Rémy Maucherat]

On Fri, Dec 18, 2020 at 2:56 PM Romain Manni-Bucau 
wrote:

> Hmm, a few thoughts on this topic:
>
> 1. there is no reason to use reflection in jrecompat (all the java > build
> time version) impl can be generated in ant build using asm or bcel
> 2. all JreCompat are kind of hardcoded SPI, if this API gets a "ordinal" -
> priority - and a "matches(int javaMajor)" then it becomes simple to pick
> only the highest impl matching current java version (ie on java 8 it will
> use the default, on java 12 it will use java12 or 11 or  8 impl, on
> java 17 it will use java 17 impl etc).
>
> So overall it is mainly about making the maintenance of the code easier but
> not about dropping any feature or reducing support list IMHO.
> Build time generation can help a lot with that (@Implement(spi =
> JreCompat.class, since = 12) which would lead to jrecompat12, jrecompat13,
> , jrecompatLast override of an impl for a method - being said playing
> with inheritence between versions enables to drop duplication).
> This kind of tool is not harder than the jakarta migration tool and can
> solve that "fast pace" issue IMHO.
> Requires some build/tool investment but it likely interesting to keep a
> high support level for end user and reduce maintenance cost for tomcat
> itself.
>
> Hope it makes sense.
>

This is more than what I expected to do.

But ok, I got the main feedback from you and Chris, the compatibility
should be kept per branch. I have a hard time seeing us give any support to
users running on Java 13 (just an example) though, but ok it doesn't need
to be made more difficult.

Rémy


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 18 déc. 2020 à 14:33, Christopher Schultz <
> ch...@christopherschultz.net> a écrit :
>
> > Rémy,
> >
> > On 12/18/20 08:20, Rémy Maucherat wrote:
> > > On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov  >
> > > wrote:
> > >
> > >> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat 
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I'd like to refactor the compat classes to align with the LTS
> versions:
> > >>> - Move Jre9Compat to Jre11Compat
> > >>> - I'll probably refactor out GraalCompat
> > >>> - For the upcoming Java 12+ features, they will all go to a new
> > >> Jre17Compat
> > >>>
> > >>
> > >> s/Java 12+/Java 17+/, right ?
> > >>
> > >
> > > I mean: for any features that are only present in Java 12 to 17 that we
> > > would want to use in Tomcat, then they will all be implemented through
> > > reflection in a Jre17Compat class. Example, if UDS support is added, it
> > > will go into that class even though previously it would have been in
> > > Jre16Compat.
> > >
> > > Effectively, this drops guaranteed support for all Java non LTS
> releases
> > > except the most recent one, so you either have to use one of the LTS or
> > the
> > > most recent Java.
> >
> > I don't see a reason to restrict users in this way.
> >
> > If a feature is added in Java 9, why not put it in a Java9Compat class
> > and allow it to work on Java 9, 10, etc.? I realize that may add more
> > JavaXCompat classes but I really don't see a particular reason to
> > restrict or misrepresent Java versions.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: Compat versions

[Romain Manni-Bucau]

Hmm, a few thoughts on this topic:

1. there is no reason to use reflection in jrecompat (all the java > build
time version) impl can be generated in ant build using asm or bcel
2. all JreCompat are kind of hardcoded SPI, if this API gets a "ordinal" -
priority - and a "matches(int javaMajor)" then it becomes simple to pick
only the highest impl matching current java version (ie on java 8 it will
use the default, on java 12 it will use java12 or 11 or  8 impl, on
java 17 it will use java 17 impl etc).

So overall it is mainly about making the maintenance of the code easier but
not about dropping any feature or reducing support list IMHO.
Build time generation can help a lot with that (@Implement(spi =
JreCompat.class, since = 12) which would lead to jrecompat12, jrecompat13,
, jrecompatLast override of an impl for a method - being said playing
with inheritence between versions enables to drop duplication).
This kind of tool is not harder than the jakarta migration tool and can
solve that "fast pace" issue IMHO.
Requires some build/tool investment but it likely interesting to keep a
high support level for end user and reduce maintenance cost for tomcat
itself.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 18 déc. 2020 à 14:33, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Rémy,
>
> On 12/18/20 08:20, Rémy Maucherat wrote:
> > On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov 
> > wrote:
> >
> >> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'd like to refactor the compat classes to align with the LTS versions:
> >>> - Move Jre9Compat to Jre11Compat
> >>> - I'll probably refactor out GraalCompat
> >>> - For the upcoming Java 12+ features, they will all go to a new
> >> Jre17Compat
> >>>
> >>
> >> s/Java 12+/Java 17+/, right ?
> >>
> >
> > I mean: for any features that are only present in Java 12 to 17 that we
> > would want to use in Tomcat, then they will all be implemented through
> > reflection in a Jre17Compat class. Example, if UDS support is added, it
> > will go into that class even though previously it would have been in
> > Jre16Compat.
> >
> > Effectively, this drops guaranteed support for all Java non LTS releases
> > except the most recent one, so you either have to use one of the LTS or
> the
> > most recent Java.
>
> I don't see a reason to restrict users in this way.
>
> If a feature is added in Java 9, why not put it in a Java9Compat class
> and allow it to work on Java 9, 10, etc.? I realize that may add more
> JavaXCompat classes but I really don't see a particular reason to
> restrict or misrepresent Java versions.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Compat versions

[Christopher Schultz]

Rémy,

On 12/18/20 08:20, Rémy Maucherat wrote:

On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov 
wrote:


On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:


Hi,

I'd like to refactor the compat classes to align with the LTS versions:
- Move Jre9Compat to Jre11Compat
- I'll probably refactor out GraalCompat
- For the upcoming Java 12+ features, they will all go to a new

Jre17Compat




s/Java 12+/Java 17+/, right ?



I mean: for any features that are only present in Java 12 to 17 that we
would want to use in Tomcat, then they will all be implemented through
reflection in a Jre17Compat class. Example, if UDS support is added, it
will go into that class even though previously it would have been in
Jre16Compat.

Effectively, this drops guaranteed support for all Java non LTS releases
except the most recent one, so you either have to use one of the LTS or the
most recent Java.


I don't see a reason to restrict users in this way.

If a feature is added in Java 9, why not put it in a Java9Compat class 
and allow it to work on Java 9, 10, etc.? I realize that may add more 
JavaXCompat classes but I really don't see a particular reason to 
restrict or misrepresent Java versions.


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Compat versions

[Rémy Maucherat]

On Fri, Dec 18, 2020 at 12:19 PM Martin Grigorov 
wrote:

> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:
>
> > Hi,
> >
> > I'd like to refactor the compat classes to align with the LTS versions:
> > - Move Jre9Compat to Jre11Compat
> > - I'll probably refactor out GraalCompat
> > - For the upcoming Java 12+ features, they will all go to a new
> Jre17Compat
> >
>
> s/Java 12+/Java 17+/, right ?
>

I mean: for any features that are only present in Java 12 to 17 that we
would want to use in Tomcat, then they will all be implemented through
reflection in a Jre17Compat class. Example, if UDS support is added, it
will go into that class even though previously it would have been in
Jre16Compat.

Effectively, this drops guaranteed support for all Java non LTS releases
except the most recent one, so you either have to use one of the LTS or the
most recent Java.


>
>
> > class, which will actually be useable in the meantime by the latest Java
> > milestone release from which the interesting features come from
> >
> > Although not fully accurate, this is more maintainable as the interim non
> > LTS Java releases quickly come and go and are not good platforms for
> > Tomcat.
> >
>
> +1
>

Rémy

>
>
>
> >
> > Rémy
> >
>

Re: Compat versions

[Martin Grigorov]

On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:

> Hi,
>
> I'd like to refactor the compat classes to align with the LTS versions:
> - Move Jre9Compat to Jre11Compat
> - I'll probably refactor out GraalCompat
> - For the upcoming Java 12+ features, they will all go to a new Jre17Compat
>

s/Java 12+/Java 17+/, right ?


> class, which will actually be useable in the meantime by the latest Java
> milestone release from which the interesting features come from
>
> Although not fully accurate, this is more maintainable as the interim non
> LTS Java releases quickly come and go and are not good platforms for
> Tomcat.
>

+1



>
> Rémy
>

Compat versions

[Rémy Maucherat]

Hi,

I'd like to refactor the compat classes to align with the LTS versions:
- Move Jre9Compat to Jre11Compat
- I'll probably refactor out GraalCompat
- For the upcoming Java 12+ features, they will all go to a new Jre17Compat
class, which will actually be useable in the meantime by the latest Java
milestone release from which the interesting features come from

Although not fully accurate, this is more maintainable as the interim non
LTS Java releases quickly come and go and are not good platforms for Tomcat.

Rémy