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
Locked
