RFR: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled [v3]

[Phil Race]

On Fri, 24 Feb 2023 01:37:44 GMT, SWinxy <duke at openjdk.org> wrote:

> > And if a default font prevents the FontUIResource from being installed, how does it get installed the in the first place ?
> > Perhaps that first time the component has no peer and it really is null ?
> 
> The font is null when it's created. Calling `getFont` causes it to go up the hierarchy, if it has a parent. The UI looks to be initialized (and thus a font is set) before `getFont` is called.

That is what I guessed. Accidental or deliberate ? I'd have to spend time to know.

> 
> > FontUIResource is something devised by Swing, for Swing.
> > Making AWT components depend on it for the convenience of Swing is backwards.
> 
> D'oh.
> 
> > It seems you would have to explicitly track whether the app set the font omn the JComponent rather than using this mechanism .. and if it did not then ignore whatever the font is ??
> > But I'm guessing and it adds just another bit more risk+complexity to this change.
> 
> Sounds like the path would be to undo my last commit and just put a note in the code.

But then there'd either be the correct font not installed or something else bad ?
How would a note in the code help ?

Maybe we are going about this all wrong  ? 
Maybe uninstall isn't needed ? 
What are the rules (set by Swing?) for what a L&F should do when installing a UI ?
If it is "if there is a FontUIResource, then feel free to replace it with yours" then may be everything in
this PR (at least about fonts) is un-needed ?

This is code relied upon by tens of thousands of applications written over a period of 25 years.
A change like this is really risky, when you consider that there are probably 10 times more
apps than there are Swing regresssion tests .. and only a few of the regression (and other) tests cover this kind of scenario.

Testing on every platform of every test we have is a bare minimum.

In the end my point is that unless (and until) we see some application complain, these proactive changes are a bad trade-off.

-------------

PR: https://git.openjdk.org/jdk/pull/10565