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

[Rémi Forax]

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