The problem of dynamically changing property values at point of use is actually orthogonal to the one of holding the same property in multiple forms. Each is a synchronization problem, but of different forms.
For any property, not just strings/classes, there is the question: when does a change to the value in its canonical home (the EnvironmentBean) take effect in things that use that property? The answer right now is: probably never. The value is read from the bean at startup (or first use) and effectively cached at the point of use, usually in a static variable. Therefore subsequent updates modify the bean but not the point of use and are thus ineffective.
For properties that have dual representation e.g. String vs. Class, there is the question of how/when updates to one of those representations affect the other. That's a much more limited problem. Right now for example, putting a getName/getInstance pair on an EnvironmentBean would just require figuring out the synchronization between them and moving the classloading code from point of use to inside the bean. But it won't address the problem that the point of use is calling either getName or getInstance once only and not rechecking either for later updates.
Initially I'm just looking to reduce the duplication of classloading code and allow for bean injection by putting Class getters/setters on the beans. After that I'll worry about the dynamic change at point of use problem. The former has a generic solution for all String/Class cases, whereas the latter will require individual examination of each point of use. In many cases I think we can probably move from static variable to instance variable and static initializer block to constructor for initializing it from the bean. But it's related to lifetime and use of the object constructed.
For example, the useAlternativeOrdering applies in comparison of records, so changing that will cause really screwy behaviour if it leads to comparing a set of records some of which were created before and some after the change. In another case the port number for a listener would require restarting that listener to take effect, which a) is not feasible at present and b) would have consequence for any clients trying to connect if they don't see the update at the same time. That's a distributed form of a problem that also exists inside the same VM - how to coordinate updates where there is more than one point of use for the same property and they need to be consistent. Should a component restart be triggered from the bean, requiring the bean to have knowledge of its users, or do we need an event registration mechanism so the listener can get a callback and restart itself when the bean property is updated? As you an see there are some common themes, each property's case is different and will need thinking about.