RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install an entry for MetalMenuBarUI [v4]

[Phil Race]

On Thu, 12 Jan 2023 06:14:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec wording

I still am having problems fully understanding this.
(1) Is it correct that in cases like this there's no Basic**UI registered instead ?
(2) If Metal is registering just the UI classes used by *all* L&Fs, how on earth can it know that ?
   Suppose I wrote another Theme and it did not use one of the UI classes, would you really
need to update this code to stop registering it and then update every other theme to register it ?

It just does not make sense to me.

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

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