I'd like to change the behavior then, if nobody objects. I'll write some
prose for the release notes of 3.3 (which I plan to roll out early February)
Benedikt
2014/1/14 sebb <seb...@gmail.com>
> On 14 January 2014 11:53, Duncan Jones <djo...@cantab.net> wrote:
> > On 14 January 2014 11:17, Benedikt Ritter <brit...@apache.org> wrote:
> >> 2014/1/13 Gary Gregory <garydgreg...@gmail.com>
> >>
> >>> On Mon, Jan 13, 2014 at 12:45 PM, sebb <seb...@gmail.com> wrote:
> >>>
> >>> > What does the Javadoc say?
> >>> >
> >>>
> >>> The Javadoc describes the current behavior, which is whacky IMO. This
> could
> >>> be a case where the docs documents the code, even though it does not
> make
> >>> sense.
> >>>
> >>> It sounds dangerous to change it in a minor release.
> >>>
> >>
> >> There are at least two issues:
> >>
> >> 1. StringUtils.spilt:
> >>
> >> StringUtils.split(null,<ANY>) = [ ]
> >> StringUtils.split("", <ANY>) = null
> >>
> >> 2. Inconsistency bewteen containsNone and containsOnly (what I said
> before):
> >>
> >> StringUtils.containsOnly("", <ANY>) = StringUtils.containsNone("",
> <ANY>)
> >> = true
> >> All of this is documented in JavaDoc, which doesn't mean it is wrong.
> >>
> >> 1) is just inconvinient. Changing it should not affect client code,
> since
> >> it will look like this:
> >>
> >> String[] parts = StringUtils.split(str, "abc");
> >> if(party != null) {
> >> // iterate over parts
> >> }
> >>
> >> Retruning an empty array will not affect this code.
> >
> > Not that specific example, no. But it would certainly affect:
> >
> > String[] parts = StringUtils.split(str, "abc");
> > if(party == null) {
> > // do something else
> > }
> >
> > I don't think this can be changed in a minor release.
>
> t seems unlikely that the end reult of the code would differ depending
> on whether the string was empty or not.
>
> If it did matter to the application, it seems more likely that the
> code would check for the empty string first.
>
> I think it is unlikely that any code will be affected.
>
> But clearly if the code is changed, this needs to be highlighted as an
> incompatibility (just as for the other case).
>
> > Duncan
> >
> >>
> >> 2) is a bug imho and needs to be fixed. The empty string at the same
> time
> >> contains anything and contains nothing (the latter is right). Bugs
> should
> >> be fixed in minor releases, even if the fix changes semantics of a
> method
> >> (from wrong to right). We can make this very clear in the release notes
> >> with an additional subscetion about this.
> >>
> >> Benedikt
> >>
> >>
> >>>
> >>> Gary
> >>>
> >>>
> >>>
> >>> >
> >>> > On 13 January 2014 17:00, Benedikt Ritter <brit...@apache.org>
> wrote:
> >>> > > ping, any thought on this?
> >>> > >
> >>> > >
> >>> > > 2014/1/11 Benedikt Ritter <brit...@apache.org>
> >>> > >
> >>> > >> Hi,
> >>> > >>
> >>> > >> while looking through the open issues for lang, I came across
> >>> LANG-823:
> >>> > >> StringUtils.split should handle empty strings the same as other
> >>> content
> >>> > >> [1]. The request makes sense to me - the empty string should be
> >>> handled
> >>> > >> like any other content.
> >>> > >>
> >>> > >> Then I looked into StringUtils to see how other methods handle the
> >>> empty
> >>> > >> string and there are more examples of specific handling of the
> empty
> >>> > >> string. For example the following will return true:
> >>> > >>
> >>> > >> StringUtils.containsOnly("", "abc")
> >>> > >>
> >>> > >> and it gets even more weird, since
> >>> > >>
> >>> > >> StringUtils.containsNone("", "abc")
> >>> > >>
> >>> > >> also returns true! How can the same string a the same time _only_
> >>> > contain
> >>> > >> "abc" and contain none of "abc"?
> >>> > >>
> >>> > >> I can not see any reason for this behavior. Why is the empty
> string
> >>> > >> different from any other string content? I'd like to change the
> >>> > behavior of
> >>> > >> the affected methods, but wanted to get some feedback first.
> >>> > >>
> >>> > >> Benedikt
> >>> > >>
> >>> > >> [1] https://issues.apache.org/jira/browse/LANG-823
> >>> > >>
> >>> > >>
> >>> > >> --
> >>> > >> http://people.apache.org/~britter/
> >>> > >> http://www.systemoutprintln.de/
> >>> > >> http://twitter.com/BenediktRitter
> >>> > >> http://github.com/britter
> >>> > >>
> >>> > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > 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
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>> 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
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
