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 <garydgreg...@gmail.com> wrote: > +1 for Java 8. > > Gary > > On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau <rmannibu...@gmail.com> > 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 <strub...@yahoo.de.invalid> 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 >> > >> > >> > >> >
