commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [pool] 1.6 proposal
Date Tue, 13 Dec 2011 14:10:26 GMT
On Tue, Dec 13, 2011 at 8:22 AM, Phil Steitz <phil.steitz@gmail.com> wrote:

> Lots of applications depend on the 1.x branch as it is now.


Hello,

What does it mean for an app to depend on a specific branch in SVN?

Do those apps depend on 1.x SNAPSHOT releases? Do they download the code
and compile it? Which is where moving to J1.5 be a problem? How can such a
thing even be supported?


> We really can't just drop support.


I am not asking to drop support. Anyone one can do as they please to
support whatever version they want. If I want to stay on J1.3 and fix the
P1.5.x line, I can do so.

Generics is the natural evolution of the P1.x line from P1.5 to a P1.6. I'm
not interested in J1.3, so I'm not going to support it. I am interested in
generics now, so I am supporting it now. If there were no P1.6, then yes,
I'd fix P1.5 because that would be the only game in town.


> At least we shouldnt, IMO.  What you are proposing is a third release
> line.


There is no need for a third release line until someone needs it and does
the work. If I am stuck on pre-J1.5 and I want a 1.5.x, I create that
release, if that means I have to create a branch, then that's what I have
to do to support an obsolete J1.3 platform.


> As I have stated before, we are having a hard time getting timely bug fix
> releases out now with just *one* release line.   Are you prepared to
> support the code fully? Are there other volunteers willing to step up to
> diagnose and fix bugs in two versions of the 1.x branch?
>

Right now, I'm doing the best I can do for [pool1] and generics. I'll
support the code the same way I support any Commons code, when I take the
time to do so. If P1.6 is as simple as /only/ adding generics, then I
predict we'll see a good adoption rate.

Gary


>
> Phil
>
>
>
> On Dec 13, 2011, at 6:11 AM, Gary Gregory <garydgregory@gmail.com> wrote:
>
> > On Tue, Dec 13, 2011 at 7:01 AM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 13 December 2011 11:36, Simone Tripodi <simonetripodi@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message