On Fri, Dec 18, 2020 at 2:56 PM Romain Manni-Bucau <rmannibu...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | 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 <mgrigo...@apache.org > > > > > wrote: > > > > > >> On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat <r...@apache.org> > > 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 > > > > >
