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
