RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v5]

[Sergey Bylokhov]

On Fri, 17 Sep 2021 12:57:18 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> FontManagerFactory class uses reflection to load platform specific FontManager classes from "sun.font.fontmanager" property.
>> 
>> Fix proposes creating FontManager platform specific classes directly in the similar way as it has been already done for GraphicsEnvironment and AWT Toolkit ([JDK-8130266](https://bugs.openjdk.java.net/browse/JDK-8130266) and [JDK-8212700](https://bugs.openjdk.java.net/browse/JDK-8212700)).
>> 
>> FontManager is internal jdk class. It is placed in `sun.font` package and java modularization encapsulates  FontManager from subclassing and using by a user.
>> 
>> The fix reuses PlatformGraphicsInfo to create FontManager platform specific classes. May be FontManager creation code needs to be placed in its own info classes.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change Solaris default implementation to Mac OS in FontManagerFactory comment

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 37:

> 35: 
> 36:     /** Our singleton instance. */
> 37:     private static volatile FontManager instance = null;

It is not necessary to initialize it to null here, there is ongoing effort to delete such initializations:
https://github.com/openjdk/jdk/pull/5197

src/java.desktop/share/classes/sun/font/FontManagerFactory.java line 46:

> 44:     public static FontManager getInstance() {
> 45: 
> 46:         if (instance == null) {

You can improve it a little bit further and read the volatile field only once in the common path. Read to local->check-> init local and field -> return local.

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

PR: https://git.openjdk.java.net/jdk/pull/5517