[pool] how to move to Java8?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[pool] how to move to Java8?

Mark Struberg-2
Hi folks!
I've worked through the open POOL tickets and found a few tickets which would like to enhance a few of our interfaces.
E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to the ObjectPool interface.
Now this would of course be a backward compatibility breaking change. If we would have java8 as minimum then we could easily just add a default method which returns -1. But since our min Java version is 1.7 we are doomed...
I would love to get the deadlock fixes out with the current 1.7 requirement first. Because that's important to get to the people (including my own customers).
But what after that?Would this justify a commons-pool-3.0?Do we also like to cleanup other stuff? Or should we just raise our min Java requirement to 1.8 and call it 2.7?
I'm totally fine either way and would love to get any feedback.

LieGrue,strub


Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

Romain Manni-Bucau
+1 to move to java 8, java 7 is more than outdated today even for legacy
systems

Le dim. 28 oct. 2018 12:10, Mark Struberg <[hidden email]> a
écrit :

> Hi folks!
> I've worked through the open POOL tickets and found a few tickets which
> would like to enhance a few of our interfaces.
> E.g. in POOL-355 we have a request to add a new method getMaxNumActive()
> to the ObjectPool interface.
> Now this would of course be a backward compatibility breaking change. If
> we would have java8 as minimum then we could easily just add a default
> method which returns -1. But since our min Java version is 1.7 we are
> doomed...
> I would love to get the deadlock fixes out with the current 1.7
> requirement first. Because that's important to get to the people (including
> my own customers).
> But what after that?Would this justify a commons-pool-3.0?Do we also like
> to cleanup other stuff? Or should we just raise our min Java requirement to
> 1.8 and call it 2.7?
> I'm totally fine either way and would love to get any feedback.
>
> LieGrue,strub
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

garydgregory
+1 for Java 8.

Gary

On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau <[hidden email]>
wrote:

> +1 to move to java 8, java 7 is more than outdated today even for legacy
> systems
>
> Le dim. 28 oct. 2018 12:10, Mark Struberg <[hidden email]> a
> écrit :
>
> > Hi folks!
> > I've worked through the open POOL tickets and found a few tickets which
> > would like to enhance a few of our interfaces.
> > E.g. in POOL-355 we have a request to add a new method getMaxNumActive()
> > to the ObjectPool interface.
> > Now this would of course be a backward compatibility breaking change. If
> > we would have java8 as minimum then we could easily just add a default
> > method which returns -1. But since our min Java version is 1.7 we are
> > doomed...
> > I would love to get the deadlock fixes out with the current 1.7
> > requirement first. Because that's important to get to the people
> (including
> > my own customers).
> > But what after that?Would this justify a commons-pool-3.0?Do we also like
> > to cleanup other stuff? Or should we just raise our min Java requirement
> to
> > 1.8 and call it 2.7?
> > I'm totally fine either way and would love to get any feedback.
> >
> > LieGrue,strub
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

garydgregory
Perhaps a path forward would be:
1) Release 2.6.1 now as is.
2) Update to Java 8 for 2.7.

I am OK with jumping to 2) over 1)

That would be up to the RM volunteering for this ;-)

Gary

On Sun, Oct 28, 2018 at 7:36 AM Gary Gregory <[hidden email]> wrote:

> +1 for Java 8.
>
> Gary
>
> On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> +1 to move to java 8, java 7 is more than outdated today even for legacy
>> systems
>>
>> Le dim. 28 oct. 2018 12:10, Mark Struberg <[hidden email]> a
>> écrit :
>>
>> > Hi folks!
>> > I've worked through the open POOL tickets and found a few tickets which
>> > would like to enhance a few of our interfaces.
>> > E.g. in POOL-355 we have a request to add a new method getMaxNumActive()
>> > to the ObjectPool interface.
>> > Now this would of course be a backward compatibility breaking change. If
>> > we would have java8 as minimum then we could easily just add a default
>> > method which returns -1. But since our min Java version is 1.7 we are
>> > doomed...
>> > I would love to get the deadlock fixes out with the current 1.7
>> > requirement first. Because that's important to get to the people
>> (including
>> > my own customers).
>> > But what after that?Would this justify a commons-pool-3.0?Do we also
>> like
>> > to cleanup other stuff? Or should we just raise our min Java
>> requirement to
>> > 1.8 and call it 2.7?
>> > I'm totally fine either way and would love to get any feedback.
>> >
>> > LieGrue,strub
>> >
>> >
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

Mark Thomas
In reply to this post by Mark Struberg-2
On 28/10/18 11:09, Mark Struberg wrote:
> Hi folks!
> I've worked through the open POOL tickets and found a few tickets which would like to enhance a few of our interfaces.
> E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to the ObjectPool interface.
> Now this would of course be a backward compatibility breaking change. If we would have java8 as minimum then we could easily just add a default method which returns -1. But since our min Java version is 1.7 we are doomed...
> I would love to get the deadlock fixes out with the current 1.7 requirement first. Because that's important to get to the people (including my own customers).
> But what after that?Would this justify a commons-pool-3.0?Do we also like to cleanup other stuff? Or should we just raise our min Java requirement to 1.8 and call it 2.7?
> I'm totally fine either way and would love to get any feedback.

Tomcat 8 (with a spec required minimum Java version of Java 7) is
currently using the latest version of pool. This version of Tomcat is
unlikely to be EOL until well into the 2020s. It would be easier if pool
stayed on Java 7 (since we maintain a package renamed copy of the code)
but I appreciate that that is not practical for pool for that timescale.

It isn't a huge amount of work to handle things like default methods.
The Tomcat community would certainly appreciate it if any Java 8
specific changes in Pool kept in mind that Tomcat will need to back-port
them to Java 7.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

Mark Struberg-2
I've went through the list and pretty much the only ticket which was left to really benefit from it would be the getMaxNumActive() (POOL-355).
But as noted there: after a bit of thinking through it I'm even tempted to close it as won't fix. Having just a bare maxNumActive doesn't give you much info in real production.
What you need is really a time graph with the currently active connections. You usually don't care about just a short spike e.g. because the underlying db gets restarted. What you care about is whether the connections are fine NOW and at which timeframe they have been in a bad shape.

If you (and others) could also take a look on this ticket them we could go on and close it. Which whould then remove the need for Java8.

That means I'm perfectly fine with keeping it java7 for now. Plus we also know what to take care of if we really need to bump to j8.

LieGrue,
strub


> Am 29.10.2018 um 09:35 schrieb Mark Thomas <[hidden email]>:
>
> On 28/10/18 11:09, Mark Struberg wrote:
>> Hi folks!
>> I've worked through the open POOL tickets and found a few tickets which would like to enhance a few of our interfaces.
>> E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to the ObjectPool interface.
>> Now this would of course be a backward compatibility breaking change. If we would have java8 as minimum then we could easily just add a default method which returns -1. But since our min Java version is 1.7 we are doomed...
>> I would love to get the deadlock fixes out with the current 1.7 requirement first. Because that's important to get to the people (including my own customers).
>> But what after that?Would this justify a commons-pool-3.0?Do we also like to cleanup other stuff? Or should we just raise our min Java requirement to 1.8 and call it 2.7?
>> I'm totally fine either way and would love to get any feedback.
>
> Tomcat 8 (with a spec required minimum Java version of Java 7) is
> currently using the latest version of pool. This version of Tomcat is
> unlikely to be EOL until well into the 2020s. It would be easier if pool
> stayed on Java 7 (since we maintain a package renamed copy of the code)
> but I appreciate that that is not practical for pool for that timescale.
>
> It isn't a huge amount of work to handle things like default methods.
> The Tomcat community would certainly appreciate it if any Java 8
> specific changes in Pool kept in mind that Tomcat will need to back-port
> them to Java 7.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

garydgregory
My view is to skip POOL-355 and release the current code still, on Java
7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear
since it seems changes.xml has not been updated for the commits over the
last week or two.

Gary

On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg <[hidden email]>
wrote:

> I've went through the list and pretty much the only ticket which was left
> to really benefit from it would be the getMaxNumActive() (POOL-355).
> But as noted there: after a bit of thinking through it I'm even tempted to
> close it as won't fix. Having just a bare maxNumActive doesn't give you
> much info in real production.
> What you need is really a time graph with the currently active
> connections. You usually don't care about just a short spike e.g. because
> the underlying db gets restarted. What you care about is whether the
> connections are fine NOW and at which timeframe they have been in a bad
> shape.
>
> If you (and others) could also take a look on this ticket them we could go
> on and close it. Which whould then remove the need for Java8.
>
> That means I'm perfectly fine with keeping it java7 for now. Plus we also
> know what to take care of if we really need to bump to j8.
>
> LieGrue,
> strub
>
>
> > Am 29.10.2018 um 09:35 schrieb Mark Thomas <[hidden email]>:
> >
> > On 28/10/18 11:09, Mark Struberg wrote:
> >> Hi folks!
> >> I've worked through the open POOL tickets and found a few tickets which
> would like to enhance a few of our interfaces.
> >> E.g. in POOL-355 we have a request to add a new method
> getMaxNumActive() to the ObjectPool interface.
> >> Now this would of course be a backward compatibility breaking change.
> If we would have java8 as minimum then we could easily just add a default
> method which returns -1. But since our min Java version is 1.7 we are
> doomed...
> >> I would love to get the deadlock fixes out with the current 1.7
> requirement first. Because that's important to get to the people (including
> my own customers).
> >> But what after that?Would this justify a commons-pool-3.0?Do we also
> like to cleanup other stuff? Or should we just raise our min Java
> requirement to 1.8 and call it 2.7?
> >> I'm totally fine either way and would love to get any feedback.
> >
> > Tomcat 8 (with a spec required minimum Java version of Java 7) is
> > currently using the latest version of pool. This version of Tomcat is
> > unlikely to be EOL until well into the 2020s. It would be easier if pool
> > stayed on Java 7 (since we maintain a package renamed copy of the code)
> > but I appreciate that that is not practical for pool for that timescale.
> >
> > It isn't a huge amount of work to handle things like default methods.
> > The Tomcat community would certainly appreciate it if any Java 8
> > specific changes in Pool kept in mind that Tomcat will need to back-port
> > them to Java 7.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

Mark Struberg-2
Yes, was not sure whether the changes.xml is generated or hand crafted.
Gonna add the missing bits.


LieGrue,
strub

> Am 29.10.2018 um 16:17 schrieb Gary Gregory <[hidden email]>:
>
> My view is to skip POOL-355 and release the current code still, on Java
> 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear
> since it seems changes.xml has not been updated for the commits over the
> last week or two.
>
> Gary
>
> On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg <[hidden email]>
> wrote:
>
>> I've went through the list and pretty much the only ticket which was left
>> to really benefit from it would be the getMaxNumActive() (POOL-355).
>> But as noted there: after a bit of thinking through it I'm even tempted to
>> close it as won't fix. Having just a bare maxNumActive doesn't give you
>> much info in real production.
>> What you need is really a time graph with the currently active
>> connections. You usually don't care about just a short spike e.g. because
>> the underlying db gets restarted. What you care about is whether the
>> connections are fine NOW and at which timeframe they have been in a bad
>> shape.
>>
>> If you (and others) could also take a look on this ticket them we could go
>> on and close it. Which whould then remove the need for Java8.
>>
>> That means I'm perfectly fine with keeping it java7 for now. Plus we also
>> know what to take care of if we really need to bump to j8.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 29.10.2018 um 09:35 schrieb Mark Thomas <[hidden email]>:
>>>
>>> On 28/10/18 11:09, Mark Struberg wrote:
>>>> Hi folks!
>>>> I've worked through the open POOL tickets and found a few tickets which
>> would like to enhance a few of our interfaces.
>>>> E.g. in POOL-355 we have a request to add a new method
>> getMaxNumActive() to the ObjectPool interface.
>>>> Now this would of course be a backward compatibility breaking change.
>> If we would have java8 as minimum then we could easily just add a default
>> method which returns -1. But since our min Java version is 1.7 we are
>> doomed...
>>>> I would love to get the deadlock fixes out with the current 1.7
>> requirement first. Because that's important to get to the people (including
>> my own customers).
>>>> But what after that?Would this justify a commons-pool-3.0?Do we also
>> like to cleanup other stuff? Or should we just raise our min Java
>> requirement to 1.8 and call it 2.7?
>>>> I'm totally fine either way and would love to get any feedback.
>>>
>>> Tomcat 8 (with a spec required minimum Java version of Java 7) is
>>> currently using the latest version of pool. This version of Tomcat is
>>> unlikely to be EOL until well into the 2020s. It would be easier if pool
>>> stayed on Java 7 (since we maintain a package renamed copy of the code)
>>> but I appreciate that that is not practical for pool for that timescale.
>>>
>>> It isn't a huge amount of work to handle things like default methods.
>>> The Tomcat community would certainly appreciate it if any Java 8
>>> specific changes in Pool kept in mind that Tomcat will need to back-port
>>> them to Java 7.
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

garydgregory
changes.xml is hand crafted and used to generate parts of the site.

Gary

On Mon, Oct 29, 2018 at 9:26 AM Mark Struberg <[hidden email]>
wrote:

> Yes, was not sure whether the changes.xml is generated or hand crafted.
> Gonna add the missing bits.
>
>
> LieGrue,
> strub
>
> > Am 29.10.2018 um 16:17 schrieb Gary Gregory <[hidden email]>:
> >
> > My view is to skip POOL-355 and release the current code still, on Java
> > 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear
> > since it seems changes.xml has not been updated for the commits over the
> > last week or two.
> >
> > Gary
> >
> > On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg <[hidden email]
> >
> > wrote:
> >
> >> I've went through the list and pretty much the only ticket which was
> left
> >> to really benefit from it would be the getMaxNumActive() (POOL-355).
> >> But as noted there: after a bit of thinking through it I'm even tempted
> to
> >> close it as won't fix. Having just a bare maxNumActive doesn't give you
> >> much info in real production.
> >> What you need is really a time graph with the currently active
> >> connections. You usually don't care about just a short spike e.g.
> because
> >> the underlying db gets restarted. What you care about is whether the
> >> connections are fine NOW and at which timeframe they have been in a bad
> >> shape.
> >>
> >> If you (and others) could also take a look on this ticket them we could
> go
> >> on and close it. Which whould then remove the need for Java8.
> >>
> >> That means I'm perfectly fine with keeping it java7 for now. Plus we
> also
> >> know what to take care of if we really need to bump to j8.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 29.10.2018 um 09:35 schrieb Mark Thomas <[hidden email]>:
> >>>
> >>> On 28/10/18 11:09, Mark Struberg wrote:
> >>>> Hi folks!
> >>>> I've worked through the open POOL tickets and found a few tickets
> which
> >> would like to enhance a few of our interfaces.
> >>>> E.g. in POOL-355 we have a request to add a new method
> >> getMaxNumActive() to the ObjectPool interface.
> >>>> Now this would of course be a backward compatibility breaking change.
> >> If we would have java8 as minimum then we could easily just add a
> default
> >> method which returns -1. But since our min Java version is 1.7 we are
> >> doomed...
> >>>> I would love to get the deadlock fixes out with the current 1.7
> >> requirement first. Because that's important to get to the people
> (including
> >> my own customers).
> >>>> But what after that?Would this justify a commons-pool-3.0?Do we also
> >> like to cleanup other stuff? Or should we just raise our min Java
> >> requirement to 1.8 and call it 2.7?
> >>>> I'm totally fine either way and would love to get any feedback.
> >>>
> >>> Tomcat 8 (with a spec required minimum Java version of Java 7) is
> >>> currently using the latest version of pool. This version of Tomcat is
> >>> unlikely to be EOL until well into the 2020s. It would be easier if
> pool
> >>> stayed on Java 7 (since we maintain a package renamed copy of the code)
> >>> but I appreciate that that is not practical for pool for that
> timescale.
> >>>
> >>> It isn't a huge amount of work to handle things like default methods.
> >>> The Tomcat community would certainly appreciate it if any Java 8
> >>> specific changes in Pool kept in mind that Tomcat will need to
> back-port
> >>> them to Java 7.
> >>>
> >>> Mark
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

Matt Sicker
I'm fine with sticking with Java 7 for Tomcat as long as the Jenkins build
continues to work properly. Keep an eye on the JDKs available! ;)

On Mon, 29 Oct 2018 at 10:28, Gary Gregory <[hidden email]> wrote:

> changes.xml is hand crafted and used to generate parts of the site.
>
> Gary
>
> On Mon, Oct 29, 2018 at 9:26 AM Mark Struberg <[hidden email]>
> wrote:
>
> > Yes, was not sure whether the changes.xml is generated or hand crafted.
> > Gonna add the missing bits.
> >
> >
> > LieGrue,
> > strub
> >
> > > Am 29.10.2018 um 16:17 schrieb Gary Gregory <[hidden email]>:
> > >
> > > My view is to skip POOL-355 and release the current code still, on Java
> > > 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not
> clear
> > > since it seems changes.xml has not been updated for the commits over
> the
> > > last week or two.
> > >
> > > Gary
> > >
> > > On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg
> <[hidden email]
> > >
> > > wrote:
> > >
> > >> I've went through the list and pretty much the only ticket which was
> > left
> > >> to really benefit from it would be the getMaxNumActive() (POOL-355).
> > >> But as noted there: after a bit of thinking through it I'm even
> tempted
> > to
> > >> close it as won't fix. Having just a bare maxNumActive doesn't give
> you
> > >> much info in real production.
> > >> What you need is really a time graph with the currently active
> > >> connections. You usually don't care about just a short spike e.g.
> > because
> > >> the underlying db gets restarted. What you care about is whether the
> > >> connections are fine NOW and at which timeframe they have been in a
> bad
> > >> shape.
> > >>
> > >> If you (and others) could also take a look on this ticket them we
> could
> > go
> > >> on and close it. Which whould then remove the need for Java8.
> > >>
> > >> That means I'm perfectly fine with keeping it java7 for now. Plus we
> > also
> > >> know what to take care of if we really need to bump to j8.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>> Am 29.10.2018 um 09:35 schrieb Mark Thomas <[hidden email]>:
> > >>>
> > >>> On 28/10/18 11:09, Mark Struberg wrote:
> > >>>> Hi folks!
> > >>>> I've worked through the open POOL tickets and found a few tickets
> > which
> > >> would like to enhance a few of our interfaces.
> > >>>> E.g. in POOL-355 we have a request to add a new method
> > >> getMaxNumActive() to the ObjectPool interface.
> > >>>> Now this would of course be a backward compatibility breaking
> change.
> > >> If we would have java8 as minimum then we could easily just add a
> > default
> > >> method which returns -1. But since our min Java version is 1.7 we are
> > >> doomed...
> > >>>> I would love to get the deadlock fixes out with the current 1.7
> > >> requirement first. Because that's important to get to the people
> > (including
> > >> my own customers).
> > >>>> But what after that?Would this justify a commons-pool-3.0?Do we also
> > >> like to cleanup other stuff? Or should we just raise our min Java
> > >> requirement to 1.8 and call it 2.7?
> > >>>> I'm totally fine either way and would love to get any feedback.
> > >>>
> > >>> Tomcat 8 (with a spec required minimum Java version of Java 7) is
> > >>> currently using the latest version of pool. This version of Tomcat is
> > >>> unlikely to be EOL until well into the 2020s. It would be easier if
> > pool
> > >>> stayed on Java 7 (since we maintain a package renamed copy of the
> code)
> > >>> but I appreciate that that is not practical for pool for that
> > timescale.
> > >>>
> > >>> It isn't a huge amount of work to handle things like default methods.
> > >>> The Tomcat community would certainly appreciate it if any Java 8
> > >>> specific changes in Pool kept in mind that Tomcat will need to
> > back-port
> > >>> them to Java 7.
> > >>>
> > >>> Mark
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: [hidden email]
> > >>> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] how to move to Java8?

Bruno P. Kinoshita-3
In reply to this post by garydgregory
+1 to release as-is and postpone POOL-355, then +1 to Java8 later too
CheersBruno

      From: Gary Gregory <[hidden email]>
 To: Commons Developers List <[hidden email]>
 Sent: Tuesday, 30 October 2018 4:17 AM
 Subject: Re: [pool] how to move to Java8?
   
My view is to skip POOL-355 and release the current code still, on Java
7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear
since it seems changes.xml has not been updated for the commits over the
last week or two.

Gary

On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg <[hidden email]>
wrote:

> I've went through the list and pretty much the only ticket which was left
> to really benefit from it would be the getMaxNumActive() (POOL-355).
> But as noted there: after a bit of thinking through it I'm even tempted to
> close it as won't fix. Having just a bare maxNumActive doesn't give you
> much info in real production.
> What you need is really a time graph with the currently active
> connections. You usually don't care about just a short spike e.g. because
> the underlying db gets restarted. What you care about is whether the
> connections are fine NOW and at which timeframe they have been in a bad
> shape.
>
> If you (and others) could also take a look on this ticket them we could go
> on and close it. Which whould then remove the need for Java8.
>
> That means I'm perfectly fine with keeping it java7 for now. Plus we also
> know what to take care of if we really need to bump to j8.
>
> LieGrue,
> strub
>
>
> > Am 29.10.2018 um 09:35 schrieb Mark Thomas <[hidden email]>:
> >
> > On 28/10/18 11:09, Mark Struberg wrote:
> >> Hi folks!
> >> I've worked through the open POOL tickets and found a few tickets which
> would like to enhance a few of our interfaces.
> >> E.g. in POOL-355 we have a request to add a new method
> getMaxNumActive() to the ObjectPool interface.
> >> Now this would of course be a backward compatibility breaking change.
> If we would have java8 as minimum then we could easily just add a default
> method which returns -1. But since our min Java version is 1.7 we are
> doomed...
> >> I would love to get the deadlock fixes out with the current 1.7
> requirement first. Because that's important to get to the people (including
> my own customers).
> >> But what after that?Would this justify a commons-pool-3.0?Do we also
> like to cleanup other stuff? Or should we just raise our min Java
> requirement to 1.8 and call it 2.7?
> >> I'm totally fine either way and would love to get any feedback.
> >
> > Tomcat 8 (with a spec required minimum Java version of Java 7) is
> > currently using the latest version of pool. This version of Tomcat is
> > unlikely to be EOL until well into the 2020s. It would be easier if pool
> > stayed on Java 7 (since we maintain a package renamed copy of the code)
> > but I appreciate that that is not practical for pool for that timescale.
> >
> > It isn't a huge amount of work to handle things like default methods.
> > The Tomcat community would certainly appreciate it if any Java 8
> > specific changes in Pool kept in mind that Tomcat will need to back-port
> > them to Java 7.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>