We just concluded this same discussion for Log4j. I looked at the JRebel 2021 report [1] to gauge the number of people using a particular Java version. Respondents were able to select multiple versions so the numbers don’t add up to 100%.
Java 7 or older. 15% Java 8 69% Java 11 36% Java 12 or newer 16% Jetbrains [2] has a 2020 survey. Since it is from last year you can be sure that the numbers for older versions have decreased somewhat. Java 6 3% Java 7. 7% Java 8. 75% Java 9. 6% Java 10. 6% Java 11. 32% Java 12. 10% Java 13. 14% Snyk is still conducting their 2021 survey but their 2020 numbers [3] had Java 7 or older 3% Java 8. 64% Java 9. 2% Java 10. 2% Java 11 25% Java 12 4% Take these numbers for whatever they are worth. The questions I would ask are: 1. Why would customers using older virtually unsupported Java versions care about new features? Remember that Oracle’s paid support for Java 7 won’t include anything but critical security patches at this point. Java 6 is no longer supported at all. 2. If you want to continue to support older versions why can’t you just branch from the last version that supported an older Java version and create whatever bug fixes are required there. To be clear, that is what we did for Java 6 and 7 with Log4j. We never had a single request for a bug fix for those older releases. We finally just voted to drop support for Java 6 & 7. Ralph [1] https://www.jrebel.com/blog/2021-java-technology-report [2[ https://www.jetbrains.com/lp/devecosystem-2020/java/ [3] https://snyk.io/blog/developers-dont-want-to-leave-java-8-as-64-hold-firm-on-their-preferred-release/ > On Mar 20, 2021, at 4:55 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > They choose to update not, no one forces updates magically, unless you > always pick up the latest by not specifying a version in a POM (bad > practice). > > If they are still on Java 6 or 7, then updating libraries might not be a > priority. > > Gary > > On Sat, Mar 20, 2021, 07:27 John Patrick <nhoj.patr...@gmail.com> wrote: > >> Some customers might need to use Java 7, but what about the customers >> who want to use it on Java 17 which will be in rampdown in 5 months >> and released in 6 months? >> Also from memory from conferences ~ 2018/2019 I thought Java 17 was >> planning on removing the Classpath so everything needed to be Modules >> as well as raising the support min Java version to 8 or maybe even 11. >> >> Also I understand that some customers might still be running Java 6 or >> 7 or 8, but would they be actively upgrading to newer versions and if >> they have not found any bugs in the current version in the past ~10 >> years will they find any new ones in next 16 months... >> >> On Sat, 21 Nov 2020 at 22:48, sebb <seb...@gmail.com> wrote: >>> >>> On Sat, 21 Nov 2020 at 17:13, Gary Gregory <garydgreg...@gmail.com> >> wrote: >>>> >>>> On Sat, Nov 21, 2020 at 11:46 AM sebb <seb...@gmail.com> wrote: >>>> >>>>> Note that Java 7 and later are all on lndefinite Sustaining Support: >>>>> >>>>> >> https://www.oracle.com/java/technologies/java-se-support-roadmap.html >>>>> >>>>> This is presumably because there are customers who need Java 7. >>>>> >>>> >>>> And those paying Oracle customers are welcome to NOT upgrade to new >>>> versions or provide PRs and request releases. >>> >>> It's not just paying customers: >>> >>> "The Extended Support fee will be waived for the period June 2019 - >>> July 2022 for Java SE 7." >>> >>> I don't see any pressing need to move to Java 8. >>> >>>> Gary >>>> >>>> >>>>> >>>>> On Sat, 21 Nov 2020 at 16:18, Gary Gregory <garydgreg...@gmail.com> >> wrote: >>>>>> >>>>>> I do not see a reason to maintain EXEC and EMAIL on Java 7 at this >> point, >>>>>> it's simpler to maintain Commons builds locally, on GitHub >> Actions, and >>>>>> Travis CI by using Java 8. >>>>>> >>>>>> FYI, DAEMON is still on Java 6, presumably to support Tomcat. I >> will >>>>> start >>>>>> a separate thread about that, just to check status. >>>>>> >>>>>> Gary >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
