Re: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html

[Prasanta Sadhukhan]

+1

Regards
Prasanta
On 1/20/2017 12:33 PM, Jayathirth D V wrote:


Hello All,

Please review the following fix in JDK9 :

Bug : https://bugs.openjdk.java.net/browse/JDK-8173064

Webrev : http://cr.openjdk.java.net/~jdv/8173064/webrev.00/ 



Html : http://cr.openjdk.java.net/~jdv/8173064/package.html 



Issue : There was extra  tag present in package.html which will 
cause problems in html documentation.


Solution : Removed the extra  tag.

Thanks,

Jay

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html

[Ambarish Rapte]

Hi Jay,

The change looks good to me.

 

Regards,

Ambarish

 

From: Jayathirth D V 
Sent: Friday, January 20, 2017 12:33 PM
To: 2d-dev@openjdk.java.net
Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected  tag in 
javax/imageio/plugins/tiff/package.html

 

Hello All,

 

Please review the following fix in JDK9 :

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8173064 

Webrev : http://cr.openjdk.java.net/~jdv/8173064/webrev.00/ 

Html : http://cr.openjdk.java.net/~jdv/8173064/package.html 

 

Issue : There was extra  tag present in package.html which will cause 
problems in html documentation.

Solution : Removed the extra  tag.

 

Thanks,

Jay

[OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html

[Jayathirth D V]

Hello All,

 

Please review the following fix in JDK9 :

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8173064 

Webrev : http://cr.openjdk.java.net/~jdv/8173064/webrev.00/ 

Html : http://cr.openjdk.java.net/~jdv/8173064/package.html 

 

Issue : There was extra  tag present in package.html which will cause 
problems in html documentation.

Solution : Removed the extra  tag.

 

Thanks,

Jay

Re: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X

[dmitry markov]

Hi Prasanta,
Thank you for your feedback.

Actually there are two problems here: JDK-8163889 
 is devoted to the 
crash/assert error and 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 
.


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

Re: [OpenJDK 2D-Dev] RFR: 8172999: Crash on Windows getting FontMetrics since JDK 9 b96

[Vadim Pakhnushev]

Looks good.

On 19.01.2017 2:08, Phil Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8172999
Webrev: http://cr.openjdk.java.net/~prr/8172999/

fix for a crash on windows.

-phil.

Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods

[Jayathirth D V]

Hello All,

After getting feedback from Joe in CCC I have made changes to the code to 
reflect Joe's suggestions.

For ColorModel class I have just added identity-is-equality equals().
For its subclasses like IndexColorModel, PackedColorModel & 
ComponentColorModel, I have added instanceOf checks and checking all fields for 
equality. Since we are not checking any fields in ColorModel, in subclasses 
there will be redundant checks.
DirectColorModel has no unique properties to check so it will be using 
PackedColorModel equals() and hashCode().

Please review the updated code at your convenience:
http://cr.openjdk.java.net/~jdv/7107905/webrev.14/ 

Thanks,
Jay

-Original Message-
From: Jim Graham 
Sent: Friday, July 22, 2016 3:15 AM
To: Jayathirth D V; Philip Race
Cc: 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel 
subclasses are missing hashCode() or equals() or both methods

Looks good to me...

...jim

On 07/20/2016 09:53 AM, Jayathirth D V wrote:
> Hi Jim,
>
> Thanks for your input.
> I have updated specification of ColorModel and its subclasses.
> Please find new webrev for review:
> http://cr.openjdk.java.net/~jdv/7107905/webrev.13/
>
> Thanks,
> Jay
>
> -Original Message-
> From: Jim Graham
> Sent: Tuesday, July 12, 2016 7:41 PM
> To: Jayathirth D V; Philip Race
> Cc: 2d-dev@openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: 
> ColorModel subclasses are missing hashCode() or equals() or both 
> methods
>
> Hi Jay,
>
> When I write javadoc suggestions I sometimes use the short-hand "{some text}" 
> to indicate that it should be formatted using javadoc protocols, typically 
> that expands to "{@code some text}", but sometimes a link may be appropriate. 
>  It looks like you copied and pasted a number of places where I wrote "{foo}" 
> in email and just left the bare braces there, please adjust those (most of 
> them should probably just have "@code" inserted.
>
> In ColorModel.equals(), I'd replace the entire "following properties" 
> sentence with:
>
> * Subclasses may check additional properties, but this method
> * will check the following basic properties for equivalence to
> * determine if the target object equals this object:
>
> The text for IndexColorModel is also a little odd.  I'd change it to 
> something like:
>
> * The target object and this object will be equal iff
> * {@link ColorModel#equals()} returns true and the following
> * properties are also the same:
>
> For Packed:
>
> * The target object and this object will be equal iff
> * {@link ColorModel#equals()} returns true and the masks
> * of the color and alpha samples are the same.
>
> In terms of Joe's request, I'd add the following text to ColorModel.equals() 
> right after we talk about all of the properties that it checks:
>
> * 
> * Subclasses should override this method if they have any additional
> * properties to compare and should use the following implementation.
> * Note that the base {@code ColorModel} class already ensures that
> * the target object is the same class as this object so the cast to
> * the subclass type can be assumed if {@code super.equals(obj)} 
> returns
> * true.
> * 
> * public boolean equals(Object obj) {
> * if (!super.equals(obj)) {
> * return false;
> * }
> * MyCMClass cm = (MyCMClass) obj;
> * // test additional properties on "cm" and "this"
> * }
> * 
>
>
> On 7/1/16 3:31 AM, Jayathirth D V wrote:
>> Hi Jim,
>>
>> Thanks for your inputs.
>> I have discussed with Phil also regarding the same issue offline.
>> I have collated all the changes mentioned by you and Phil in the latest 
>> webrev:
>> http://cr.openjdk.java.net/~jdv/7107905/webrev.12/
>>
>> But I was not able to understand your statement - "Arguably, we could omit 
>> the class comparison text from the subclasses as well by using a reference 
>> like that, but I think that the class equivalence test is enough out of the 
>> ordinary that it does bear reiterating it in every subclass as you already 
>> do now even though we only reference the specific other properties tested by 
>> a reference.", please clarify.
>>
>> Also I am not able find a way to describe Joe's concern of "The ColorModel 
>> equals and hashCode methods should spell out the protocol subclasses need to 
>> follow to obey the respective contracts of methods.", I have discussed with 
>> Phil also regarding the same offline. Any inputs on this also would be 
>> helpful.
>>
>> Thanks,
>> Jay
>>
>> -Original Message-
>> From: Jim Graham
>> Sent: Thursday, June 30, 2016 4:05 AM
>> To: Jayathirth D V; Philip Race; 2d-dev@openjdk.java.net
>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905:
>> ColorModel subclasses are missing hashCode() or equals() or both 
>> methods
>>
>> Hi Jay,
>>
>> We need to reference the properties from the base class in the subclasses.  
>> We don't need to