On 05/11/2015 11:41 PM, Peter Levart wrote:
On 05/12/2015 07:41 AM, Peter Levart wrote:
Taking another look at this deadlock issue and the compatibility
concerns, I wonder if we should keep this change as a special
implementation for system properties rather than having this change to
java.util.Properties class. Properties is a Hashtable which specifies
the fast-fail behavior (throwing ConcurrentModificationException for
concurrent update). There are other issues specific to system
properties we want to clean up (e.g. read-only system property,
private
system property to JDK but not visible to public etc).
Any thought?
I like this idea, too. :)
One thought:
In the current fix, clone() and serialization make use of
package-private methods. This could present some difficulties if
system properties would use its own Properties subclass that would
live outside java.util.
-Brent
Do you have an example where you would like to access/override one of
those methods? They are designed to be a private contract between
Properties and Hashtable.
Regards, Peter
Ah, I understand Mandy now. You are talking about using special
Properties implementation just for system properties. Unfortunately,
this is currently valid code:
Properties props = new Properties();
...
System.setProperties(props);
...
props.setProperty(key, value);
assert System.getProperty(key).equals(value);
How likely does existing code do this? A proper way is to call
System.setProperty. One pattern I found on System.setProperties is like
this to add a system property of key/value pair:
Properties props = System.getProperties();
props.put(key, value);
System.setProperties(props);
More investigation needs to be done (e.g. look at System.setProperties
and other system property related APIs and any spec change is needed to
be made and the compatibility implication) if we agree that it worths
keeping this change local to system properties.
By current semantics, the props object must be installed as new system
properties by reference, so later changes to it must be visible. Here,
the class of system properties is chosen by user.
Perhaps the spec of System.setProperties should be changed (I don't have
cycle to think through this).
But I think it should be pretty safe to make the java.util.Properties
object override all Hashtable methods and delegate to internal CMH so
that:
- all modification methods + all bulk read methods such as
(keySet().toArray, values.toArray) are made synchronized again
- individual entry read methods (get, containsKey, ...) are not
synchronized.
This way we get the benefits of non-synchronized read access but the
change is hardly observable. In particular since external
synchronization on the Properties object makes guarded code atomic
like it is now and individual entry read accesses are almost
equivalent whether they are synchronized or not and I would be
surprised if any code using Properties for the purpose they were
designed for worked any differently.
I agree that making read-only methods not synchronized while keeping any
method with write-access with synchronized is pretty safe change and low
compatibility risk. On the other hand, would most of the overrridden
methods be synchronized then?
Mandy
