Hi Dmitri,
Don't you need to implement syncFromCustom() and syncToCustom()?
If not, then it seems you do not need to call this functions from
customPixelsFromJava() and customPixelsToJava() in which case, then env
change/fix will not be needed.
Also, is it not possible to create a regression testcase?
Regards
Prasanta
On 1/14/2017 8:22 PM, Dmitry Markov wrote:
Hello,
Could you review a fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8163889
webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/
Problem description:
Several functions inside ImageSurfaceData.m, (e.g. customPixelsFromJava(),
customPixelsToJava(), etc.) invoke getJNIEnv() from ThreadUtilities instead of
usage corresponding input parameter. According to the design - getJNIEnv()
should be executed on AppKit thread, but all code related to printing should
NOT run on AppKit thread. So we get the following assert here - ‘CocoaAWT: Not
running on AppKit thread 0 when expected.’
Also customPixelsFromJava() and customPixelsToJava() call
OSXOffScreenSurfaceData.syncFromCustom() and
OSXOffScreenSurfaceData.syncToCustom(), but these methods are absent at Java
layer. So when we try to perform such JNI invocation we experience the crash.
Fix:
It is necessary to eliminate negative effects such as crashes, native
exceptions and assert errors during printing.
Change summary:
- Replaced invocation of getJNIEnv() with usage of corresponding input
parameter.
- Added method stubs to OSXOffScreenSurfaceData.
Thanks,
Dmitry
