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
