At some point, java.awt.Color.createContext() was marked as synchronized to support caching of a ColorPaintContext instance. The cache was later removed, but the synchronized modifier remained. Since there is no shared mutable state anymore, the synchronization is no longer necessary and can be safely removed.
Note: This code path is rarely executed because a special optimization was introduced in [SunGraphics2D.setPaint](https://github.com/openjdk/jdk/blob/c514f135ccf08c3be016a32ae8f2c055fb941857/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L1003). As a result, unless a custom wrapper around the Color class is used, the Color.createContext() method is typically bypassed during rendering. Two tests are added: - ColorPaintContextBasicTest: Checks if different image types (BufferedImage and VolatileImage) produce the same results when using different ways to fill the image (setColor, setPaint, and custom Paint). This test intentionally uses a custom Paint implementation to bypass the optimization and ensure that Color.createContext() is invoked verifying its correct behavior. - ColorPaintContextStateTrackerTest: Checks that the raster used in ColorPaintContext.getRaster() can be properly cached in video memory and we do not need to call icr.markDirty() in ColorPaintContext.getRaster() ------------- Commit messages: - Merge branch 'openjdk:master' into colorctx - Update ColorPaintContextBasicTest.java - handle VolatileImage properly - Update ColorPaintContext.java - 8355078: java.awt.Color.createContext() uses unnecessary synchronization Changes: https://git.openjdk.org/jdk/pull/24771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24771&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355078 Stats: 304 lines in 4 files changed: 270 ins; 21 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24771/head:pull/24771 PR: https://git.openjdk.org/jdk/pull/24771
