Hello.
Please review the fix for jdk 9.
Type of the temporary buffer in DrawImage.renderImageXform() is
incorrect. Note that we blit this buffer to the destination, using next
maskblit/blit:
line 463: maskblit = MaskBlit.getFromCache(SurfaceType.IntArgbPre,
Hi, Hendrik.
The fix looks good.
webrev: http://cr.openjdk.java.net/~serb/Hendrik/8057830/webrev
However, before we can accept fixes from you, you will need to have an
OCA signed. Please find more details here:
http://www.oracle.com/technetwork/community/oca-486395.html
On 22.09.2014 12:19,
Hi Sergey,
In the test case you call new BufferedImage() with a Transparency
constant which is essentially a random number to determine the type of
BufferedImage since it is expecting its own values. You get lucky with
the value of the integer as it turns out, but the test case really
https://bugs.openjdk.java.net/browse/JDK-8028539
http://cr.openjdk.java.net/~prr/8028539/
The trigger for the bug is that there is a translate component on the
graphics
which overflows what can be stored in a integer, and the native code we
reach
cannot handle this.
Although the sofware
The fix looks fine. Isn't there a timeout you can set on the unit test
rather than rolling your own inside the test? Also, even if you
interrupt the test, if the failure mode is an infinite loop in native
code then the VM you are running in is probably not going to be happy.
That only
I can add othervm but each VM invocation slows down the
overall testing time and I'd like to think this only will be run on
versions that do not have the bug.
I added the custom time out code so that I was not reliant on the
harness to test.
Certainly I can delete all of that and just go to
That looks good. You bring up good points as well. The main thing I
was worried about is hanging an automated regression test run if there
is ever a regression...
...jim
On 10/27/14 2:49 PM, Phil Race wrote:
I can add othervm but each VM invocation slows down the
overall
