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