> On May 15, 2015, at 12:09 PM, Brent Christian <brent.christ...@oracle.com> 
> wrote:
> 
> Updated webrev:
> 
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.1/
> 
> I have restored synchronization to modification methods, and to my 
> interpretation of "bulk read" operations:
> 
>    * forEach
>    * replaceAll
>    * store: (synchronized(this) in store0; also, entrySet() returns a 
> synchronizedSet)
>    * storeToXML: PropertiesDefaultsHandler.store() synchronizes on the 
> Properties instance
>    * propertyNames(): returns an Enumeration not backed by the Properies; 
> calls (still synchronized) enumerate()
>    * stringPropertyNames returns a Set not backed by the Properties; calls 
> (still synchronized) enumerateStringProperties
> 
>  These continue to return a synchronized[Set|Collection]:
>    * keySet
>    * entrySet
>    * values


The enumerate and enumerateStringProperties methods calls entrySet() to 
enumerate all entries adding to the given map. The methods are synchronized and 
it can call map.entrySet directly to avoid the unnecessary synchronization. 

> 
>  These methods should operate on a coherent snapshot:
>    * clone
>    * equals
>    * hashCode
> 
>  I expect these two are only used for debugging.  I wonder if we could get 
> away with removing synchronization:
>    * list
>    * toString
> 

list() method calls enumerate() that is synchronized to take a snapshot and it 
doesn’t need synchronize. It may be useful to leave toString with synchronize 
that we know the string is a snapshot.

Otherwise, looks good.

Mandy

Reply via email to