On 9/2/13 3:30 PM, James Carman wrote: > I get both sides of the argument. I just know how I feel when I see > an NPE. It's probably more of a psychological thing for me, I guess. > I just prefer IAE in these cases.
I do as well. The key for me is Gary's point about activation site - where exactly the exception is triggered. If it is detected at an API boundary, then IAE makes sense to me. I like (where practical) to document null handling in API documentation and if the documentation says nulls are not allowed, throw IAE. I don't like the "just let the runtime go boom" approach when I can avoid it. As a user, I would much rather see an IAE where a (documented) null check failed than an NPE bubbling up from the bowels of some impl that I don't know anything about. An analogous case that may not convince anyone is to consider ArrayIndexOutOfBoundsException triggered when an API is given bad array indices. There as well, I would see a) failfast better and b) IAE thrown instead of AIOOBE. All that said, we more or less agreed on a different approach for [math] [1], so I understand above may be a minority view. Phil [1] http://markmail.org/message/cl2e6c4pqbluo63e > > On Mon, Sep 2, 2013 at 3:27 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> To continue to play devil's advocate, when one validates that an argument >> is not null, doesn't this signify that in the absence of such validation, >> NPE is what would be thrown anyway? Arguably throwing NPE from >> Validate#notNull() simply allows the API designer to explicitly address >> this and optionally provide a more detailed exception message in the >> process. >> >> Matt >> >> >> On Mon, Sep 2, 2013 at 1:46 PM, James Carman >> <ja...@carmanconsulting.com>wrote: >> >>> I think Emmanuel Bourg was the only one actually advocating NPE (or >>> asking if it's what should be used). I brought up the fact that >>> [lang] uses NPE merely as a discussion point. I don't agree with the >>> NPE usage for Validate.notNull() (sorry I was not more clear on that >>> opinion). I would rather have all of Validate's methods throw IAE for >>> consistency. As far as this case is concerned, the only thing you >>> would have to worry about would be a veto from someone, and since >>> Emmanuel was the only dissenting voice, perhaps he would want to weigh >>> in at this point. Emmanuel? >>> >>> I don't know if I would agree that Bloch has "codified this >>> expectation into the minds of developers." I've been developing in >>> Java for a long time and when I see a NPE, I immediately think this >>> results from an attempt to dereference a null reference. Judging from >>> the discussion here, I would think others feel the same way. >>> >>> On Mon, Sep 2, 2013 at 1:49 PM, Benedikt Ritter <benerit...@gmail.com> >>> wrote: >>>> Hey, >>>> >>>> sorry if I missunderstood your opinions (Gary and James). >>>> So do we call for a [VOTE]? I've never seen a vote thread for design >>>> related decisions so far. >>>> >>>> Benedikt >>>> >>>> >>>> 2013/9/2 James Carman <ja...@carmanconsulting.com> >>>> >>>>> I meant re-visit the decision to make sure we took everything into >>>>> consideration when choosing which way to go in this case. I say we >>>>> leave [lang] alone at this point. >>>>> >>>>> >>>>> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gudnabr...@gmail.com> >>> wrote: >>>>>> How do you mean, "revisit?" I think changing [lang] at this late date >>>>> would >>>>>> be more trouble than it's worth. >>>>>> >>>>>> Matt >>>>>> On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com> >>>>> wrote: >>>>>>> I favor IAE, but I want to make sure we re-visit the decision made >>> for >>>>>>> [lang] when it chose to use NPE instead. >>>>>>> >>>>>>> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <garydgreg...@gmail.com >>>>>>> wrote: >>>>>>>> It feels to me that this misrepresents the ideas expressed here, >>> or at >>>>>>>> least mine ;) I am neither indifferent or favor NPE. I favor IAE, >>> so >>>>>>>> does that mean I am nor "most people". If a person make these >>> kinds of >>>>>>>> statement, we might as well VOTE or argue-discuss some more...! >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> On Sep 1, 2013, at 10:46, Benedikt Ritter <brit...@apache.org> >>> wrote: >>>>>>>>> Look's like most people are either indifferent or favor NPE. So, >>> do >>>>> we >>>>>>>>> change this for [CSV]? The important thing is to give users an >>>>>>> expressive >>>>>>>>> message. >>>>>>>>> >>>>>>>>> Benedikt >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/8/30 Gary Gregory <garydgreg...@gmail.com> >>>>>>>>> >>>>>>>>>> Surprisingly, a lot. At work, we have a lot of >>>>> frameworky/plugin-type >>>>>>> of >>>>>>>>>> code where we run operations on collections of things and we do >>> not >>>>>>> want >>>>>>>>>> "expected" errors to torpedo the whole processing flow, so we do >>>>> catch >>>>>>>>>> things like IAE and ISE. We do try to avoid catching Exception >>> if we >>>>>>> can >>>>>>>>>> help it. >>>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson < >>> gudnabr...@gmail.com> >>>>>>> wrote: >>>>>>>>>>> How often do you really want to catch these? >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory < >>>>> garydgreg...@gmail.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> Another perspective to think about is whether you want to write >>>>> code >>>>>>>>>>> like: >>>>>>>>>>>> try { >>>>>>>>>>>> // la-di-da >>>>>>>>>>>> } catch (NullPointerException e) { >>>>>>>>>>>> // garbage in! >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> or: >>>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>>> // doo-wap-doo-wap >>>>>>>>>>>> } catch (IllegalArugumentException e) { >>>>>>>>>>>> // garbage in! >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Catching NPE just smells funny to me. >>>>>>>>>>>> >>>>>>>>>>>> Gary >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <seb...@gmail.com> >>> wrote: >>>>>>>>>>>>> The fact that NPE is documented in Bloch is quite important. >>>>>>>>>>>>> >>>>>>>>>>>>> Whatever we do choose, we should make sure to document all th >>>>>>> reasons >>>>>>>>>>>>> (pros and cons) somewhere other than just the mailing list! >>>>>>>>>>>>> >>>>>>>>>>>>> On 30 August 2013 17:30, Matt Benson <gudnabr...@gmail.com> >>>>> wrote: >>>>>>>>>>>>>> The discussion for [lang], none of whose participants have >>>>> weighed >>>>>>>>>> in >>>>>>>>>>>>> here, >>>>>>>>>>>>>> took place in late 2009 (so perhaps a little longer ago than >>> I >>>>>>>>>>> thought) >>>>>>>>>>>>> and >>>>>>>>>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling >>>>>>>>>>> arguments >>>>>>>>>>>>> in >>>>>>>>>>>>>> [2]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Matt >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c >>>>>>>>>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <seb...@gmail.com> >>>>> wrote: >>>>>>>>>>>>>>> The JDK Javadoc says of NPE: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Applications should throw instances of this class to >>> indicate >>>>>>>>>>>>>>> * other illegal uses of the <code>null</code> object. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and of IAE: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Thrown to indicate that a method has been passed an >>> illegal >>>>> or >>>>>>>>>>>>>>> * inappropriate argument. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That says to me that we should throw IAE here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The JDK does use NPE for parameter checks, but it also uses >>>>> IAE, >>>>>>>>>> for >>>>>>>>>>>>>>> example: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> javax.management.monitor.Monitor.addObservedObject >>>>>>>>>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc >>>>>>>>>>>>>>> javax.management.relation.RoleList.add >>>>>>>>>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30 August 2013 16:50, Adrian Crum < >>>>>>>>>>>>> adrian.c...@sandglass-software.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in >>> the >>>>> end >>>>>>>>>>>> they >>>>>>>>>>>>> all >>>>>>>>>>>>>>>> condense down to what Matt stated here: Those who favor NPE >>>>> cite >>>>>>>>>>> the >>>>>>>>>>>>> JDK >>>>>>>>>>>>>>>> classes as a pattern to follow, and those who favor IAE >>> say it >>>>>>>>>> is >>>>>>>>>>> a >>>>>>>>>>>>>>> better >>>>>>>>>>>>>>>> description of the problem. From my perspective, both are >>>>> valid >>>>>>>>>>>>>>> viewpoints, >>>>>>>>>>>>>>>> and a project simply needs to choose one. In the end, the >>>>> choice >>>>>>>>>>> is >>>>>>>>>>>>>>> neither >>>>>>>>>>>>>>>> "right" nor "wrong" - it is just a choice. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote: >>>>>>>>>>>>>>>>> Let me stir the pot: >>>>>>>>>>>>>>>>> At a fundamental level I agree that a required >>> *argument* >>>>>>>>>>> should >>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>> IllegalArgumentException when null is supplied. However, >>>>> ISTR >>>>>>>>>>> the >>>>>>>>>>>>>>>>> decision >>>>>>>>>>>>>>>>> to do otherwise in [lang] having been discussed on-list in >>>>> the >>>>>>>>>>>>>>>>> not-so-distant past, and the result of that discussion >>> being >>>>>>>>>> that >>>>>>>>>>>>> NPE is >>>>>>>>>>>>>>>>> usually the result in the core JDK classes. So I wouldn't >>>>>>>>>>>>> characterize >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now, >>>>> [lang] >>>>>>>>>>> is >>>>>>>>>>>>> in a >>>>>>>>>>>>>>>>> slightly unique situation as its stated mission is to >>>>>>>>>> complement >>>>>>>>>>>> Java >>>>>>>>>>>>>>> SE, >>>>>>>>>>>>>>>>> so it could be argued that [lang] is under greater >>> pressure >>>>> to >>>>>>>>>>>>> conform >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> that reason. But my personal preference, in light of the >>>>>>>>>>> standing >>>>>>>>>>>>>>>>> decision >>>>>>>>>>>>>>>>> with [lang], would be for consistency throughout Commons >>>>>>>>>>> components >>>>>>>>>>>>>>>>> *despite* the fact that at a purely semantic level I agree >>>>> with >>>>>>>>>>> the >>>>>>>>>>>>>>>>> arguments in favor of IllegalArgumentException. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To summarize, +1 for NullPointerException from me. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Matt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter < >>>>>>>>>>>> brit...@apache.org >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2013/8/30 sebb <seb...@gmail.com> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter < >>>>> brit...@apache.org >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> I've removed the generics in r1518974, thanks for >>> spotting >>>>>>>>>>> that >>>>>>>>>>>>> sebb. >>>>>>>>>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The >>>>>>>>>>> important >>>>>>>>>>>>> thing >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> fail early. >>>>>>>>>>>>>>>>>>> ... and with a helpful message. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I personally thing that NPE should be reserved for >>>>> signaling >>>>>>>>>>>> that >>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>> code >>>>>>>>>>>>>>>>>>>> tried to invoke a method on a null reference. >>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In our case null is illegal because we know that some >>> code >>>>>>>>>>> later >>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>> break if we accept a null reference. So >>>>>>>>>> IllegalStateException >>>>>>>>>>>>> makes >>>>>>>>>>>>>>>>>>> sense. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>> Sorry, I meant IAE of corse. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Imaging having a method that accepts an int and only >>>>>>>>>> positive >>>>>>>>>>>> ints >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a >>>>>>>>>>> negative >>>>>>>>>>>>> int >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> passed to that method and not a >>> NegativeIntegerException >>>>> (or >>>>>>>>>>>> what >>>>>>>>>>>>>>>>>> ever). >>>>>>>>>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we >>> should >>>>>>>>>>> stick >>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>>>>>> I don't think we have to do the same as LANG, so long as >>>>> the >>>>>>>>>>>>> Javadoc >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>> clear. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Feel free to change it. I'll leave it for now since >>> there >>>>>>>>>>>> doesn't >>>>>>>>>>>>>>> seem >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> be consensus?! >>>>>>>>>>>>>>>>>>> Unless there are other reasons than "LANG happens to use >>>>>>>>>> NPE" I >>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>> we should stick with IAE, as it more clearly indicates >>> the >>>>>>>>>> the >>>>>>>>>>>>> problem >>>>>>>>>>>>>>>>>>> is not within the method throwing it. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The problem with using NPE to flag parameter errors is >>> that >>>>>>>>>> it >>>>>>>>>>>>>>>>>>> confuses the user as to the likely cause. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Leave NPEs to the runtime system. >>>>>>>>>>>>>>>>>> agreed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Benedikt >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java >>>>>>>>>>> developers >>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>> learned through the years that NPE typically is an "oh >>>>>>>>>> crap" >>>>>>>>>>>>>>>>>>>>> situation, where something is terribly wrong (we hate >>>>>>>>>> seeing >>>>>>>>>>>>> those). >>>>>>>>>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not >>> even >>>>>>>>>>> know >>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> inspect the message for the real cause. IAE is less >>>>>>>>>>> alarming, >>>>>>>>>>>>> IMHO. >>>>>>>>>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a >>>>> long >>>>>>>>>>> time >>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>> [lang], so be it. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb < >>> seb...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message >>> associated >>>>>>>>>> with >>>>>>>>>>>>> them. >>>>>>>>>>>>>>>>>>>>>> So provided that the assertion generates the NPE >>> with a >>>>>>>>>>>> suitable >>>>>>>>>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it >>>>>>>>>>> *should* >>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>> possible for the end user to distinguish the two >>> cases. >>>>>>>>>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the >>> cause is >>>>>>>>>>>> obvious >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> needing to look at the NPE message. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> == >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could >>> wrap >>>>> an >>>>>>>>>>> IAE >>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> NPE: >>>>>>>>>>>>>>>>>>>>>> npe = new NPE(msg); >>>>>>>>>>>>>>>>>>>>>> npe.initCause(new IAE(msg)); >>>>>>>>>>>>>>>>>>>>>> throw npe; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Or vice-vera, of course! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Not sure that gains anything, but it does make the >>> stack >>>>>>>>>>> trace >>>>>>>>>>>>> look >>>>>>>>>>>>>>>>>>>>>> more impressive! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman < >>>>>>>>>>>>> ja...@carmanconsulting.com> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I >>> don't >>>>>>>>>>> know >>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> I've >>>>>>>>>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a >>>>>>>>>> decision >>>>>>>>>>>> was >>>>>>>>>>>>>>> made >>>>>>>>>>>>>>>>>>>>>>> that null constraint violations should throw NPEs. >>>>> Food >>>>>>>>>>> for >>>>>>>>>>>>>>>>>> thought. >>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory < >>>>>>>>>>>>>>>>>>> garydgreg...@gmail.com> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg < >>>>>>>>>>>>>>>>>> ebo...@apache.org> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> + if (parameter == null) { >>>>>>>>>>>>>>>>>>>>>>>>>>> + throw new >>>>>>>>>>>> IllegalArgumentException("Parameter >>>>>>>>>>>>> '" >>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>>>>>>>>> parameterName + "' must not be null!"); >>>>>>>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>>>>>>> +} >>>>>>>>>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ? >>>>>>>>>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume >>> something >>>>> is >>>>>>>>>>> very >>>>>>>>>>>>>>> wrong >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site, >>>>> somewhere >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> code >>>>>>>>>>>>>>>>>>>>> path. >>>>>>>>>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the >>>>> call >>>>>>>>>>> site >>>>>>>>>>>>>>>>>> (which >>>>>>>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>>>>>>>> be a bug of course). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, >>> so >>>>>>>>>> it's >>>>>>>>>>>>> hard to >>>>>>>>>>>>>>>>>>> find >>>>>>>>>>>>>>>>>>>>>>>> examples. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Gary >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Emmanuel Bourg >>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition< >>>>>>>>>>>>>>>>>>>>> http://www.manning.com/bauer3/> >>>>>>>>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition < >>>>>>>>>>>>>>> http://www.manning.com/tahchiev/ >>>>>>>>>>>>>>>>>>>>>>>> Spring Batch in Action < >>>>>>>>>> http://www.manning.com/templier/> >>>>>>>>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> http://people.apache.org/~britter/ >>>>>>>>>>>>>>>>>>>> http://www.systemoutprintln.de/ >>>>>>>>>>>>>>>>>>>> http://twitter.com/BenediktRitter >>>>>>>>>>>>>>>>>>>> http://github.com/britter >>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@commons.apache.org >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>> dev-h...@commons.apache.org >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> http://people.apache.org/~britter/ >>>>>>>>>>>>>>>>>> http://www.systemoutprintln.de/ >>>>>>>>>>>>>>>>>> http://twitter.com/BenediktRitter >>>>>>>>>>>>>>>>>> http://github.com/britter >>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>> Java Persistence with Hibernate, Second Edition< >>>>>>>>>>>> http://www.manning.com/bauer3/> >>>>>>>>>>>> JUnit in Action, Second Edition < >>> http://www.manning.com/tahchiev/ >>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>> Java Persistence with Hibernate, Second Edition< >>>>>>>>>> http://www.manning.com/bauer3/> >>>>>>>>>> JUnit in Action, Second Edition < >>> http://www.manning.com/tahchiev/> >>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> http://people.apache.org/~britter/ >>>>>>>>> http://www.systemoutprintln.de/ >>>>>>>>> http://twitter.com/BenediktRitter >>>>>>>>> http://github.com/britter >>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>> 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 >>>>> >>>>> >>> --------------------------------------------------------------------- >>> 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
