FULL PRODUCT VERSION :
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Any MacOS

A DESCRIPTION OF THE PROBLEM :
As documented in https://bugs.openjdk.java.net/browse/JDK-8162796?focusedCommentId=14001817&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14001817 the CoreGraphics based renderer doesn't properly support painting user-subclasses of java.awt.Paint and TexturePaint (both relying on the `kColorTexture` op).

The first reason is that this support code is currently commented out with a "TODO" comment: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/cf207e188ae2/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m#l1082

The second reason is that, as-per comment Prasenta comment, there is a crash with current implementation when trying to LockImage the surface data.

This can be explained because the Java code in OSXSurfaceData creates the wrong type of SurfaceData to store in the array at `kTextureImageIndex`. Where the native code expects this to be a `OSXOffscreenSurfaceData`, the Java side creates this as a `BufImageSurfaceData`. The ops structure in that case is thus smaller than the native code expects which causes the crash.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The reproduction given in https://bugs.openjdk.java.net/browse/JDK-8162796 (without the patch currently being reviewed for it) is valid. Otherwise any TexturePaint or custom implementation of java.awt.Paint used with the CoreGraphics renderer (e.g. printing PDF).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Those types should be rendered properly
ACTUAL -
Nothing is being rendered

REPRODUCIBILITY :
This bug can be reproduced always.