On Sat, 10 Jun 2023 at 06:20, Guillaume Nodet <gno...@apache.org> wrote: > > I'd really like to > * use JEP 442 to get rid of the JNI and native libs in jline, jansi and > mvnd (but that's for JDK 21)
I understand your pain here. Temporary we are using that for Jetty. Even if a package such jdk.incubator.foreign is not directly exposed it will change its name in the future and potentially cause issues. But we needed it for http3 (and it's probably a feature not used so much) so better to wait maybe as stability in package name will not be before 21. > * use JEP 380 (unix domain sockets) to be able to cleanly implement > https://github.com/apache/maven-resolver/pull/269 why not reuse some Jetty code and not reinvent the wheel? if you want to avoid the pain of managing unix socket over jni you should be able to use jetty code as it will hide all of it. not sure about your use case though and if it's applicable. > * use some helper methods that have been added: List.of(), > Stream.toList(), Files.readString() to name just a few > * have syntactic sugar with text blocks, enhanced switches... that's perfectly understandable (but I'm not the person to convince here) > > The first one is out of reach in the very short term, but keeping JDK 8 for > ten more years would mean I'll never be able to get rid of those native > libs builds. I'm not very good at writing those libraries and supporting > various platforms is a real pain. The others can always be worked around, > as usual when you talk about upgrading to a more recent JDK, it's mostly > improvements and standardization, it's never really blocking as people have > long found workarounds if really needed. +1 > > Le ven. 9 juin 2023 à 10:58, Olivier Lamy <ol...@apache.org> a écrit : > > > this jdk discussion could be ended if someone could say we need jdk17 > > as a minimum because we really need this jdk feature. > > Frankly, I don’t care about being jdk17 minimum and I'm fine with that > > but what sort of feature do we really need? > > nobody prevents users from using 17 or 21 but on the other side if we > > can keep it lower to make a few people happy why not. > > because now reading the thread, it just looks makes 17 minimum because > > we will look more trendy I cannot see any really technical need for > > this. > > As I'm involved with Jetty I compare to it, we are now 17 minimum for > > jetty 12 because we really need the foreign memory API to use it and > > record because it’s really convenient. > > > > > > > > On Fri, 9 Jun 2023 at 03:01, Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > > > @Michael: the user base, both will give you an idea of java ecosystem for > > > coming projects and therefore can define a baseline which is not > > bothering > > > for our users. > > > > > > 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 jeu. 8 juin 2023 à 17:38, Michael Osipov <micha...@apache.org> a > > écrit : > > > > > > > I can concur to this with a user message: > > > > https://www.mail-archive.com/users@tomcat.apache.org/msg141662.html > > > > > > > > On 2023/06/08 09:51:45 Karl Heinz Marbaise wrote: > > > > > Hi to all, > > > > > > > > > > The most recent version of Tomcat 11.0.0-M7 has lifted it's JDK > > minimum > > > > > to JDK21 !!! > > > > > > > > > > > > > > > > https://tomcat.apache.org/tomcat-11.0-doc/changelog.html#Tomcat_11.0.0-M7_(markt) > > > > > > > > > > Kind regards > > > > > Karl Heinz Marbaise > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > ------------------------ > Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
