RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

[John Rose]

On Nov 18, 2017, at 8:10 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I'm with Remi on this.  
> 
> Sent from my MacBook Wheel
> 
>> On Nov 18, 2017, at 5:41 AM, Remi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>> wrote:
>> 
>> Hi John,
>> i strongly believe that static fluent methods have no place in a blue collar language
>> ...

>> So in my opinion, the only possible option is to introduce final default methods, i fully understand that this is non trivial to introduce this kind of methods in the VM but this discussion is a good use case for their introduction. 

We have four choices on the table with respect to the occasional
need for securable API points in fluent APIs:

0. Blue collar language:  Pick only one of fluency or security.

1. Secure a default method by marking it final.

2. Secure a fluent API point by binding to a static in the same type.

4. Extension methods:  Anybody can "import" new statics into any type.

I think #0 hurts security, which is why I keep objecting to it.

Brian thinks #1 puts too many restrictions on implementors.

Although it would seem to allow everybody to do whatever they want,
#4 is not a fit for Java.  APIs in java.base are carefully curated,
and allowing third parties to add "nice" methods would interfere
with that curation.

Option #2 has the known good properties of C# extension methods
(decoupling from receiver dispatch, natural notation), without the known
bad properties of C# extension methods (lack of curation).

So #2 is the least ugly solution for an ugly problem, except possibly #1
Which I would accept also.  I would also be glad to see a #5 that would
please everybody.

— John

P.S. Security is a big concern for us developers of java.base.  And it is
surely a concern for everyone else, at least in part.  If you program
behind only a firewall, consider that program integrity and robustness
are corollaries of security.  Your past self and teammates are throwing
buggy code at your present self; you want to be secure from that
even if you don't fear nefarious attackers.  When we secure the
Java stack from nefarious attackers we are also preventing large
numbers of unintentional bugs.