On 9/04/2013 10:28 PM, Stephen Colebourne wrote:
While I disagree with the choice made (one of Java's strengths is a
little bit of extra verbosity), I am happy if it is consistent. Based
on the links I provided, clearly Project Lambda has a long way to go
to meet that consistency, so it clearly hasn't been a firm
recommendation up until now.
The examples you gave have all been fixed within the last couple of
weeks. If you still see some please point them out but my searching
shows that the only use of "public default" in the lambda repos is from
java.time and:
./share/classes/java/security/Principal.java: public default boolean
implies(Subject subject) {
./share/classes/java/security/KeyStore.java: public default
Set<Attribute> getAttributes() {
./share/classes/javax/security/auth/Destroyable.java: public default
void destroy() throws DestroyFailedException {
./share/classes/javax/security/auth/Destroyable.java: public default
boolean isDestroyed() {
java.time will of course be adapted to match.
Terrific.
Thanks,
David
Stephen
On 9 April 2013 12:57, David Holmes <[email protected]> wrote:
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
