JDK-7183251 : Netbeans editor renders text wrong on JDK 7u6 build 17
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 2.0,7u6,8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,os_x,windows_7,windows_8
  • CPU: generic,x86
  • Submitted: 2012-07-11
  • Updated: 2012-12-05
  • Resolved: 2012-07-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u34Fixed 7u6Fixed 8 b49Fixed
Related Reports
Duplicate :  
JDK-7183332 - Bold text rendering regression in 7u6
Duplicate :  
JDK-7185204 - FontMetrics.stringWidth() does not return fixed value for same string
Duplicate :  
JDK-7184900 - [macosx] regression test closed/demo/jfc/Java2D/Java2DemoTest.java fail
Duplicate :  
JDK-7180898 - Exception thrown from FileFontStrike.getCachedGlyphPtr in Java2Demo
Relates :  
JDK-7184798 - Revisit caching code in SunLayoutEngine.java
Relates :  
JDK-7027300 - Unsynchronized HashMap access causes endless loop
Description
Netbeans editor renders text wrong on JDK 7u6 build 17 aginst build 16.
See attached images
Comments
Hard to verify
05-12-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ab0b2720a756
14-08-2012
EVALUATION I filed 7184798 to consider revising this area of the code more broadly
17-07-2012
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.
17-07-2012