Hi All,
Please review a fix for jdk9 which is a continuation of the fix of
JDK-6543815.
Bug: https://bugs.openjdk.java.net/browse/JDK-6601097
webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/
6543815 fix resets the x,y to 0 if they are negative before creating a
MediaPrintabl
Hello,
Could you review a simple fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8157322
webrev: http://cr.openjdk.java.net/~dmarkov/8157322/webrev.00/
Fixed several typos in client libraries javadoc.
Thanks,
Dmitry
Hi Prasanta,
Changes are working fine. +1.
Thanks,
Jay
-Original Message-
From: Phil Race
Sent: Thursday, May 19, 2016 3:53 AM
To: prasanta sadhukhan; 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6509729:
javax.print.ServiceUI.printDialog Border/Margin Evaluation i
Hello Dmitry
Looks just great!
Thanks
alexp
On 5/19/2016 13:35, dmitry markov wrote:
Hello,
Could you review a simple fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8157322
webrev: http://cr.openjdk.java.net/~dmarkov/8157322/webrev.00/
Fixed several typos in cl
Hi, Dmitry.
Looks fine, but can you please maintain 80 chars per line in the files
where this rule was applied already(UnsupportedAudioFileException.java
for example). It is not necessary to send a new webrev.
On 19.05.16 13:35, dmitry markov wrote:
Hello,
Could you review a simple fix for j
Hi Sergey,
Thank you for the review. I will update the fix based on your suggestion.
Thanks,
Dmitry
On 19/05/2016 14:24, Sergey Bylokhov wrote:
Hi, Dmitry.
Looks fine, but can you please maintain 80 chars per line in the files
where this rule was applied already(UnsupportedAudioFileException.j
Hi,
Previously for this bug we were making changes related only to IndexColorModel.
Since we are expanding to include hashCode() or equals() method from
PackedColorModel and ComponentColorModel, I have created single webrev for
review under the same bug id.
Now the "getclass()==" check is pres
Hi Brian,
I think the change looks fine.
However I want confirm the reason for the check "type == TIFFTag.LONG"
besides type == TIFFTag.TIFF_IFD_POINTER .
>From this http://partners.adobe.com/public/developer/en/tiff/TIFFPM6.pdf. , it
>is clear that IFD /LONG type can be used for the
Hi Bharath,
On May 19, 2016, at 11:06 AM, Bluv Nallakaluva
wrote:
> I think the change looks fine.
>
> However I want confirm the reason for the check “type == TIFFTag.LONG”
> besides type == TIFFTag.TIFF_IFD_POINTER .
> From this http://partners.adobe.com/public/developer/en/tiff/TIFFPM6
The webrev has been updated here
http://cr.openjdk.java.net/~bpb/8149815/webrev.01/
and is in need of review.
Thanks,
Brian
On May 19, 2016, at 12:45 PM, Brian Burkhalter
wrote:
> I’ll update the webrev.
10 matches
Mail list logo