+1 to release as-is and postpone POOL-355, then +1 to Java8 later too
CheersBruno
From: Gary Gregory <garydgreg...@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
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 <strub...@yahoo.de.invalid>
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 <ma...@apache.org>:
> >
> > 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: 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
>
>
