Hi Prasanta,
Thank you for your feedback.
Actually there are two problems here: JDK-8163889
<https://bugs.openjdk.java.net/browse/JDK-8163889> is devoted to the
crash/assert error and JDK-8173050
<https://bugs.openjdk.java.net/browse/JDK-8173050> which is about
possible lack of support for the images with 'custom' type.
Currently I am trying to address the first problem, (i.e. eliminate
crash and assert errors which take place during printing). So possible
implementations of syncFromCustom(), syncToCustom(), etc. are out of
scope for this fix. They will be investigated under JDK-8173050
<https://bugs.openjdk.java.net/browse/JDK-8173050>.
It is possible to create manual regression test for this problem. Also
the test will require some additional set up steps such as printer
installation and so on. It seems to me that is overhead for person who
runs it. However if you insist on test creation, I will add it.
Thanks,
Dmitry
On 16/01/2017 09:14, Prasanta Sadhukhan wrote:
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
