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

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>, "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 22 Novembre 2017 04:31:52
> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set,
> Map

> On Nov 18, 2017, at 8:10 AM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> 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 < [ mailto:forax at univ-mlv.fr |
>>> 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.

The whole point of final on methods is to add security and as a side effect, it bother the implementors. Security always bother people that doesn't have to handle security issues. 
So you can have security even in a blue collar language. 

I do not see the point to add a new semantics if you have a way to solve the current issue by applying a know semantics 'final' on an already existing feature 'default method'. 

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

#2 also works by accident, the fact that by inheritance you can see static method is ugly. 
The lambda EG has made clear that the fact that you can see a static method by inheritance was a mistake by making static methods in interface non visible by inheritance. 

> I would also be glad to see a #5 that would please everybody.

or a #3, there is no #3 in your list. 

> — John

Rémi 

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

I think everybody on this list agree about that point.