EVALUATION
Before 6594219, DeployUIManager called javax.swing.UIManager.setLookAndFeel(), thus setting LAF for the plugin's AppContext. Applets, because they live in different contexts, were getting default LAF, and could change it if they wished to. So everything worked properly, except for the fact that calling UIManager method caused loading of many Swing classes, and that was bad for jkernel.
The fix for 6594219 tried to avoid calling into Swing by setting a system property, "swing.defaultlaf". Unfortunately this setting affected all AppContexts, so applets started getting system LAF by default. This bug, 6653395, is a regression introduced by 6594219.
To fix the issue properly, we need a way to specify default LAF on a per-AppContext basis, like UIManager.setLookAndFeel() does, but without loading Swing. A natural way of doing this is through AppContext properties. Another thing to note is that plugin may customize LAF by setting properties (currently it sets "Slider.paintValue").
So the suggested fix is as follows:
- plugin creates an AppContext property whose value is a hashmap. This hashmap contains name of the default LAF class associated with a special predefined key, "defaultlaf". It may also contain any number of LAF properties. Currently the hashmap looks like:
{
"defaultlaf" -> <system LAF class name>
"Slider.paintValue" -> Boolean.FALSE
}
- UIManager.initializeDefaultLAF() examines the AppContext property, and if it's present, takes default LAF from there. After LAF has been set, it also sets any properties received through AppContext.
This approach is quite flexible - it's easy for plugin to specify additional properties if needed. It's also secure - no public API is involved, no client code will see the AppContext properties we create.
|
Java