Scope modifiers in interfaces [was Default methods on Map]

[David Holmes]

Stephen,

On 9/04/2013 7:53 PM, Stephen Colebourne wrote:
> As far as I can tell, there are three different styles being used for
> "public" modifiers in interfaces now:
>
> 1) no use of "public"
> 2) use of "public" only on default methods
> 3) use of "pubilc" on default and abstract methods
> (I can't recall seeing any static methods on interfaces outside of JSR-310 yet)
>
> Type 1:
> http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/stream/Collector.java
>
> Type 2:
> http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/BiConsumer.java
>
> Type 3:
> http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/IntSupplier.java
> http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/IntPredicate.java

All of the lambda-related work has now moved (or is moving) to #1. No 
public on interface methods as has been the recommendation since day one.

> I find this inconsistency troubling. Its time for a firm
> recommendation to be made as to Oracle's preferred coding standard.

I agree because I see that java.time is using #2.

> I'm of the opinion that moving code to #3, explicit use of "public"
> will serve Java better in the long run. I find #1 particularly
> troubling, as it means a default method (which looks very like a
> normal method) looks like it is package scoped when I read the source
> code.

If/when non-public methods are allowed in interfaces then we should 
probably make things explicit, in my opinion. I don't find anything 
troubling about not having public of interface methods - default or 
abstract.

David
-----

> (this affects the Map changes webrev)
> Stephen
>
>
>
> On 8 April 2013 19:07, Mike Duigou <mike.duigou at oracle.com> wrote:
>> Hello all;
>>
>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/
>>
>> 8004518: Add in-place operations to Map
>>   forEach()
>>   replaceAll()
>>
>> 8010122: Add atomic operations to Map
>>   getOrDefault()
>>   putIfAbsent()          *
>>   remove(K, V)
>>   replace(K, V)
>>   replace(K, V, V)
>>   compute()              *
>>   merge()                *
>>   computeIfAbsent()      *
>>   computeIfPresent()     *
>>
>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key).
>>
>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity.
>>
>> Mike
>>