You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John Patrick <nh...@gmail.com> on 2021/03/20 11:27:19 UTC
Re: [exec][email] Java 7 to 8
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 <se...@gmail.com> wrote:
>
> On Sat, 21 Nov 2020 at 17:13, Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Sat, Nov 21, 2020 at 11:46 AM sebb <se...@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 <ga...@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [EXTERNAL] [exec][email] Java 7 to 8
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Oracle changed the license past Java8. Oracle Java is not free anymore. OpenJDK is though. So for anything later people have to move to AdoptOpenJDK. And company executives seem to be not sure about that move yet. Also the half year cadence leads to way less testing on a specific Java Version. Even if Java11 is LTS it does not see big adoption because it's only 'supported' by Oracle (main marketing) for half a year. Also while most of their Java Module changes in Java9..16 is nice for their internal decoupling it is often a major pita for downstream projects.
My personal guess is that Java17 (which is the next LTS) will see some adoption. With anything in between pretty much getting skipped, except where it really makes sense. e.g. Java Native Memory Access support for Apache Lucene, etc.
LieGrue,
strub
> Am 22.03.2021 um 19:46 schrieb Strauss, Randy (ARC-AF)[KBR Wyle Services, LLC] <ra...@nasa.gov.INVALID>:
>
>> 2018-11-29-F008-Back40.csv
>
> I work for NASA (as a contractor). It seems that for Macs, NASA, and perhaps all of the federal government, don't yet support anything past Java 8. I have no idea why...
> -r
> Randy Strauss
> Software Engr, SWS/UAM/UTM, NASA Ames Research Center
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [EXTERNAL] Re: [exec][email] Java 7 to 8
Posted by "Strauss, Randy (ARC-AF)[KBR Wyle Services, LLC]" <ra...@nasa.gov.INVALID>.
> 2018-11-29-F008-Back40.csv
I work for NASA (as a contractor). It seems that for Macs, NASA, and perhaps all of the federal government, don't yet support anything past Java 8. I have no idea why...
-r
Randy Strauss
Software Engr, SWS/UAM/UTM, NASA Ames Research Center
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [exec][email] Java 7 to 8
Posted by Gary Gregory <ga...@gmail.com>.
Thank you for the explainer Ralph :-)
Gary
On Sat, Mar 20, 2021, 13:27 Ralph Goers <ra...@dslextreme.com> wrote:
> 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 <ga...@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 <nh...@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 <se...@gmail.com> wrote:
> >>>
> >>> On Sat, 21 Nov 2020 at 17:13, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>>
> >>>> On Sat, Nov 21, 2020 at 11:46 AM sebb <se...@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 <ga...@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-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [exec][email] Java 7 to 8
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@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 <nh...@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 <se...@gmail.com> wrote:
>>>
>>> On Sat, 21 Nov 2020 at 17:13, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> On Sat, Nov 21, 2020 at 11:46 AM sebb <se...@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 <ga...@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [exec][email] Java 7 to 8
Posted by Siegfried Goeschl <si...@gmail.com>.
Hi folks,
I probably missed most of the fun here (overworked) but IMHO it makes sense to update both projects to JDK 8
A related question - someone volunteering as release manager? Having said that I can lend a hand for the code changes :)
Thanks in advance
Siegfried Goeschl
> On 29.03.2021, at 02:38, Matt Sicker <bo...@gmail.com> wrote:
>
> Calling it technical debt is pretty useful, too, because just like
> monetary debt, it can be useful to accumulate some in the short term
> for productive reasons, but if you don't pay it off and manage it
> properly, the interest payments begin to dominate expenses. Interest
> on technical debt comes in the form of what would normally be a five
> minute effort taking five months and three separate line managers to
> sign off on the budget to have it maybe deployed to production after
> the last 20 fires have been sufficiently extinguished. :)
>
> On Sun, 28 Mar 2021 at 17:09, Gary Gregory <ga...@gmail.com> wrote:
>>
>> WRT rant:
>> We call that "technical debt" and to move the needle on that developers are
>> (sometimes or always depending on you company) asked to explain the
>> "business value" for spending the time (IOW the money) to do so. At which
>> point said developers roll their eyes, pull their remaining hair out, or
>> both, before being asked to go another "death march"...
>>
>> Gary
>>
>>
>> On Sun, Mar 28, 2021, 16:18 Thomas Schapitz <ta...@online.de> wrote:
>>
>>>> If they are still on Java 6 or 7, then updating libraries might not be a
>>>> priority.
>>>>
>>>> Gary
>>>
>>>
>>> I second that.
>>>
>>> If an organization is still reluctant to upgrade at least to JDK 8, its
>>> rather unlikely that the same organization is urgently requiring to update
>>> to any latest commons release.
>>>
>>> And if they do in fact urgently require functionality, that is only
>>> available in a commons lib requiring JDK 8, it would be a nice incentive
>>> for finally considering an to upgrade at least to JDK 8.
>>>
>>> To me, Apache, especially commons, does a terrific job guarding BC, but in
>>> the end, trying to keep this up for the eternity will overstretch the
>>> communities resources, and it is breaking the stride.
>>>
>>> <RANT>On a more personal note: being 20+ years in the industry, I'm really
>>> fed up with organizations wanting me to build the newest, shiniest,
>>> fanciest crystal palaces of applications, while at the same time
>>> restricting me to use the tools from the stone age to achieve that, just
>>> because some oaf up there needs the money to upgrade the gadgets in his
>>> super yacht. You know, there is something wrong, when the model of the
>>> CEO's car is changing more frequently than the versions of your tools.
>>>
>>> Basically, an organization showing this behaviour is dumping their
>>> leniency as a debt into the community, so complaints about that shouldn't
>>> be taken too serious.
>>> </RANT>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: [exec][email] Java 7 to 8
Posted by Matt Sicker <bo...@gmail.com>.
Calling it technical debt is pretty useful, too, because just like
monetary debt, it can be useful to accumulate some in the short term
for productive reasons, but if you don't pay it off and manage it
properly, the interest payments begin to dominate expenses. Interest
on technical debt comes in the form of what would normally be a five
minute effort taking five months and three separate line managers to
sign off on the budget to have it maybe deployed to production after
the last 20 fires have been sufficiently extinguished. :)
On Sun, 28 Mar 2021 at 17:09, Gary Gregory <ga...@gmail.com> wrote:
>
> WRT rant:
> We call that "technical debt" and to move the needle on that developers are
> (sometimes or always depending on you company) asked to explain the
> "business value" for spending the time (IOW the money) to do so. At which
> point said developers roll their eyes, pull their remaining hair out, or
> both, before being asked to go another "death march"...
>
> Gary
>
>
> On Sun, Mar 28, 2021, 16:18 Thomas Schapitz <ta...@online.de> wrote:
>
> > > If they are still on Java 6 or 7, then updating libraries might not be a
> > > priority.
> > >
> > > Gary
> >
> >
> > I second that.
> >
> > If an organization is still reluctant to upgrade at least to JDK 8, its
> > rather unlikely that the same organization is urgently requiring to update
> > to any latest commons release.
> >
> > And if they do in fact urgently require functionality, that is only
> > available in a commons lib requiring JDK 8, it would be a nice incentive
> > for finally considering an to upgrade at least to JDK 8.
> >
> > To me, Apache, especially commons, does a terrific job guarding BC, but in
> > the end, trying to keep this up for the eternity will overstretch the
> > communities resources, and it is breaking the stride.
> >
> > <RANT>On a more personal note: being 20+ years in the industry, I'm really
> > fed up with organizations wanting me to build the newest, shiniest,
> > fanciest crystal palaces of applications, while at the same time
> > restricting me to use the tools from the stone age to achieve that, just
> > because some oaf up there needs the money to upgrade the gadgets in his
> > super yacht. You know, there is something wrong, when the model of the
> > CEO's car is changing more frequently than the versions of your tools.
> >
> > Basically, an organization showing this behaviour is dumping their
> > leniency as a debt into the community, so complaints about that shouldn't
> > be taken too serious.
> > </RANT>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: [exec][email] Java 7 to 8
Posted by Gary Gregory <ga...@gmail.com>.
WRT rant:
We call that "technical debt" and to move the needle on that developers are
(sometimes or always depending on you company) asked to explain the
"business value" for spending the time (IOW the money) to do so. At which
point said developers roll their eyes, pull their remaining hair out, or
both, before being asked to go another "death march"...
Gary
On Sun, Mar 28, 2021, 16:18 Thomas Schapitz <ta...@online.de> wrote:
> > If they are still on Java 6 or 7, then updating libraries might not be a
> > priority.
> >
> > Gary
>
>
> I second that.
>
> If an organization is still reluctant to upgrade at least to JDK 8, its
> rather unlikely that the same organization is urgently requiring to update
> to any latest commons release.
>
> And if they do in fact urgently require functionality, that is only
> available in a commons lib requiring JDK 8, it would be a nice incentive
> for finally considering an to upgrade at least to JDK 8.
>
> To me, Apache, especially commons, does a terrific job guarding BC, but in
> the end, trying to keep this up for the eternity will overstretch the
> communities resources, and it is breaking the stride.
>
> <RANT>On a more personal note: being 20+ years in the industry, I'm really
> fed up with organizations wanting me to build the newest, shiniest,
> fanciest crystal palaces of applications, while at the same time
> restricting me to use the tools from the stone age to achieve that, just
> because some oaf up there needs the money to upgrade the gadgets in his
> super yacht. You know, there is something wrong, when the model of the
> CEO's car is changing more frequently than the versions of your tools.
>
> Basically, an organization showing this behaviour is dumping their
> leniency as a debt into the community, so complaints about that shouldn't
> be taken too serious.
> </RANT>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Aw: Re: [exec][email] Java 7 to 8
Posted by Thomas Schapitz <ta...@online.de>.
> If they are still on Java 6 or 7, then updating libraries might not be a
> priority.
>
> Gary
I second that.
If an organization is still reluctant to upgrade at least to JDK 8, its rather unlikely that the same organization is urgently requiring to update to any latest commons release.
And if they do in fact urgently require functionality, that is only available in a commons lib requiring JDK 8, it would be a nice incentive for finally considering an to upgrade at least to JDK 8.
To me, Apache, especially commons, does a terrific job guarding BC, but in the end, trying to keep this up for the eternity will overstretch the communities resources, and it is breaking the stride.
<RANT>On a more personal note: being 20+ years in the industry, I'm really fed up with organizations wanting me to build the newest, shiniest, fanciest crystal palaces of applications, while at the same time restricting me to use the tools from the stone age to achieve that, just because some oaf up there needs the money to upgrade the gadgets in his super yacht. You know, there is something wrong, when the model of the CEO's car is changing more frequently than the versions of your tools.
Basically, an organization showing this behaviour is dumping their leniency as a debt into the community, so complaints about that shouldn't be taken too serious.
</RANT>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [exec][email] Java 7 to 8
Posted by Gary Gregory <ga...@gmail.com>.
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 <nh...@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 <se...@gmail.com> wrote:
> >
> > On Sat, 21 Nov 2020 at 17:13, Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > On Sat, Nov 21, 2020 at 11:46 AM sebb <se...@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 <ga...@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>