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 <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 > >
