RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map
forax at univ-mlv.fr
forax at univ-mlv.fr
Wed Nov 22 11:40:45 UTC 2017
> 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,
> 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
>>> 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
> 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
> 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.
More information about the core-libs-dev