commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Date Mon, 02 Sep 2013 19:27:42 GMT
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 <james@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 <beneritter@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 <james@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 <gudnabrsam@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" <james@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 <garydgregory@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 <britter@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 <garydgregory@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 <
> gudnabrsam@gmail.com>
> >> >> wrote:
> >> >> >>>
> >> >> >>>> How often do you really want to catch these?
> >> >> >>>>
> >> >> >>>> Matt
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
> >> garydgregory@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 <sebbaz@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 <gudnabrsam@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
<sebbaz@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.crum@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 <
> >> >> >>>>> britter@apache.org
> >> >> >>>>>>>
> >> >> >>>>>>>>>> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> 2013/8/30 sebb <sebbaz@gmail.com>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>> On 30 August 2013
15:19, Benedikt Ritter <
> >> britter@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 <james@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 <
> sebbaz@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 <
> >> >> >>>>>> james@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 <
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> garydgregory@gmail.com>
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>
On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>>>>>
For additional commands, e-mail:
> >> >> >>>>> dev-help@commons.apache.org
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>
--
> >> >> >>>>>>>>>>>>>>>>>
E-Mail: garydgregory@gmail.com |
> ggregory@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-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
> >> >> >>>>
> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>> To unsubscribe,
e-mail:
> >> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>> For additional
commands, e-mail:
> >> >> >>> dev-help@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-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>> For additional commands,
e-mail:
> >> dev-help@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-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
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>> 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
> >> >> >>>>> 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: garydgregory@gmail.com | ggregory@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-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
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

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