Its definitely a font bug.
There is usually a single GlyphLayout instance per-VM
which is created and then checked out and back in again by calling code.
If more than one is needed we create it, but it means that mostly there's only one.
It is partially re-initialiased for each new client, but some state is saved.
For example it creates "EngineRecord" instances as needed.
These are then cached by the GlyphLayout and re-used by
subsequent clients but are also re-initialised as they are re-used.
One part of the state of an EngineRecord is the LayoutEngineKey
struct. which wraps a Font2D, script and lang.
This key is also cached on the EngineRecord and re-initialised when
the EngineRecord is re-initialised.
But the key instance is used as the key to a map where the
cached values are instances of SunLayoutEngine.
I'm not sure how useful this map is at all, but that's for later.
Since the content of the key is changed it will completely
mess up any hash map.
Moreover the SunLayoutEngine value references a LayoutEngine key
However its not the same key !
A private copy() is made for to be stored SunLayoutEngine instance
and the key to the map is the shared and mutated one.
So, the results of using the same key object over-and-over
but changing its contents and hash each time are going to
cause unpredictable results, which very conceivably can
differ from map to map. In the case of HashMap the previous
values seem to become un-gettable ..
But now since since the fix for 7027300 we are using ConcurrentHashMap
and it shows up this problem.
The private copy of the key on the SunLayoutEngine means you can
get a look up on font A returning a SunLayoutEngine that wraps font B.
The simple and safe fix (for now) as we need to back port the fix
is to make sure the map key is also the copy.