git.net

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

Re: [pool] how to move to Java8?


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 <struberg@xxxxxxxx.invalid>
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 <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
>
>