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

[Rémi Forax]

On 05/01/2012 05:50 PM, Jim Gish wrote:
> Thanks -
>
> Should I proceed with improvements to String.join() or wait, for 
> example, until the lambda array support is there?
>
> Jim

better to ask Brian Goetz :)

Rémi

>
> 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 
>> String.CASE_INSENSITIVE_ORDER
>> 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
>>
>