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 <[email protected]> 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
