git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pool] how to move to Java8?


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 <garydgregory@xxxxxxxxx>:
> 
> 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 <struberg@xxxxxxxx.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 <markt@xxxxxxxxxx>:
>>> 
>>> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx