United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7183251 Netbeans editor renders text wrong on JDK 7u6 build 17
JDK-7183251 : Netbeans editor renders text wrong on JDK 7u6 build 17

Details
Type:
Bug
Submit Date:
2012-07-11
Status:
Closed
Updated Date:
2012-12-05
Project Name:
JDK
Resolved Date:
2012-07-24
Component:
client-libs
OS:
os_x,windows_8,generic,windows_7
Sub-Component:
2d
CPU:
x86,generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
2.0,7u6,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
Netbeans editor renders text wrong on JDK 7u6 build 17 aginst build 16.
See attached images

                                    

Comments
EVALUATION

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.
                                     
2012-07-17
EVALUATION

I filed 7184798 to consider revising this area of the code more broadly
                                     
2012-07-17
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ab0b2720a756
                                     
2012-08-14
Hard to verify
                                     
2012-12-05



Hardware and Software, Engineered to Work Together