RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8

Jim Gish jim.gish at oracle.com
Tue May 1 15:50:50 UTC 2012

Thanks -

Should I proceed with improvements to String.join() or wait, for 
example, until the lambda array support is there?


On 05/01/2012 07:02 AM, Rémi Forax wrote:
> On 04/30/2012 04:23 PM, Jim Gish wrote:
>> Thanks Rémi,
>> I'll take a look at defender methods on Iterable.
>> As far as the parameter checks on String -- I had the same "Aha!" 
>> moment as soon as I got in my car to drive home on Friday. 
> :)
>> However, it does come down to a philosophy of style in that I'm in 
>> favor of (1) catching and reporting errors as soon as possible, and 
>> (2) not depending on the implementation details of other methods 
>> (particularly other classes) of which I'm a client. 
> These checks are part of the spec of the method then part of the 
> implementation,
> that's why I think it's Ok tu use them.
>> On the other hand, given this is "core" I realize that performance 
>> matters as well as locality of reference, so there is a trade off 
>> between deferring the check and sharing the static result message 
>> string.
> The main issue with sharing static strings is that slowdown the 
> startup of the VM.
> The core classes do already too much static initialization for very 
> little benefit,
> by example, loading a string requires to initialize 
> even if this comparator is not actually used.
> BTW, a good project should be to try to remove most of the private 
> static fields
> from the public java.lang classes in order to defer their 
> initializations.
>> Let's see what others think.
>> As far as transient on the static field -- I also realized as I was 
>> driving away that statics might not be serialized so transient is 
>> unnecessary.
>> Thanks,
>>    Jim
> cheers,
> Rémi

More information about the core-libs-dev mailing list