纯Swing中获取当前GUI字体的优选方案及原因问询

结论 #

优先选择方案1 somethingExtendsAwtComponent.getFont()，若无可用关联组件实例，再选择方案4 UIManager.getDefaults().getFont("defaultFont")

各方案具体分析 #

方案1：somethingExtendsAwtComponent.getFont() #

这是最适配需求的方案，原因如下：

• 拿到的是目标组件实际用于渲染的字体，完全匹配当前界面的真实展示效果，不会出现生成的粗体和原字体家族、字号不匹配的问题
• 覆盖所有自定义场景：包括单个组件单独设置字体、父组件字体继承、不同LookAndFeel下组件字体特殊适配等情况，取值准确性远高于其他三种从全局配置拿默认值的方案
• 无兼容性问题，是AWT/Swing规范明确提供的组件属性获取接口，所有JDK版本和自定义LookAndFeel都能正常返回有效值

方案2：UIManager.getLookAndFeel().getDefaults().getFont("defaultFont") #

不推荐使用，问题如下：

• 仅能拿到LookAndFeel加载时的初始默认配置，不会包含后续代码对Swing全局字体的修改，也不会适配系统级的字体配置覆盖，和界面实际用的字体不一致的概率很高
• 很多第三方自定义LookAndFeel不会将默认字体存放在这个初始defaults对象中，返回null的概率极高

方案3：UIManager.getLookAndFeelDefaults().getFont("defaultFont") #

不推荐使用，除了官方Javadoc提到的修改返回对象会引发异常的问题外，还有其他缺陷：

• 这个对象是LookAndFeel的内部共享实例，切换LookAndFeel时会被清空或重建，多线程场景下大概率拿到失效值
• 部分OpenJDK衍生版本的实现中，这个defaults不会合并用户自定义的全局字体配置，取值可靠性远低于方案4

方案4：UIManager.getDefaults().getFont("defaultFont") #

是无可用组件实例时的次优选择：

• 拿到的是合并了LookAndFeel默认配置、用户全局修改、系统字体适配之后的最终全局默认值，取值可靠性远高于方案2、3
• 符合官方Javadoc的推荐规范，避免了方案3的内部实例操作风险

内容的提问来源于stack exchange，提问作者mindoverflow