On Tue, Dec 13, 2011 at 7:01 AM, sebb <seb...@gmail.com> wrote: > On 13 December 2011 11:36, Simone Tripodi <simonetrip...@apache.org> > wrote: > >> > >> Generics would help to ensure suitable types were being used, but> > would do nothing to prevent the subtle threading bugs that misusing a> > protected field can cause.>> To my mind, it would paper over a few cracks, > whilst leaving gaping> holes elsewhere.> > > we just voted a new maintenance release for [pool] that brings exactly > > the same bugs, what should prevent us cutting a new release adding > > something comfortable for our users - and some of us, included myself > > - such as generics? > > > >> Unfortunately, because the original code was created with exposed> > mutable data items, it's just not possible to fix it without breaking> > binary compatibility. > > > > agreed, maybe I got Gary wrong but IIUC the purpose for a 1.6 release > > is just providing Generics... or not? > > 2.0 provides a lot more - not only locks are fixed, but internals are > > more performant - so I don't see issues having 1.6 released. > > But what is the point? >
The point is I really want an easy path to generics now, with as much compatibility as possible, including 1.5 warts and all. I want to clean up my [pool] call sites ASAP. It's one of the rare key spots in my app that does not support generics. We have all this nice generified code except when hitting the [pool] edges, that's ugly, unsafe, and unnecessary. I also do not want the risks that come with a whole new [pool2] impl. Do generics really make enough difference to be worth spending the time on? > I started this thread for a reason :) > > Note also that Pool 1.x currently targets 1.3, so adding generics will > force source compliance of at least 1.5. > Well, yes, that's not a surprise, compiling generics requires J1.5. If someone cares to maintain a Java 1.3-compliant branch, be my guest. > Not sure if it will force target compliance of 1.5 as well. If so, it > might no longer be a drop-in replacement for some isers. > True, and worse for compilation, if you do very odd things with pools, your call sites might not compile. But that would be true of any new lib that adds generics. Once you declare a pool with a type, you can't just shove any old Object in there anymore. My proposed plan is to migrate the 1.x branch to generics (done on my machine, like Simo, it's not the first time its been done ;) If someone want to release a 1.5.x release after 1.6, create a 1.5.x branch from the last 1.5.x tag. Doing another 1.5.x would mean that person want J1.3 compatibility, and does not care for J1.5. At work, we have been on J1.6 for years and are now experimenting with J1.7. I know some people like in a pre-J1.6 world, and no one is forcing anyone to upgrade. I do not care to rehash the 'when is it OK to use Java 5-6' debate. As I mentioned, [pool2] can cook all it needs until it is fully baked as far as I am concerned. If this causes people to rekindle their [pool2] efforts, then I'm happy this provided the catalyst. Gary > > My 0.02 cents, > > -Simo > > > > http://people.apache.org/~simonetripodi/ > > http://simonetripodi.livejournal.com/ > > http://twitter.com/simonetripodi > > http://www.99soft.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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
