Usually when projects dump Java 8 support, they is a strong reason. I don't see any here. * I am not aware of any dependency that we rely on that has fixes that we can't uptake if we stick to Java 8 - ie the projects still publish Java 8 friendly releases even if they have higher version releases that don't support Java 8 * I am not aware of any major Java runtime features that we need to uptake that are not in Java 8 * For me, there is a better solution to optimising support for newer Java versions while still supporting older Java versions - Multi Release Jars [1] * The POI build support for module-info classes is pretty stable and for me is far from the most complicated part of the build - I, personally, have much more a problem with the build time wasted on poi-ooxml-full, the complexity of poi-ooxml-lite and poi-integration - and the fact that we can't automate our releases because of this complexity. I have given up bringing up discussions about such items due to general lack of engagement with the dev mailing list. * We have other Apache projects like Tika, Drill and Linkis that use POI and some of those still apps still use Java 8 builds. We have 1000s of other projects that depend on us - eg [2] * If you look at Stackoverflow or our mailing lists, there is a large number of users who are using old POI versions and I think we need to avoid making it harder for those users to upgrade. Java 8 still gets regular security patches and depending on what you read, as many as 30% of Java users still use Java 8 (eg [3[).
[1] https://openjdk.org/jeps/238 [2] https://mvnrepository.com/artifact/org.apache.poi/poi-ooxml/usages [3[ https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem On 2024/02/19 23:00:32 stanton fisque wrote: > something to consider, which kind of gathers a few of the opinions that have > been discussed, maybe in a different light. > > POI is in an odd situation because it is BOTH a consumer of dependencies, and > IS also a dependency, since it is a library and not a stand-alone product. > > as a consumer of dependencies, it should be partial to keeping pace with what > it consumes. it would be a big dis-service if POI lagged behind on its > dependencies and ended up getting dinged for a CERT or other security issue > and not be able to mitigate it due to being incompatible with newer versions > of its dependencies. > > though, on the other side, POI should not be too aggressive since it is > consumed by so many other products "out in the wild". > > i think a java-11 requirement would suffice for now. > > i do not know if i am eligible (my tacit assumption is no, atm) to offer a > +1, but if i could, i would. > > > Stanton Fisque > principal technologist > latticeware.com > portland, oregon > > > On Feb 19, 2024, at 10:54 AM, Alain FAGOT BÉAREZ <abea...@for-scala.it> > > wrote: > > > > Hi, > > > > +1 for moving to Java 11 as minimum > > > > My opinion is that we should jump to the oldest LTS version each time one > > LTS reached its end of life. This means that we would jump from 8 to 17 at > > once... Which is also not so friendly to be done right now! > > > > Kind regards, > > Alain FAGOT BÉAREZ > > > > > > > > > > Obter o BlueMail para Android > > > > Em 17 de fev de 2024 09:39, em 09:39, Dominik Stadler > > <dominik.stad...@gmx.at.invalid> escreveu: > >> Hi, > >> > >> What do others thing? > >> > >> We currently are at +2/-1 for moving to Java 11 minimum. > >> > >> Would be good if we get a more significant number of votes for this. > >> > >> Thanks... Dominik. > >> > >> > >> On Sat, Feb 3, 2024 at 10:04 PM Axel Howind <a...@dua3.com> wrote: > >> > >>> Hi, > >>> > >>> for whatever reason I cannot reach both the Nabble and MarkMail > >> archives > >>> to check if this has been discussed before, but I think it would be a > >> good > >>> idea to bump the minimum Java version for POI 5 to 11. I’d also be ok > >> (or > >>> rather like) 17. What do you think? > >>> > >>> Cheers, > >>> Axel > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >>> For additional commands, e-mail: dev-h...@poi.apache.org > >>> > >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
