This is a proposed patch that makes few significant changes in Value-Configuration part to support dynamic update of Configuration. Hence this is a patch for your comment/review.
1. The intents are
a) certain Values can be marked dynamic. This allows them to be modified even after the configuration is frozen i.e. EntityManagerFactory has issued its first EntityManager.
b) because EntityManagerFactories are cached based on the keys of their configuration, the hashCode of the configuration must not be changed when a dynamic value V changes from x1 to x2.
For example, for Configuration A, one of it's value V(A) is originally set to x1. Later it was modified to x2.
A.hashCode() should remain the same before and after the modification if V is dynamic.
c) Equality: Two Configuration A and B had originally V(A)=x and V(B)=y where V is dynamic.
Initially x!=y. That implies A not equals B.
Now V(B) is set to x. Does A now equals B?
The intended answer is no.
2. What needed to support (1c) is notion of 'originalValue' for dynamic properties. This patch implements by declaring a new String field in Value.class, also logic of setting this 'originalValue' in setString() and setObject() methods.
3. The 'originalValue' notion is used for changed behavior of Value.equals() and Value.hashCode() methods.
4. ConfigurationImpl used to compute its hashCode() and equals() by first converting itself into a Properties object. I do not why. That is the main reason this is submitted as a patch for everyone's comment/review.
This patch makes a conceptual change. Now ConfigurationImpl computes its hashCode() and equals() based on its Values – who in turn evaluates their own hashCode() and equals() that varies based on their dynamic nature.