On Nov 18, 2017, at 8:10 AM, Brian Goetz <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 <fo...@univ-mlv.fr >> <mailto: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. 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.
