The map is not expected to be updated after it has been created so it
should not need synchronized access.
There are a couple of exceptions where it is being updated when some
file that
is supposed to be there can't be found - a scenario that apparently
hasn't been
an issue in the 10 years this code has been in use.
So the removal is an optimisation that could be revisited.
-phil.
On 2/22/21 4:40 AM, Andrey Turbanov wrote:
Hello.
I recently found suspicious field (with SpotBugs help) in class
SunFontManager:
static HashMap<String, FamilyDescription> platformFontMap;
This HashMap is accessed (read and write) in a method
sun.font.SunFontManager#findFontFromPlatformMap. As I see there is no
synchronization when this HashMap is accessed.
This method can be called from client code with this simple stack trace:
at
sun.font.SunFontManager.findFontFromPlatformMap(SunFontManager.java:1508)
at sun.font.SunFontManager.findFont2D(SunFontManager.java:2069)
at java.awt.Font.getFont2D(Font.java:500)
at java.awt.Font.getPSName(Font.java:1416)
I wonder if this unsynchronized access is expected. Looks like it can
break things when accessed from multiple threads simultaneously.
Do I miss something? Is it done this way, because Font objects are
supposed to be accessed from a single thread only?
Andrey Turbanov