Re: [pool] how to move to Java8?
+1 to release as-is and postpone POOL-355, then +1 to Java8 later too CheersBruno From: Gary Gregory To: Commons Developers List 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 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 : > > > > 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 > >
Re: [pool] how to move to Java8?
I'm fine with sticking with Java 7 for Tomcat as long as the Jenkins build continues to work properly. Keep an eye on the JDKs available! ;) On Mon, 29 Oct 2018 at 10:28, Gary Gregory wrote: > 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 > 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 : > > > > > > 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 > > > > > > 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 : > > >>> > > >>> 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 > > >> > > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
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 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 : > > > > 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 > > > 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 : > >>> > >>> 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 > >> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
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 : > > 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 > 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 : >>> >>> 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 >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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 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 : > > > > 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 > >
Re: [pool] how to move to Java8?
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 : > > 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
Re: [pool] how to move to Java8?
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
Re: [pool] how to move to Java8?
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 wrote: > +1 for Java 8. > > Gary > > On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau > 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 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 >> > >> > >> > >> >
Re: [pool] how to move to Java8?
+1 for Java 8. Gary On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau 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 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 > > > > > > >
Re: [pool] how to move to Java8?
+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 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 > > >
[pool] how to move to Java8?
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
