Code review request

Joe Bowbeer joe.bowbeer at
Sat Feb 23 11:42:30 PST 2013

We should send these comments in emails?  I don't see a way to comment at
the link provided.

I repeat some of Remi's comments regarding formatting below.


1. Please run this through a code formatter to conform with Oracle's
standard.  Things to fix:

parameter wrapping should indent only 8 spaces:

+ default V merge(K key, V value,
+                 BiFunction<? super V, ? super V, ? extends V>
remappingFunction) {

if-else brace should be on same line:

+ }
+ else if ((newValue = remappingFunction.apply(oldValue, value)) != null) {

multi-line 'if' always needs braces?

+ if (replace(key, oldValue, newValue))
+     return newValue;

2. replaceAll javadoc: Function#map => Function#apply

calling the function's {@code Function#map} method

calling the function's {@code Function#apply} method

3. replaceAll question

What's with all the finals?

+        final Iterator<Map.Entry<K, V>> entries = entrySet().iterator();
+        while (entries.hasNext()) {
+            final Map.Entry<K, V> entry =;
+            entry.setValue(function.apply(entry.getKey(),
+        }

Why not code this as follows, just like forEach?

+        for (Map.Entry<K, V> entry : entrySet()) {
+            entry.setValue(function.apply(entry.getKey(),
+        }


On Thu, Feb 21, 2013 at 11:17 AM, Brian Goetz <brian.goetz at>wrote:

> At
> I've posted a webrev for about half the classes in None
> of these are public classes, so there are no public API issues here, but
> plenty of internal API issues, naming issues (ooh, a bikeshed), and code
> quality issues.

More information about the lambda-libs-spec-observers mailing list