Hi Rémi, One quick comment on AbstractStringBuilder.join(String, Object, Object...) -- I'd propose to check that 'elements' is not null prior to appending 'first' so that if the preconditions are violated and the NullPointerException is thrown, there are no side effects. This would also be a nice use of the proposed java.util.Objects validation/precondition/assert methods. The other two join methods in AbstractStringBuilder will implicitly throw NullPointerException when getting the length or iterator respectively, both prior to any modification to the underlying AbstractStringBuilder. I'd be in favor of making those more explicit, but that is more of a stylistic comment.
Thanks, Dave Schlosnagle On Wed, Oct 14, 2009 at 10:35 AM, Rémi Forax <fo...@univ-mlv.fr> wrote: > Le 14/10/2009 01:32, Joseph D. Darcy a écrit : >> >> Hello. >> >> Following up from threads earlier this year, >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html >> >> I'm willing and interested to sponsor getting String.join functionality >> into JDK 7. >> >> To address this particular bug, I think there should be new "join" methods >> on String as opposed to a general "joiner" class. A more general class >> could be added later. >> >> Remi, please point to a current draft of the specification and >> implementation for your change. >> >> Kevin, I'm interested in hearing your comments on the API design. >> >> Thanks, >> >> -Joe > > Hi Joe, > the webrev is here: > http://cr.openjdk.java.net/~forax/5015163/webrev.00/ > There is no specification, i.e no more than the javadoc. > > I will dig this evening to find the tests I've used, > they are on another computer at home which is currently shutdown. > > As Kevin said String.join is perhaps better as a static method, > see first part of: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html > > regards, > Rémi > > >
