> De: "John Rose" <john.r.r...@oracle.com> > À: "Brian Goetz" <brian.go...@oracle.com>, "Rémi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@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.go...@oracle.com | > brian.go...@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:fo...@univ-mlv.fr | >>> fo...@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.
