From alexander.zuev at oracle.com  Mon Mar  2 18:31:36 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Mon, 2 Mar 2020 21:31:36 +0300
Subject: [OpenJDK 2D-Dev] <Swing Dev> [15] Review Request: 8237746
 Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
References: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
 <C234EDBB-20AA-4921-9836-0F9F1F2AF4B5@mountainminds.com>
 <e199e3ef-f2a8-81b7-9714-dc1f9d07cc39@oracle.com>
 <FBD35B62-ED3D-4C05-9147-60F08E4E3774@mountainminds.com>
 <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
Message-ID: <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com>

Looks much better. I would double the proposal of creating the separate 
issue for bringing formatting in different files to the same coding 
standard. Seeing different spacing on cycles and method invocations in 
different classes makes me cringe. But functionally it seems everything 
is fine.

/Alex

On 22-Feb-20 12:50, Sergey Bylokhov wrote:
> Thank you, an updated version is upload:
> http://cr.openjdk.java.net/~serb/8237746/webrev.01
>
> On 2/17/20 11:55 am, Marc Hoffmann wrote:
>> Thanks Alexey for the detailed review! I attached a updated version.
>>
>> The examples have many cleanup opportunities. I wanted to focus on 
>> compiler warnings for now and keep the changeset minimal.
>>
>>
>>> *Font2DTest.java*
>>> 674???????? if ( selectedText == fp.USER_TEXT )
>>> 675?????????? userTextDialog.setVisible(true);
>>> 676???????? else
>>> 677?????????? userTextDialog.setVisible(false);
>>>
>>> I'd put the braces around and indent the statements by 4 spaces.
>>> However, it's the style used throughout the file: if there's only 
>>> one statement, there are no braces and the statement is indented by 
>>> 2 spaces rather than 4. Probably, to keep the code consistent, it's 
>>> better to leave it as is.
>>>
>>> 797???????????? else
>>> 798?????????????? fontInfoDialog.setVisible(false);
>>
>> Maybe separate issue for formatting?
>>
>>>
>>> *FontPanel.java*
>>> 1248??????????? if (valArray == null) {
>>> 1249??????????????? valArray = 
>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>> 1250??????????? }
>>> 1259??????????? if (valArray == null) {
>>> 1260??????????????? valArray = 
>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>> 1261??????????? }
>>> Can it be replaced with FMValues.values() as you did in 
>>> Font2DTest.java lines 153, 156?
>>>
>>> And below
>>> 1311??????????????? valArray = 
>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>> 1324??????????????? valArray = 
>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>
>> Done.
>>
>>>
>>> *ButtonDemo.java*
>>> 64???? Vector<Component> buttons = new Vector<>();
>>> Shall it be JComponent?
>>
>> Doesn?t because JPanel.add() returns Component:
>>
>> ???? buttons.add(p2.add(new JButton(getString("ButtonDemo.button1"))));
>>
>> Should I introduce a local variable?
>>
>>>
>>>
>>> *ComboBoxDemo.java*
>>> 60???? JComboBox<?> hairCB;
>>> Why not JComboBox<String> ?
>>> All createXXX methods use this type.
>>> Then the cast below would be unnecessary:
>>> 282???????????? String name = (String) 
>>> parts.get(hairCB.getSelectedItem());
>>
>> This comes from the lookup in the parts Hashtable. Unfortunately it 
>> has String an ImageIcon values.
>>
>>>
>>>
>>> 114???????? presetCB = (JComboBox<?>) 
>>> comboBoxPanel.add(createPresetComboBox());
>>> To avoid cast, you can use two statements:
>>> presetCB = createPresetComboBox();
>>> comboBoxPanel.add(presetCB);
>>
>> Done for all 4 occurrences.
>>
>>>
>>>
>>> *DirectionPanel.java*
>>> 97???????????????? AbstractButton b = e.nextElement();
>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>> Indentation on line 97 seems incorrect, it should align to line 98, 
>>> shouldn't it?
>>
>> Done (replace tab with spaces).
>>
>>>
>>>
>>> *SliderDemo.java*
>>> 167???????? @SuppressWarnings("unchecked")
>>> 168???????????????? Dictionary<Object, Object> labelTable = 
>>> s.getLabelTable();
>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>> I mean that @SuppressWarning would become unnecessary.
>>
>> Dictionary<?,?> does not allow put of specific types in the next 
>> line. But fixed tabs in the same line.
>>
>>>
>>>
>>> *SplitPaneDemo.java*
>>> 168 
>>> divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); 
>>>
>>> can be simplified to
>>> divSize.setText(Integer.toString(splitPane.getDividerSize()));
>>> by using static method Integer.toString() method.
>>
>> Done.
>>
>>>
>>>
>>> Shall the copyright year be updated in all the modified files?
>>
>> Please let me know what would be the correct process.
>>
>> Cheers,
>> -marc
>>
>>
>>
>>
>>> On 17. Feb 2020, at 15:40, Alexey Ivanov <alexey.ivanov at oracle.com> 
>>> wrote:
>>>
>>> Thank you, Marc, for your contribution.
>>> And thank you to Sergey for creating the review.
>>>
>>> *Font2DTest.java*
>>> 674???????? if ( selectedText == fp.USER_TEXT )
>>> 675?????????? userTextDialog.setVisible(true);
>>> 676???????? else
>>> 677?????????? userTextDialog.setVisible(false);
>>>
>>> I'd put the braces around and indent the statements by 4 spaces.
>>> However, it's the style used throughout the file: if there's only 
>>> one statement, there are no braces and the statement is indented by 
>>> 2 spaces rather than 4. Probably, to keep the code consistent, it's 
>>> better to leave it as is.
>>>
>>> 797???????????? else
>>> 798?????????????? fontInfoDialog.setVisible(false);
>>>
>>>
>>> *FontPanel.java*
>>> 1248??????????? if (valArray == null) {
>>> 1249??????????????? valArray = 
>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>> 1250??????????? }
>>> 1259??????????? if (valArray == null) {
>>> 1260??????????????? valArray = 
>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>> 1261??????????? }
>>> Can it be replaced with FMValues.values() as you did in 
>>> Font2DTest.java lines 153, 156?
>>>
>>> And below
>>> 1311??????????????? valArray = 
>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>> 1324??????????????? valArray = 
>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>
>>>
>>> *ButtonDemo.java*
>>> 64???? Vector<Component> buttons = new Vector<>();
>>> Shall it be JComponent?
>>>
>>>
>>> *ComboBoxDemo.java*
>>> 60???? JComboBox<?> hairCB;
>>> Why not JComboBox<String> ?
>>> All createXXX methods use this type.
>>> Then the cast below would be unnecessary:
>>> 282???????????? String name = (String) 
>>> parts.get(hairCB.getSelectedItem());
>>>
>>>
>>> 114???????? presetCB = (JComboBox<?>) 
>>> comboBoxPanel.add(createPresetComboBox());
>>> To avoid cast, you can use two statements:
>>> presetCB = createPresetComboBox();
>>> comboBoxPanel.add(presetCB);
>>>
>>>
>>> *DirectionPanel.java*
>>> 97???????????????? AbstractButton b = e.nextElement();
>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>> Indentation on line 97 seems incorrect, it should align to line 98, 
>>> shouldn't it?
>>>
>>>
>>> *SliderDemo.java*
>>> 167???????? @SuppressWarnings("unchecked")
>>> 168???????????????? Dictionary<Object, Object> labelTable = 
>>> s.getLabelTable();
>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>> I mean that @SuppressWarning would become unnecessary.
>>>
>>>
>>> *SplitPaneDemo.java*
>>> 168 
>>> divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); 
>>>
>>> can be simplified to
>>> divSize.setText(Integer.toString(splitPane.getDividerSize()));
>>> by using static method Integer.toString() method.
>>>
>>>
>>> Shall the copyright year be updated in all the modified files?
>>>
>>>
>>> On 23/01/2020 08:54, Marc Hoffmann wrote:
>>>> Hi Sergey,
>>>>
>>>> thanks for sponsoring this patch!
>>>>
>>>> I successfully applied the webrev patch on current JDK head 
>>>> (57807:7bae17e00566). The build runs without warnings on the demo 
>>>> code :)
>>>>
>>>> But I noticed a minor glitch: I inserted a tab in 
>>>> src/demo/share/jfc/SwingSet2/DirectionPanel.java Line 97 where only 
>>>> spaces are used in the rest of the file. Probably this should be 
>>>> fixed before merge.
>>>>
>>>> Regards,
>>>> -marc
>>>>
>>>>
>>>>> On 23. Jan 2020, at 01:35, Sergey Bylokhov 
>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>
>>>>> Hello.
>>>>> Please review the fix for compiler warnings in the demo/jfc in JDK 
>>>>> 15.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237746
>>>>> Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00
>>>>>
>>>>> This fix contributed by the Marc Hoffmann:
>>>>> https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html 
>>>>>
>>>>>
>>>>> Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs.
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>> -- 
>>> Regards,
>>> Alexey
>>
>>
>>
>>
>
>


From christoph.langer at sap.com  Mon Mar  2 20:07:46 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 2 Mar 2020 20:07:46 +0000
Subject: [OpenJDK 2D-Dev] RFR 8239149: Cleanups in SunFontManager.java
 and TrueTypeFont.java
In-Reply-To: <e7ba52c8-6ecd-c722-312e-d568054a7a8d@oracle.com>
References: <AM0PR02MB571441A65CB20F74DE999BD08A160@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <e7ba52c8-6ecd-c722-312e-d568054a7a8d@oracle.com>
Message-ID: <AM0PR02MB57144A82D468343CF1480DB08AE70@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Phil,

thanks for the review. I pushed to jdk-client: http://hg.openjdk.java.net/jdk/client/rev/5cc32ff976fe

Best regards
Christoph

From: Phil Race <philip.race at oracle.com>
Sent: Dienstag, 25. Februar 2020 00:49
To: Langer, Christoph <christoph.langer at sap.com>; 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] RFR 8239149: Cleanups in SunFontManager.java and TrueTypeFont.java


This is OK. I think a lot of the generics were written at a time which pre-dated
the diamond operator in JDK 7.

using sun.security.action - something in java.base is something we should
clean up some day, but you are just changing the way it is referenced and
it is on my clean up list so OK.

Please do push to jdk/client.

-phil.
On 2/17/20 1:57 AM, Langer, Christoph wrote:
Hi,

I did some cleanups in src/java.desktop/share/classes/sun/font/SunFontManager.java and src/java.desktop/share/classes/sun/font/TrueTypeFont.java which I?d like to contribute.

Most is about indentation, generics initialization and better usage of AccessController::doPrivileged and friends. Also, some unused imports and locals were removed/commented out.

Please review ??

Bug: https://bugs.openjdk.java.net/browse/JDK-8239149
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8239149.0/

Best regards
Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200302/3f491001/attachment-0001.htm>

From Sergey.Bylokhov at oracle.com  Thu Mar  5 00:51:12 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 4 Mar 2020 16:51:12 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8219578 No associated icon for the leaf node
	of Jtree
Message-ID: <bd85d476-981e-98fa-7b8c-0841e6500c87@oracle.com>

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8219578
CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00

The fix clarifies the status of the links to external
resources in the documentation

-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Mar  5 01:07:22 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 04 Mar 2020 17:07:22 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8219578 No associated icon for
 the leaf node of Jtree
In-Reply-To: <bd85d476-981e-98fa-7b8c-0841e6500c87@oracle.com>
References: <bd85d476-981e-98fa-7b8c-0841e6500c87@oracle.com>
Message-ID: <5E6050CA.2050904@oracle.com>

I suggest changing

+ * The documentation in this module includes links to overviews, tutorials,
+ * examples, guides, and other documentation. This is done for convenience.
+ * Information at these external resources is not part of JavaSE API
+ * Specification.

to

+ * The documentation in this module includes links to external overviews, tutorials,
+ * examples, guides, media format specifications, and other similar documentation.
+ * These links are meant to be informative to the reader and nothing more.
+ * Information at these external resources, no matter the hosting or the author,
+ * is not part of Java Platform API  specification unless explicitly stated to be so.

I wouldn't be surprised if the CSR process generates some more tweaks.

-phil.

On 3/4/20, 4:51 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578
> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00
>
> The fix clarifies the status of the links to external
> resources in the documentation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200304/291964d1/attachment.htm>

From Sergey.Bylokhov at oracle.com  Thu Mar  5 01:37:09 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 4 Mar 2020 17:37:09 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8219578 No associated icon for
 the leaf node of Jtree
In-Reply-To: <5E6050CA.2050904@oracle.com>
References: <bd85d476-981e-98fa-7b8c-0841e6500c87@oracle.com>
 <5E6050CA.2050904@oracle.com>
Message-ID: <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com>

webrev and CSR are updated:

Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01
CSR: https://bugs.openjdk.java.net/browse/JDK-8240554

On 3/4/20 5:07 pm, Philip Race wrote:
> I suggest changing + * The documentation in this module includes links to overviews, tutorials,
> + * examples, guides, and other documentation. This is done for convenience.
> + * Information at these external resources is not part of JavaSE API
> + * Specification.
> 
> to
> 
> + * The documentation in this module includes links to external overviews, tutorials,
> + * examples, guides, media format specifications, and other similar documentation.
> + * These links are meant to be informative to the reader and nothing more.
> + * Information at these external resources, no matter the hosting or the author, + * is not part of Java Platform APIspecification unless explicitly stated to be so. I wouldn't be surprised if the CSR process generates some more tweaks.
> 
> -phil.
> 
> On 3/4/20, 4:51 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
>> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00
>>
>> The fix clarifies the status of the links to external
>> resources in the documentation
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Mar  5 01:55:50 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 04 Mar 2020 17:55:50 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8219578 No associated icon for
 the leaf node of Jtree
In-Reply-To: <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com>
References: <bd85d476-981e-98fa-7b8c-0841e6500c87@oracle.com>
 <5E6050CA.2050904@oracle.com>
 <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com>
Message-ID: <5E605C26.3060104@oracle.com>

OK. CSR is reviewed.

-phil.

On 3/4/20, 5:37 PM, Sergey Bylokhov wrote:
> webrev and CSR are updated:
>
> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01
> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
>
> On 3/4/20 5:07 pm, Philip Race wrote:
>> I suggest changing + * The documentation in this module includes 
>> links to overviews, tutorials,
>> + * examples, guides, and other documentation. This is done for 
>> convenience.
>> + * Information at these external resources is not part of JavaSE API
>> + * Specification.
>>
>> to
>>
>> + * The documentation in this module includes links to external 
>> overviews, tutorials,
>> + * examples, guides, media format specifications, and other similar 
>> documentation.
>> + * These links are meant to be informative to the reader and nothing 
>> more.
>> + * Information at these external resources, no matter the hosting or 
>> the author, + * is not part of Java Platform APIspecification unless 
>> explicitly stated to be so. I wouldn't be surprised if the CSR 
>> process generates some more tweaks.
>>
>> -phil.
>>
>> On 3/4/20, 4:51 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk/client.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
>>> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00
>>>
>>> The fix clarifies the status of the links to external
>>> resources in the documentation
>>>
>
>

From Sergey.Bylokhov at oracle.com  Thu Mar  5 09:04:58 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 5 Mar 2020 01:04:58 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8240518: Incorrect
 JNU_ReleaseStringPlatformChars in Windows Print
In-Reply-To: <OF3D877DBA.48A66CC3-ON00258521.0045FE78-49258521.00465A47@notes.na.collabserv.com>
References: <OF3D877DBA.48A66CC3-ON00258521.0045FE78-49258521.00465A47@notes.na.collabserv.com>
Message-ID: <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>

(CC) 2d-dev,

Looks fine.

On 3/4/20 4:48 am, Toshio 5 Nakamura wrote:
> Hi,
> 
> I'd like to ask review and sponsor of this fix.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8240518
> Fix: http://cr.openjdk.java.net/~tnakamura/8240518/webrev.00
> 
> Eclipse OpenJ9 VM detects two errors about JNU_ReleaseStringPlatformChars in WPrinterJob.cpp.
> Then, I checked similar situation in the folder, and found one lacking of the release method in awt_PrintControl.cpp.
> 
> Best regards,
> 
> Toshio Nakamura
> 


-- 
Best regards, Sergey.

From jayathirth.d.v at oracle.com  Thu Mar  5 09:17:58 2020
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 5 Mar 2020 01:17:58 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <Swing Dev> <AWT Dev> RFR: 8219578 No
 associated icon for the leaf node of Jtree
In-Reply-To: <5E605C26.3060104@oracle.com>
References: <bd85d476-981e-98fa-7b8c-0841e6500c87@oracle.com>
 <5E6050CA.2050904@oracle.com>
 <465eaf39-06ab-637a-94bc-80bab18557bd@oracle.com>
 <5E605C26.3060104@oracle.com>
Message-ID: <446d6a93-b6d9-42b4-8790-9bc613bda3f6@default>

Change looks good to me.

Thanks,
Jay

-----Original Message-----
From: Philip Race 
Sent: Thursday, March 5, 2020 7:26 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> <AWT Dev> RFR: 8219578 No associated icon for the leaf node of Jtree

OK. CSR is reviewed.

-phil.

On 3/4/20, 5:37 PM, Sergey Bylokhov wrote:
> webrev and CSR are updated:
>
> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01
> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
>
> On 3/4/20 5:07 pm, Philip Race wrote:
>> I suggest changing + * The documentation in this module includes 
>> links to overviews, tutorials,
>> + * examples, guides, and other documentation. This is done for
>> convenience.
>> + * Information at these external resources is not part of JavaSE API
>> + * Specification.
>>
>> to
>>
>> + * The documentation in this module includes links to external
>> overviews, tutorials,
>> + * examples, guides, media format specifications, and other similar
>> documentation.
>> + * These links are meant to be informative to the reader and nothing
>> more.
>> + * Information at these external resources, no matter the hosting or
>> the author, + * is not part of Java Platform APIspecification unless 
>> explicitly stated to be so. I wouldn't be surprised if the CSR 
>> process generates some more tweaks.
>>
>> -phil.
>>
>> On 3/4/20, 4:51 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk/client.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219578
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
>>> Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.00
>>>
>>> The fix clarifies the status of the links to external resources in 
>>> the documentation
>>>
>
>

From prasanta.sadhukhan at oracle.com  Thu Mar  5 09:21:51 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 5 Mar 2020 14:51:51 +0530
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8240518: Incorrect
 JNU_ReleaseStringPlatformChars in Windows Print
In-Reply-To: <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>
References: <OF3D877DBA.48A66CC3-ON00258521.0045FE78-49258521.00465A47@notes.na.collabserv.com>
 <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>
Message-ID: <7f85ff77-ee9e-dad6-d2c6-280ea75e008d@oracle.com>

+1

Regards
Prasanta
On 05-Mar-20 2:34 PM, Sergey Bylokhov wrote:
> (CC) 2d-dev,
>
> Looks fine.
>
> On 3/4/20 4:48 am, Toshio 5 Nakamura wrote:
>> Hi,
>>
>> I'd like to ask review and sponsor of this fix.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8240518
>> Fix: http://cr.openjdk.java.net/~tnakamura/8240518/webrev.00
>>
>> Eclipse OpenJ9 VM detects two errors about 
>> JNU_ReleaseStringPlatformChars in WPrinterJob.cpp.
>> Then, I checked similar situation in the folder, and found one 
>> lacking of the release method in awt_PrintControl.cpp.
>>
>> Best regards,
>>
>> Toshio Nakamura
>>
>
>

From pankaj.b.bansal at oracle.com  Thu Mar  5 09:22:43 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 5 Mar 2020 01:22:43 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8240518: Incorrect
 JNU_ReleaseStringPlatformChars in Windows Print
In-Reply-To: <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>
References: <OF3D877DBA.48A66CC3-ON00258521.0045FE78-49258521.00465A47@notes.na.collabserv.com>
 <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>
Message-ID: <fe5653ff-c902-413d-b1c6-0ed4e213af4a@default>

Looks good to me

-Pankaj

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, March 5, 2020 2:35 PM
To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>; awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: <AWT Dev> RFR: 8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print

(CC) 2d-dev,

Looks fine.

On 3/4/20 4:48 am, Toshio 5 Nakamura wrote:
> Hi,
> 
> I'd like to ask review and sponsor of this fix.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8240518
> Fix: http://cr.openjdk.java.net/~tnakamura/8240518/webrev.00
> 
> Eclipse OpenJ9 VM detects two errors about JNU_ReleaseStringPlatformChars in WPrinterJob.cpp.
> Then, I checked similar situation in the folder, and found one lacking of the release method in awt_PrintControl.cpp.
> 
> Best regards,
> 
> Toshio Nakamura
> 


-- 
Best regards, Sergey.

From JAYATHIRTH.D.V at ORACLE.COM  Thu Mar  5 10:12:31 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Thu, 5 Mar 2020 15:42:31 +0530
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws misleading
 exception with truncated images
Message-ID: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>

Hello All,

Please review the following fix for JDK 15:

Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.00/> 

Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
Solution : Handle cases where we reach EOF and throw appropriate exception.

Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200305/173f72c5/attachment.htm>

From brian.burkhalter at oracle.com  Thu Mar  5 16:50:03 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 5 Mar 2020 08:50:03 -0800
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
Message-ID: <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>

Hello Jay,

The source fix looks OK to me. I get the same exception as in the bug description when I run the test against my unpatched local JDK 15 build.

Thanks,

Brian

> On Mar 5, 2020, at 2:12 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM> wrote:
> 
> Please review the following fix for JDK 15:
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.00/> 
> 
> Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
> Solution : Handle cases where we reach EOF and throw appropriate exception.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200305/b9bebdf5/attachment.htm>

From JAYATHIRTH.D.V at ORACLE.COM  Thu Mar  5 17:18:09 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Thu, 5 Mar 2020 22:48:09 +0530
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
Message-ID: <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>

Hello Brian,

Thanks for the review. GIF stream in regression test case would match warn.gif stream behaviour that?s why it going into GIFImageReader.getCode().

Are you okay with overall webrev.00 patch or have you just approved GIFImageReader change? Please clarify.

Regards,
Jay

> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hello Jay,
> 
> The source fix looks OK to me. I get the same exception as in the bug description when I run the test against my unpatched local JDK 15 build.
> 
> Thanks,
> 
> Brian
> 
>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>> 
>> Please review the following fix for JDK 15:
>> 
>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.00/> 
>> 
>> Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
>> Solution : Handle cases where we reach EOF and throw appropriate exception.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200305/0ac91f4c/attachment.htm>

From brian.burkhalter at oracle.com  Thu Mar  5 20:35:36 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 5 Mar 2020 12:35:36 -0800
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
 <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
Message-ID: <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>

Hi Jay,

I think the overall change is fine.

Regards,

Brian

> On Mar 5, 2020, at 9:18 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM> wrote:
> 
> Hello Brian,
> 
> Thanks for the review. GIF stream in regression test case would match warn.gif stream behaviour that?s why it going into GIFImageReader.getCode().
> 
> Are you okay with overall webrev.00 patch or have you just approved GIFImageReader change? Please clarify.
> 
> Regards,
> Jay
> 
>> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>> 
>> Hello Jay,
>> 
>> The source fix looks OK to me. I get the same exception as in the bug description when I run the test against my unpatched local JDK 15 build.
>> 
>> Thanks,
>> 
>> Brian
>> 
>>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>> 
>>> Please review the following fix for JDK 15:
>>> 
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
>>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.00/> 
>>> 
>>> Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
>>> Solution : Handle cases where we reach EOF and throw appropriate exception.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200305/02c3cc93/attachment.htm>

From TOSHIONA at jp.ibm.com  Fri Mar  6 00:40:38 2020
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Fri, 6 Mar 2020 09:40:38 +0900
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8240518: Incorrect
 JNU_ReleaseStringPlatformChars in Windows Print
In-Reply-To: <fe5653ff-c902-413d-b1c6-0ed4e213af4a@default>
References: <OF3D877DBA.48A66CC3-ON00258521.0045FE78-49258521.00465A47@notes.na.collabserv.com>
 <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>
 <fe5653ff-c902-413d-b1c6-0ed4e213af4a@default>
Message-ID: <OF27FB8484.F898C0CE-ON00258523.000348C4-49258523.0003B864@notes.na.collabserv.com>


Hi Sergey, Prasanta, Pankaj,

Thank you for the review. May I ask a sponsor of the fix as well?
I'm not a committer.

Best Regards,
Toshio Nakamura

Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote on 2020/03/05 18:22:43:

> From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>, awt-
> dev at openjdk.java.net, 2d-dev <2d-dev at openjdk.java.net>
> Date: 2020/03/05 18:22
> Subject: [EXTERNAL] RE: <AWT Dev> RFR: 8240518: Incorrect
> JNU_ReleaseStringPlatformChars in Windows Print
>
> Looks good to me
>
> -Pankaj
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, March 5, 2020 2:35 PM
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>; awt-
> dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: <AWT Dev> RFR: 8240518: Incorrect
> JNU_ReleaseStringPlatformChars in Windows Print
>
> (CC) 2d-dev,
>
> Looks fine.
>
> On 3/4/20 4:48 am, Toshio 5 Nakamura wrote:
> > Hi,
> >
> > I'd like to ask review and sponsor of this fix.
> >
> > Issue:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8240518&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=Ugr81mDyW3UBisxHYIBGJRn59YtU54N94eZ3qym_AxI&s=aiMA0Y77aGl1__RhHjtvahZ0wWG8fG0G4BgFOcpvrPY&e=

> > Fix:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8240518_webrev.00&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw&m=Ugr81mDyW3UBisxHYIBGJRn59YtU54N94eZ3qym_AxI&s=YaighmfLyolNRz8ORpStjqHH1p4KX8d4g_AwsY0GPHk&e=

> >
> > Eclipse OpenJ9 VM detects two errors about
> JNU_ReleaseStringPlatformChars in WPrinterJob.cpp.
> > Then, I checked similar situation in the folder, and found one
> lacking of the release method in awt_PrintControl.cpp.
> >
> > Best regards,
> >
> > Toshio Nakamura
> >
>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200306/c386edfc/attachment-0001.htm>

From JAYATHIRTH.D.V at ORACLE.COM  Fri Mar  6 02:15:01 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Fri, 6 Mar 2020 07:45:01 +0530
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
 <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
 <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>
Message-ID: <DE688F8F-6F72-4F8F-B024-CA2B754E1394@ORACLE.COM>

Hi Brian,

Thanks for the clarification and approval.

@Others : Need one more review please take a look.

Regards,
Jay 

> On 06-Mar-2020, at 2:05 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Jay,
> 
> I think the overall change is fine.
> 
> Regards,
> 
> Brian
> 
>> On Mar 5, 2020, at 9:18 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>> 
>> Hello Brian,
>> 
>> Thanks for the review. GIF stream in regression test case would match warn.gif stream behaviour that?s why it going into GIFImageReader.getCode().
>> 
>> Are you okay with overall webrev.00 patch or have you just approved GIFImageReader change? Please clarify.
>> 
>> Regards,
>> Jay
>> 
>>> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> 
>>> Hello Jay,
>>> 
>>> The source fix looks OK to me. I get the same exception as in the bug description when I run the test against my unpatched local JDK 15 build.
>>> 
>>> Thanks,
>>> 
>>> Brian
>>> 
>>>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>> 
>>>> Please review the following fix for JDK 15:
>>>> 
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
>>>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.00/> 
>>>> 
>>>> Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
>>>> Solution : Handle cases where we reach EOF and throw appropriate exception.
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200306/87dd0dc9/attachment.htm>

From philip.race at oracle.com  Fri Mar  6 02:52:32 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 05 Mar 2020 18:52:32 -0800
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <DE688F8F-6F72-4F8F-B024-CA2B754E1394@ORACLE.COM>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
 <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
 <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>
 <DE688F8F-6F72-4F8F-B024-CA2B754E1394@ORACLE.COM>
Message-ID: <5E61BAF0.9020604@oracle.com>

I don't understand why you need to recheck that left > 0.
Nothing can change it between the while loop check and your check

                      while (left > 0) {
                          int nbytes = stream.read(block, off, left);
+                        if (nbytes == -1 && left > 0) {
+                            throw new IIOException("Invalid block 
length for " +
+                                    "LZW encoded image data");
+                        }
                          off += nbytes;
                          left -= nbytes;
                      }

Also in the test since you are printing

   51         } catch (IIOException e) {
   52             // do nothing we expect IIOException but we should not
   53             // throw IndexOutOfBoundsException
   54             System.out.println(e.toString());
   55             System.out.println("Caught IIOException ignore it");


Maybe add "Test passed" to be extra clear !

-phil.

On 3/5/20, 6:15 PM, Jayathirth D v wrote:
> Hi Brian,
>
> Thanks for the clarification and approval.
>
> @Others : Need one more review please take a look.
>
> Regards,
> Jay
>
>> On 06-Mar-2020, at 2:05 AM, Brian Burkhalter 
>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>
>> Hi Jay,
>>
>> I think the overall change is fine.
>>
>> Regards,
>>
>> Brian
>>
>>> On Mar 5, 2020, at 9:18 AM, Jayathirth D v 
>>> <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>
>>> Hello Brian,
>>>
>>> Thanks for the review. GIF stream in regression test case would 
>>> match warn.gif stream behaviour that?s why it going into 
>>> GIFImageReader.getCode().
>>>
>>> Are you okay with overall webrev.00 patch or have you just approved 
>>> GIFImageReader change? Please clarify.
>>>
>>> Regards,
>>> Jay
>>>
>>>> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter 
>>>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> 
>>>> wrote:
>>>>
>>>> Hello Jay,
>>>>
>>>> The source fix looks OK to me. I get the same exception as in the 
>>>> bug description when I run the test against my unpatched local JDK 
>>>> 15 build.
>>>>
>>>> Thanks,
>>>>
>>>> Brian
>>>>
>>>>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v 
>>>>> <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>>>
>>>>> Please review the following fix for JDK 15:
>>>>>
>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025
>>>>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Ejdv/6532025/webrev.00/>
>>>>>
>>>>> Root cause : When we have truncated GIF images, stream.read() 
>>>>> returns -1 but GIFImageReader doesn?t handle such conditions 
>>>>> properly and continues to read input stream data.
>>>>> Solution : Handle cases where we reach EOF and throw appropriate 
>>>>> exception.
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200305/56842638/attachment.htm>

From pankaj.b.bansal at oracle.com  Fri Mar  6 03:14:50 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 6 Mar 2020 03:14:50 +0000 (UTC)
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8240518: Incorrect
 JNU_ReleaseStringPlatformChars in Windows Print
In-Reply-To: <OF27FB8484.F898C0CE-ON00258523.000348C4-49258523.0003B864@notes.na.collabserv.com>
References: <OF3D877DBA.48A66CC3-ON00258521.0045FE78-49258521.00465A47@notes.na.collabserv.com>
 <3a6e8a61-dcbf-63db-690d-be5677428744@oracle.com>
 <fe5653ff-c902-413d-b1c6-0ed4e213af4a@default>
 <OF27FB8484.F898C0CE-ON00258523.000348C4-49258523.0003B864@notes.na.collabserv.com>
Message-ID: <dc3bd2c4-9e43-94c7-a1d5-7e740ac5d05e@oracle.com>

Hi Toshio,

I will commit this for you.

Regards,

Pankaj


On 06/03/20 6:10 AM, Toshio 5 Nakamura wrote:
>
> Hi Sergey, Prasanta, Pankaj,
>
> Thank you for the review. May I ask a sponsor of the fix as well?
> I'm not a committer.
>
> Best Regards,
> Toshio Nakamura
>
> Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote on 2020/03/05 18:22:43:
>
> > From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
> > To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>, awt-
> > dev at openjdk.java.net, 2d-dev <2d-dev at openjdk.java.net>
> > Date: 2020/03/05 18:22
> > Subject: [EXTERNAL] RE: <AWT Dev> RFR: 8240518: Incorrect
> > JNU_ReleaseStringPlatformChars in Windows Print
> >
> > Looks good to me
> >
> > -Pankaj
> >
> > -----Original Message-----
> > From: Sergey Bylokhov
> > Sent: Thursday, March 5, 2020 2:35 PM
> > To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>; awt-
> > dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
> > Subject: Re: <AWT Dev> RFR: 8240518: Incorrect
> > JNU_ReleaseStringPlatformChars in Windows Print
> >
> > (CC) 2d-dev,
> >
> > Looks fine.
> >
> > On 3/4/20 4:48 am, Toshio 5 Nakamura wrote:
> > > Hi,
> > >
> > > I'd like to ask review and sponsor of this fix.
> > >
> > > Issue: https://bugs.openjdk.java.net/browse/JDK-8240518
> > > Fix: http://cr.openjdk.java.net/~tnakamura/8240518/webrev.00 
> <http://cr.openjdk.java.net/%7Etnakamura/8240518/webrev.00>
> > >
> > > Eclipse OpenJ9 VM detects two errors about
> > JNU_ReleaseStringPlatformChars in WPrinterJob.cpp.
> > > Then, I checked similar situation in the folder, and found one
> > lacking of the release method in awt_PrintControl.cpp.
> > >
> > > Best regards,
> > >
> > > Toshio Nakamura
> > >
> >
> >
> > --
> > Best regards, Sergey.
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200306/1a466915/attachment-0001.htm>

From JAYATHIRTH.D.V at ORACLE.COM  Fri Mar  6 03:47:15 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Fri, 6 Mar 2020 09:17:15 +0530
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <5E61BAF0.9020604@oracle.com>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
 <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
 <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>
 <DE688F8F-6F72-4F8F-B024-CA2B754E1394@ORACLE.COM>
 <5E61BAF0.9020604@oracle.com>
Message-ID: <A52671D0-B116-43FB-9EED-1CC5FD8D10F2@ORACLE.COM>

Hi Phil,

Thanks for your inputs.

Yes we don?t need extra ?left > 0? check, I have removed it and I have updated the test case to print ?Test passed?.

Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/6532025/webrev.01/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.01/> 

I ran all imageio jtreg tests and there are no failures with updated change.

Thanks,
Jay

> On 06-Mar-2020, at 8:22 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I don't understand why you need to recheck that left > 0.
> Nothing can change it between the while loop check and your check
> 
>                      while (left > 0) {
>                          int nbytes = stream.read(block, off, left);
> +                        if (nbytes == -1 && left > 0) {
> +                            throw new IIOException("Invalid block length for " +
> +                                    "LZW encoded image data");
> +                        }
>                          off += nbytes;
>                          left -= nbytes;
>                      }
> 
> Also in the test since you are printing
>   51         } catch (IIOException e) {
>   52             // do nothing we expect IIOException but we should not
>   53             // throw IndexOutOfBoundsException
>   54             System.out.println(e.toString());
>   55             System.out.println("Caught IIOException ignore it");
> 
> Maybe add "Test passed" to be extra clear !
> 
> -phil.
> 
> On 3/5/20, 6:15 PM, Jayathirth D v wrote:
>> 
>> Hi Brian,
>> 
>> Thanks for the clarification and approval.
>> 
>> @Others : Need one more review please take a look.
>> 
>> Regards,
>> Jay 
>> 
>>> On 06-Mar-2020, at 2:05 AM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> 
>>> Hi Jay,
>>> 
>>> I think the overall change is fine.
>>> 
>>> Regards,
>>> 
>>> Brian
>>> 
>>>> On Mar 5, 2020, at 9:18 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>> 
>>>> Hello Brian,
>>>> 
>>>> Thanks for the review. GIF stream in regression test case would match warn.gif stream behaviour that?s why it going into GIFImageReader.getCode().
>>>> 
>>>> Are you okay with overall webrev.00 patch or have you just approved GIFImageReader change? Please clarify.
>>>> 
>>>> Regards,
>>>> Jay
>>>> 
>>>>> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>>>> 
>>>>> Hello Jay,
>>>>> 
>>>>> The source fix looks OK to me. I get the same exception as in the bug description when I run the test against my unpatched local JDK 15 build.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>>>> 
>>>>>> Please review the following fix for JDK 15:
>>>>>> 
>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/%7Ejdv/6532025/webrev.00/> 
>>>>>> 
>>>>>> Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
>>>>>> Solution : Handle cases where we reach EOF and throw appropriate exception.
>>>>> 
>>>> 
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200306/49122480/attachment.htm>

From philip.race at oracle.com  Fri Mar  6 16:01:35 2020
From: philip.race at oracle.com (Phil Race)
Date: Fri, 6 Mar 2020 08:01:35 -0800
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <A52671D0-B116-43FB-9EED-1CC5FD8D10F2@ORACLE.COM>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
 <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
 <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>
 <DE688F8F-6F72-4F8F-B024-CA2B754E1394@ORACLE.COM>
 <5E61BAF0.9020604@oracle.com>
 <A52671D0-B116-43FB-9EED-1CC5FD8D10F2@ORACLE.COM>
Message-ID: <5cd7bb3b-68c9-6a73-b1b6-ce74a0c1ef7c@oracle.com>

+1

-Phil.

On 3/5/20 7:47 PM, Jayathirth D v wrote:
> Hi Phil,
>
> Thanks for your inputs.
>
> Yes we don?t need extra ?left > 0? check, I have removed it and I have 
> updated the test case to print ?Test passed?.
>
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/6532025/webrev.01/
>
> I ran all imageio jtreg tests and there are no failures with updated 
> change.
>
> Thanks,
> Jay
>
>> On 06-Mar-2020, at 8:22 AM, Philip Race <philip.race at oracle.com 
>> <mailto:philip.race at oracle.com>> wrote:
>>
>> I don't understand why you need to recheck that left > 0.
>> Nothing can change it between the while loop check and your check
>>
>> ???????????????????? while (left > 0) {
>> ???????????????????????? int nbytes = stream.read(block, off, left);
>> +??????????????????????? if (nbytes == -1 && left > 0) {
>> +??????????????????????????? throw new IIOException("Invalid block 
>> length for " +
>> +??????????????????????????????????? "LZW encoded image data");
>> +??????????????????????? }
>> ???????????????????????? off += nbytes;
>> ???????????????????????? left -= nbytes;
>> ???????????????????? }
>>
>> Also in the test since you are printing
>>    51         } catch (IIOException e) {
>>    52             // do nothing we expect IIOException but we should not
>>    53             // throw IndexOutOfBoundsException
>>    54             System.out.println(e.toString());
>>    55             System.out.println("Caught IIOException ignore it");
>>
>> Maybe add "Test passed" to be extra clear !
>>
>> -phil.
>>
>> On 3/5/20, 6:15 PM, Jayathirth D v wrote:
>>> Hi Brian,
>>>
>>> Thanks for the clarification and approval.
>>>
>>> @Others : Need one more review please take a look.
>>>
>>> Regards,
>>> Jay
>>>
>>>> On 06-Mar-2020, at 2:05 AM, Brian Burkhalter 
>>>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> 
>>>> wrote:
>>>>
>>>> Hi Jay,
>>>>
>>>> I think the overall change is fine.
>>>>
>>>> Regards,
>>>>
>>>> Brian
>>>>
>>>>> On Mar 5, 2020, at 9:18 AM, Jayathirth D v 
>>>>> <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>>>
>>>>> Hello Brian,
>>>>>
>>>>> Thanks for the review. GIF stream in regression test case would 
>>>>> match warn.gif stream behaviour that?s why it going into 
>>>>> GIFImageReader.getCode().
>>>>>
>>>>> Are you okay with overall webrev.00 patch or have you just 
>>>>> approved GIFImageReader change? Please clarify.
>>>>>
>>>>> Regards,
>>>>> Jay
>>>>>
>>>>>> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter 
>>>>>> <brian.burkhalter at oracle.com 
>>>>>> <mailto:brian.burkhalter at oracle.com>> wrote:
>>>>>>
>>>>>> Hello Jay,
>>>>>>
>>>>>> The source fix looks OK to me. I get the same exception as in the 
>>>>>> bug description when I run the test against my unpatched local 
>>>>>> JDK 15 build.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v 
>>>>>>> <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Please review the following fix for JDK 15:
>>>>>>>
>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025
>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Ejdv/6532025/webrev.00/>
>>>>>>>
>>>>>>> Root cause : When we have truncated GIF images, stream.read() 
>>>>>>> returns -1 but GIFImageReader doesn?t handle such conditions 
>>>>>>> properly and continues to read input stream data.
>>>>>>> Solution : Handle cases where we reach EOF and throw appropriate 
>>>>>>> exception.
>>>>>>
>>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200306/5081f157/attachment.htm>

From brian.burkhalter at oracle.com  Fri Mar  6 16:18:36 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 6 Mar 2020 08:18:36 -0800
Subject: [OpenJDK 2D-Dev] [15] RFR JDK-6532025: GIF reader throws
 misleading exception with truncated images
In-Reply-To: <5cd7bb3b-68c9-6a73-b1b6-ce74a0c1ef7c@oracle.com>
References: <A3A8CB1B-68BA-4CB5-992D-D5B85158D3F0@ORACLE.COM>
 <220117F7-0B47-477F-8FEF-1A39DEFCD46D@oracle.com>
 <6B1FB91F-9BC1-48BE-B231-EDEC2AD349E9@ORACLE.COM>
 <31B7EC39-1405-4C5A-992B-D9BD417FE6B0@oracle.com>
 <DE688F8F-6F72-4F8F-B024-CA2B754E1394@ORACLE.COM>
 <5E61BAF0.9020604@oracle.com>
 <A52671D0-B116-43FB-9EED-1CC5FD8D10F2@ORACLE.COM>
 <5cd7bb3b-68c9-6a73-b1b6-ce74a0c1ef7c@oracle.com>
Message-ID: <AD44CA53-8F11-4D68-9351-CDA76A4E08CA@oracle.com>

+1

> On Mar 6, 2020, at 8:01 AM, Phil Race <philip.race at oracle.com> wrote:
> 
> +1
> 
> -Phil.
> 
> On 3/5/20 7:47 PM, Jayathirth D v wrote:
>> Hi Phil,
>> 
>> Thanks for your inputs.
>> 
>> Yes we don?t need extra ?left > 0? check, I have removed it and I have updated the test case to print ?Test passed?.
>> 
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/6532025/webrev.01/ <http://cr.openjdk.java.net/~jdv/6532025/webrev.01/> 
>> 
>> I ran all imageio jtreg tests and there are no failures with updated change.
>> 
>> Thanks,
>> Jay
>> 
>>> On 06-Mar-2020, at 8:22 AM, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>> 
>>> I don't understand why you need to recheck that left > 0.
>>> Nothing can change it between the while loop check and your check
>>> 
>>>                      while (left > 0) {
>>>                          int nbytes = stream.read(block, off, left);
>>> +                        if (nbytes == -1 && left > 0) {
>>> +                            throw new IIOException("Invalid block length for " +
>>> +                                    "LZW encoded image data");
>>> +                        }
>>>                          off += nbytes;
>>>                          left -= nbytes;
>>>                      }
>>> 
>>> Also in the test since you are printing
>>>   51         } catch (IIOException e) {
>>>   52             // do nothing we expect IIOException but we should not
>>>   53             // throw IndexOutOfBoundsException
>>>   54             System.out.println(e.toString());
>>>   55             System.out.println("Caught IIOException ignore it");
>>> 
>>> Maybe add "Test passed" to be extra clear !
>>> 
>>> -phil.
>>> 
>>> On 3/5/20, 6:15 PM, Jayathirth D v wrote:
>>>> 
>>>> Hi Brian,
>>>> 
>>>> Thanks for the clarification and approval.
>>>> 
>>>> @Others : Need one more review please take a look.
>>>> 
>>>> Regards,
>>>> Jay 
>>>> 
>>>>> On 06-Mar-2020, at 2:05 AM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>>>> 
>>>>> Hi Jay,
>>>>> 
>>>>> I think the overall change is fine.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> On Mar 5, 2020, at 9:18 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>>>> 
>>>>>> Hello Brian,
>>>>>> 
>>>>>> Thanks for the review. GIF stream in regression test case would match warn.gif stream behaviour that?s why it going into GIFImageReader.getCode().
>>>>>> 
>>>>>> Are you okay with overall webrev.00 patch or have you just approved GIFImageReader change? Please clarify.
>>>>>> 
>>>>>> Regards,
>>>>>> Jay
>>>>>> 
>>>>>>> On 05-Mar-2020, at 10:20 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hello Jay,
>>>>>>> 
>>>>>>> The source fix looks OK to me. I get the same exception as in the bug description when I run the test against my unpatched local JDK 15 build.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Brian
>>>>>>> 
>>>>>>>> On Mar 5, 2020, at 2:12 AM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>>>>>>> 
>>>>>>>> Please review the following fix for JDK 15:
>>>>>>>> 
>>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6532025 <https://bugs.openjdk.java.net/browse/JDK-6532025>
>>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/6532025/webrev.00/ <http://cr.openjdk.java.net/%7Ejdv/6532025/webrev.00/> 
>>>>>>>> 
>>>>>>>> Root cause : When we have truncated GIF images, stream.read() returns -1 but GIFImageReader doesn?t handle such conditions properly and continues to read input stream data.
>>>>>>>> Solution : Handle cases where we reach EOF and throw appropriate exception.
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200306/afd4754f/attachment-0001.htm>

From Sergey.Bylokhov at oracle.com  Mon Mar  9 00:29:20 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 8 Mar 2020 17:29:20 -0700
Subject: [OpenJDK 2D-Dev] BufferedImage.getTileGridXOffset() not
 compliant with its specification?
In-Reply-To: <d3f5ee5d-effa-f9d6-5dfd-1f0149808fb3@geomatys.com>
References: <556c4c82-8035-6d1d-3823-0e83cd7bc7b8@geomatys.com>
 <5b603a92-2929-67bb-20c0-089305d5eff2@oracle.com>
 <30ac198f-59e6-5bee-4cb5-cb2fe53ddf2c@geomatys.com>
 <ec7709e9-fca2-f3d7-1d96-1adaffa4e405@oracle.com>
 <d3f5ee5d-effa-f9d6-5dfd-1f0149808fb3@geomatys.com>
Message-ID: <fd35062e-e624-0cf1-33bd-5ed2679afa4c@oracle.com>

Hi, Martin.

On 2/23/20 3:12 am, Martin Desruisseaux wrote:
> The purpose of RenderedImage.getTileGridXOffset() is to provide information needed for converting pixel coordinates to tile indices and conversely. Current BufferedImage.getTileGridXOffset() implementation breaks this purpose, and in turn does not provide any information that I can see as useful at the image level (it is useful at the Raster / SampleModel level, but developers already have dedicated API for that). It is not even an offset of the sub-image compared to the parent image except by coincidence in the simple case (it depends on how the BufferedImage has been constructed).


I have checked the history of these methods and their usage.

These methods were added to the BufferedImage back in 1997 when the
generic support of rendered images was added. Since then these methods
were used in the implementation of Graphics2D.drawRenderedImage(), but
in fact for BufferedImage they are never called [1]. I think it is
possible to change getTileGridXOffset()/getTileGridYOffset to return 0.
But it will be necessary to create a CSR, since the change has
compatibility impact.


[1] https://github.com/openjdk/client/blob/master/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L2662


-- 
Best regards, Sergey.

From martin.desruisseaux at geomatys.com  Mon Mar  9 13:29:47 2020
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Mon, 9 Mar 2020 14:29:47 +0100
Subject: [OpenJDK 2D-Dev] BufferedImage.getTileGridXOffset() not
 compliant with its specification?
In-Reply-To: <fd35062e-e624-0cf1-33bd-5ed2679afa4c@oracle.com>
References: <556c4c82-8035-6d1d-3823-0e83cd7bc7b8@geomatys.com>
 <5b603a92-2929-67bb-20c0-089305d5eff2@oracle.com>
 <30ac198f-59e6-5bee-4cb5-cb2fe53ddf2c@geomatys.com>
 <ec7709e9-fca2-f3d7-1d96-1adaffa4e405@oracle.com>
 <d3f5ee5d-effa-f9d6-5dfd-1f0149808fb3@geomatys.com>
 <fd35062e-e624-0cf1-33bd-5ed2679afa4c@oracle.com>
Message-ID: <049582ff-a3b3-7381-6cc0-ff3199366e6f@geomatys.com>

Hello Sergey

Thanks for the analysis. I can volunteer for creating the CSR if I can 
have some pointers (e.g. template) to follow?

Indeed, I though that Graphics2D may have "if (image instanceof 
BufferedImage)" optimizations that hides the issue. My plan was to 
create a test with a RenderedImage wrapping a BufferedImage, which would 
prevent Graphics2D to use such fast track, and see how it behaves. What 
I can said however is that Graphics2D works well with multi-tiled images 
compliant with the specification, such as javax.media.jai.TiledImage [1].

For the formula used for "pixel coordinates to tile indices" 
calculation, we can use source code of [2] as a reference.

[1] https://docs.oracle.com/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/TiledImage.html
[2] https://docs.oracle.com/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/PlanarImage.html#XToTileX(int,%20int,%20int)

 ??? Regards,

 ??? ??? Martin


Le 09/03/2020 ? 01:29, Sergey Bylokhov a ?crit?:

> I have checked the history of these methods and their usage.
>
> These methods were added to the BufferedImage back in 1997 when the
> generic support of rendered images was added. Since then these methods
> were used in the implementation of Graphics2D.drawRenderedImage(), but
> in fact for BufferedImage they are never called [1]. I think it is
> possible to change getTileGridXOffset()/getTileGridYOffset to return 0.
> But it will be necessary to create a CSR, since the change has
> compatibility impact.
>
> [1] 
> https://github.com/openjdk/client/blob/master/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L2662

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200309/7e6ddc82/attachment.htm>

From Sergey.Bylokhov at oracle.com  Mon Mar  9 22:14:05 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 9 Mar 2020 22:14:05 +0000 (UTC)
Subject: [OpenJDK 2D-Dev] [15] Review Request: 8238075 [OGL] Delete
 unused properties
In-Reply-To: <19076fe4-7414-6aac-e112-a4d9d3799136@oracle.com>
References: <19076fe4-7414-6aac-e112-a4d9d3799136@oracle.com>
Message-ID: <d567ea3d-4822-4d81-83bd-6c582b9dee4c@oracle.com>

Any volunteers to review? =)

On 1/28/20 8:15 pm, Sergey Bylokhov wrote:
> Hello.
> Please review the small cleanup for JDK 15.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238075
> Fix: http://cr.openjdk.java.net/~serb/8238075/webrev.00
> 
> The OGL pipeline on macOS still used some properties:
>  ?- CGLGraphicsConfig#kOpenGLSwapInterval is not useful since we moved to the CALayer
>  ?- CGLGraphicsConfig#pixfmt never used
>  ?- Initialization of CGLGraphicsConfig does not depend on displayID after JDK-8223158[1]
> 
> Also I simplified the native initialization logic of CGLGraphicsConfig.
> Previously we create an array of parameters and passed them to the selector, also we
> return result via the same array, in the fix selector was replaced by the simple "block"
> passed to "ThreadUtilities performOnMainThreadWaiting"
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8223158
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Mar  9 22:24:30 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 9 Mar 2020 15:24:30 -0700
Subject: [OpenJDK 2D-Dev] BufferedImage.getTileGridXOffset() not
 compliant with its specification?
In-Reply-To: <049582ff-a3b3-7381-6cc0-ff3199366e6f@geomatys.com>
References: <556c4c82-8035-6d1d-3823-0e83cd7bc7b8@geomatys.com>
 <5b603a92-2929-67bb-20c0-089305d5eff2@oracle.com>
 <30ac198f-59e6-5bee-4cb5-cb2fe53ddf2c@geomatys.com>
 <ec7709e9-fca2-f3d7-1d96-1adaffa4e405@oracle.com>
 <d3f5ee5d-effa-f9d6-5dfd-1f0149808fb3@geomatys.com>
 <fd35062e-e624-0cf1-33bd-5ed2679afa4c@oracle.com>
 <049582ff-a3b3-7381-6cc0-ff3199366e6f@geomatys.com>
Message-ID: <16881f25-0775-eb02-825e-36c50b57f282@oracle.com>

On 3/9/20 6:29 am, Martin Desruisseaux wrote:
> Thanks for the analysis. I can volunteer for creating the CSR if I can have some pointers (e.g. template) to follow?

Let's start with the fix/test. Send me a patch and I will upload it to the cr.openjdk, so will be able to send an official review request.

> Indeed, I though that Graphics2D may have "if (image instanceof BufferedImage)" optimizations that hides the issue. My plan was to create a test with a RenderedImage wrapping a BufferedImage, which would prevent Graphics2D to use such fast track, and see how it behaves. What I can said however is that Graphics2D works well with multi-tiled images compliant with the specification, such as javax.media.jai.TiledImage [1].
> 
> For the formula used for "pixel coordinates to tile indices" calculation, we can use source code of [2] as a reference.
> 
> [1]https://docs.oracle.com/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/TiledImage.html
> [2]https://docs.oracle.com/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/PlanarImage.html#XToTileX(int,%20int,%20int)
> 
>  ??? Regards,
> 
>  ??? ??? Martin
> 
> 
> Le 09/03/2020 ? 01:29, Sergey Bylokhov a ?crit?:
> 
>> I have checked the history of these methods and their usage.
>>
>> These methods were added to the BufferedImage back in 1997 when the
>> generic support of rendered images was added. Since then these methods
>> were used in the implementation of Graphics2D.drawRenderedImage(), but
>> in fact for BufferedImage they are never called [1]. I think it is
>> possible to change getTileGridXOffset()/getTileGridYOffset to return 0.
>> But it will be necessary to create a CSR, since the change has
>> compatibility impact.
>>
>> [1] https://github.com/openjdk/client/blob/master/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L2662
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Mar 11 00:12:59 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Mar 2020 17:12:59 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [15] Review Request: 8237746
 Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com>
References: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
 <C234EDBB-20AA-4921-9836-0F9F1F2AF4B5@mountainminds.com>
 <e199e3ef-f2a8-81b7-9714-dc1f9d07cc39@oracle.com>
 <FBD35B62-ED3D-4C05-9147-60F08E4E3774@mountainminds.com>
 <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
 <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com>
Message-ID: <19118a11-e420-4ec5-0364-f3bce325f293@oracle.com>

I plan to push this change if there are no more comments about the webrev.

On 3/2/20 10:31 am, Alexander Zuev wrote:
> Looks much better. I would double the proposal of creating the separate issue for bringing formatting in different files to the same coding standard. Seeing different spacing on cycles and method invocations in different classes makes me cringe. But functionally it seems everything is fine.
> 
> /Alex
> 
> On 22-Feb-20 12:50, Sergey Bylokhov wrote:
>> Thank you, an updated version is upload:
>> http://cr.openjdk.java.net/~serb/8237746/webrev.01
>>
>> On 2/17/20 11:55 am, Marc Hoffmann wrote:
>>> Thanks Alexey for the detailed review! I attached a updated version.
>>>
>>> The examples have many cleanup opportunities. I wanted to focus on compiler warnings for now and keep the changeset minimal.
>>>
>>>
>>>> *Font2DTest.java*
>>>> 674???????? if ( selectedText == fp.USER_TEXT )
>>>> 675?????????? userTextDialog.setVisible(true);
>>>> 676???????? else
>>>> 677?????????? userTextDialog.setVisible(false);
>>>>
>>>> I'd put the braces around and indent the statements by 4 spaces.
>>>> However, it's the style used throughout the file: if there's only one statement, there are no braces and the statement is indented by 2 spaces rather than 4. Probably, to keep the code consistent, it's better to leave it as is.
>>>>
>>>> 797???????????? else
>>>> 798?????????????? fontInfoDialog.setVisible(false);
>>>
>>> Maybe separate issue for formatting?
>>>
>>>>
>>>> *FontPanel.java*
>>>> 1248??????????? if (valArray == null) {
>>>> 1249??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>> 1250??????????? }
>>>> 1259??????????? if (valArray == null) {
>>>> 1260??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>> 1261??????????? }
>>>> Can it be replaced with FMValues.values() as you did in Font2DTest.java lines 153, 156?
>>>>
>>>> And below
>>>> 1311??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>> 1324??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>
>>> Done.
>>>
>>>>
>>>> *ButtonDemo.java*
>>>> 64???? Vector<Component> buttons = new Vector<>();
>>>> Shall it be JComponent?
>>>
>>> Doesn?t because JPanel.add() returns Component:
>>>
>>> ???? buttons.add(p2.add(new JButton(getString("ButtonDemo.button1"))));
>>>
>>> Should I introduce a local variable?
>>>
>>>>
>>>>
>>>> *ComboBoxDemo.java*
>>>> 60???? JComboBox<?> hairCB;
>>>> Why not JComboBox<String> ?
>>>> All createXXX methods use this type.
>>>> Then the cast below would be unnecessary:
>>>> 282???????????? String name = (String) parts.get(hairCB.getSelectedItem());
>>>
>>> This comes from the lookup in the parts Hashtable. Unfortunately it has String an ImageIcon values.
>>>
>>>>
>>>>
>>>> 114???????? presetCB = (JComboBox<?>) comboBoxPanel.add(createPresetComboBox());
>>>> To avoid cast, you can use two statements:
>>>> presetCB = createPresetComboBox();
>>>> comboBoxPanel.add(presetCB);
>>>
>>> Done for all 4 occurrences.
>>>
>>>>
>>>>
>>>> *DirectionPanel.java*
>>>> 97???????????????? AbstractButton b = e.nextElement();
>>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>>> Indentation on line 97 seems incorrect, it should align to line 98, shouldn't it?
>>>
>>> Done (replace tab with spaces).
>>>
>>>>
>>>>
>>>> *SliderDemo.java*
>>>> 167???????? @SuppressWarnings("unchecked")
>>>> 168???????????????? Dictionary<Object, Object> labelTable = s.getLabelTable();
>>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>>> I mean that @SuppressWarning would become unnecessary.
>>>
>>> Dictionary<?,?> does not allow put of specific types in the next line. But fixed tabs in the same line.
>>>
>>>>
>>>>
>>>> *SplitPaneDemo.java*
>>>> 168 divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString());
>>>> can be simplified to
>>>> divSize.setText(Integer.toString(splitPane.getDividerSize()));
>>>> by using static method Integer.toString() method.
>>>
>>> Done.
>>>
>>>>
>>>>
>>>> Shall the copyright year be updated in all the modified files?
>>>
>>> Please let me know what would be the correct process.
>>>
>>> Cheers,
>>> -marc
>>>
>>>
>>>
>>>
>>>> On 17. Feb 2020, at 15:40, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
>>>>
>>>> Thank you, Marc, for your contribution.
>>>> And thank you to Sergey for creating the review.
>>>>
>>>> *Font2DTest.java*
>>>> 674???????? if ( selectedText == fp.USER_TEXT )
>>>> 675?????????? userTextDialog.setVisible(true);
>>>> 676???????? else
>>>> 677?????????? userTextDialog.setVisible(false);
>>>>
>>>> I'd put the braces around and indent the statements by 4 spaces.
>>>> However, it's the style used throughout the file: if there's only one statement, there are no braces and the statement is indented by 2 spaces rather than 4. Probably, to keep the code consistent, it's better to leave it as is.
>>>>
>>>> 797???????????? else
>>>> 798?????????????? fontInfoDialog.setVisible(false);
>>>>
>>>>
>>>> *FontPanel.java*
>>>> 1248??????????? if (valArray == null) {
>>>> 1249??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>> 1250??????????? }
>>>> 1259??????????? if (valArray == null) {
>>>> 1260??????????????? valArray = EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>> 1261??????????? }
>>>> Can it be replaced with FMValues.values() as you did in Font2DTest.java lines 153, 156?
>>>>
>>>> And below
>>>> 1311??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>> 1324??????????????? valArray = EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>>
>>>>
>>>> *ButtonDemo.java*
>>>> 64???? Vector<Component> buttons = new Vector<>();
>>>> Shall it be JComponent?
>>>>
>>>>
>>>> *ComboBoxDemo.java*
>>>> 60???? JComboBox<?> hairCB;
>>>> Why not JComboBox<String> ?
>>>> All createXXX methods use this type.
>>>> Then the cast below would be unnecessary:
>>>> 282???????????? String name = (String) parts.get(hairCB.getSelectedItem());
>>>>
>>>>
>>>> 114???????? presetCB = (JComboBox<?>) comboBoxPanel.add(createPresetComboBox());
>>>> To avoid cast, you can use two statements:
>>>> presetCB = createPresetComboBox();
>>>> comboBoxPanel.add(presetCB);
>>>>
>>>>
>>>> *DirectionPanel.java*
>>>> 97???????????????? AbstractButton b = e.nextElement();
>>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>>> Indentation on line 97 seems incorrect, it should align to line 98, shouldn't it?
>>>>
>>>>
>>>> *SliderDemo.java*
>>>> 167???????? @SuppressWarnings("unchecked")
>>>> 168???????????????? Dictionary<Object, Object> labelTable = s.getLabelTable();
>>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>>> I mean that @SuppressWarning would become unnecessary.
>>>>
>>>>
>>>> *SplitPaneDemo.java*
>>>> 168 divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString());
>>>> can be simplified to
>>>> divSize.setText(Integer.toString(splitPane.getDividerSize()));
>>>> by using static method Integer.toString() method.
>>>>
>>>>
>>>> Shall the copyright year be updated in all the modified files?
>>>>
>>>>
>>>> On 23/01/2020 08:54, Marc Hoffmann wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> thanks for sponsoring this patch!
>>>>>
>>>>> I successfully applied the webrev patch on current JDK head (57807:7bae17e00566). The build runs without warnings on the demo code :)
>>>>>
>>>>> But I noticed a minor glitch: I inserted a tab in src/demo/share/jfc/SwingSet2/DirectionPanel.java Line 97 where only spaces are used in the rest of the file. Probably this should be fixed before merge.
>>>>>
>>>>> Regards,
>>>>> -marc
>>>>>
>>>>>
>>>>>> On 23. Jan 2020, at 01:35, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>
>>>>>> Hello.
>>>>>> Please review the fix for compiler warnings in the demo/jfc in JDK 15.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237746
>>>>>> Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00
>>>>>>
>>>>>> This fix contributed by the Marc Hoffmann:
>>>>>> https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html
>>>>>>
>>>>>> Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs.
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>>
>>>> -- 
>>>> Regards,
>>>> Alexey
>>>
>>>
>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From alexander.zuev at oracle.com  Wed Mar 11 14:49:47 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Wed, 11 Mar 2020 17:49:47 +0300
Subject: [OpenJDK 2D-Dev] [15] Review Request: 8238075 [OGL] Delete
 unused properties
In-Reply-To: <19076fe4-7414-6aac-e112-a4d9d3799136@oracle.com>
References: <19076fe4-7414-6aac-e112-a4d9d3799136@oracle.com>
Message-ID: <2eac6bd9-4ee4-23f1-f81e-0ced6ec66019@oracle.com>

Looks Ok to me.

On 29-Jan-20 7:15, Sergey Bylokhov wrote:
> Hello.
> Please review the small cleanup for JDK 15.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238075
> Fix: http://cr.openjdk.java.net/~serb/8238075/webrev.00
>
> The OGL pipeline on macOS still used some properties:
> ?- CGLGraphicsConfig#kOpenGLSwapInterval is not useful since we moved 
> to the CALayer
> ?- CGLGraphicsConfig#pixfmt never used
> ?- Initialization of CGLGraphicsConfig does not depend on displayID 
> after JDK-8223158[1]
>
> Also I simplified the native initialization logic of CGLGraphicsConfig.
> Previously we create an array of parameters and passed them to the 
> selector, also we
> return result via the same array, in the fix selector was replaced by 
> the simple "block"
> passed to "ThreadUtilities performOnMainThreadWaiting"
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223158
>


From alexey.ivanov at oracle.com  Wed Mar 11 19:28:33 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 11 Mar 2020 19:28:33 +0000
Subject: [OpenJDK 2D-Dev] <Swing Dev> [15] Review Request: 8237746
 Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <19118a11-e420-4ec5-0364-f3bce325f293@oracle.com>
References: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
 <C234EDBB-20AA-4921-9836-0F9F1F2AF4B5@mountainminds.com>
 <e199e3ef-f2a8-81b7-9714-dc1f9d07cc39@oracle.com>
 <FBD35B62-ED3D-4C05-9147-60F08E4E3774@mountainminds.com>
 <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
 <047e9859-bd9a-2716-d54a-bcd73b572b27@oracle.com>
 <19118a11-e420-4ec5-0364-f3bce325f293@oracle.com>
Message-ID: <6c70a474-783b-52fb-cc41-b94626302452@oracle.com>

Hi Sergey,

The updated webrev.01 looks good to me.
Please go ahead and push the changes.

I agree with Alexander, separate issues for formatting are better.

Regards,
Alexey

On 11/03/2020 00:12, Sergey Bylokhov wrote:
> I plan to push this change if there are no more comments about the 
> webrev.
>
> On 3/2/20 10:31 am, Alexander Zuev wrote:
>> Looks much better. I would double the proposal of creating the 
>> separate issue for bringing formatting in different files to the same 
>> coding standard. Seeing different spacing on cycles and method 
>> invocations in different classes makes me cringe. But functionally it 
>> seems everything is fine.
>>
>> /Alex
>>
>> On 22-Feb-20 12:50, Sergey Bylokhov wrote:
>>> Thank you, an updated version is upload:
>>> http://cr.openjdk.java.net/~serb/8237746/webrev.01
>>>
>>> On 2/17/20 11:55 am, Marc Hoffmann wrote:
>>>> Thanks Alexey for the detailed review! I attached a updated version.
>>>>
>>>> The examples have many cleanup opportunities. I wanted to focus on 
>>>> compiler warnings for now and keep the changeset minimal.
>>>>
>>>>
>>>>> *Font2DTest.java*
>>>>> 674???????? if ( selectedText == fp.USER_TEXT )
>>>>> 675?????????? userTextDialog.setVisible(true);
>>>>> 676???????? else
>>>>> 677?????????? userTextDialog.setVisible(false);
>>>>>
>>>>> I'd put the braces around and indent the statements by 4 spaces.
>>>>> However, it's the style used throughout the file: if there's only 
>>>>> one statement, there are no braces and the statement is indented 
>>>>> by 2 spaces rather than 4. Probably, to keep the code consistent, 
>>>>> it's better to leave it as is.
>>>>>
>>>>> 797???????????? else
>>>>> 798?????????????? fontInfoDialog.setVisible(false);
>>>>
>>>> Maybe separate issue for formatting?
>>>>
>>>>>
>>>>> *FontPanel.java*
>>>>> 1248??????????? if (valArray == null) {
>>>>> 1249??????????????? valArray = 
>>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>>> 1250??????????? }
>>>>> 1259??????????? if (valArray == null) {
>>>>> 1260??????????????? valArray = 
>>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>>> 1261??????????? }
>>>>> Can it be replaced with FMValues.values() as you did in 
>>>>> Font2DTest.java lines 153, 156?
>>>>>
>>>>> And below
>>>>> 1311??????????????? valArray = 
>>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>>> 1324??????????????? valArray = 
>>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> *ButtonDemo.java*
>>>>> 64???? Vector<Component> buttons = new Vector<>();
>>>>> Shall it be JComponent?
>>>>
>>>> Doesn?t because JPanel.add() returns Component:
>>>>
>>>> ???? buttons.add(p2.add(new 
>>>> JButton(getString("ButtonDemo.button1"))));
>>>>
>>>> Should I introduce a local variable?
>>>>
>>>>>
>>>>>
>>>>> *ComboBoxDemo.java*
>>>>> 60???? JComboBox<?> hairCB;
>>>>> Why not JComboBox<String> ?
>>>>> All createXXX methods use this type.
>>>>> Then the cast below would be unnecessary:
>>>>> 282???????????? String name = (String) 
>>>>> parts.get(hairCB.getSelectedItem());
>>>>
>>>> This comes from the lookup in the parts Hashtable. Unfortunately it 
>>>> has String an ImageIcon values.
>>>>
>>>>>
>>>>>
>>>>> 114???????? presetCB = (JComboBox<?>) 
>>>>> comboBoxPanel.add(createPresetComboBox());
>>>>> To avoid cast, you can use two statements:
>>>>> presetCB = createPresetComboBox();
>>>>> comboBoxPanel.add(presetCB);
>>>>
>>>> Done for all 4 occurrences.
>>>>
>>>>>
>>>>>
>>>>> *DirectionPanel.java*
>>>>> 97???????????????? AbstractButton b = e.nextElement();
>>>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>>>> Indentation on line 97 seems incorrect, it should align to line 
>>>>> 98, shouldn't it?
>>>>
>>>> Done (replace tab with spaces).
>>>>
>>>>>
>>>>>
>>>>> *SliderDemo.java*
>>>>> 167???????? @SuppressWarnings("unchecked")
>>>>> 168???????????????? Dictionary<Object, Object> labelTable = 
>>>>> s.getLabelTable();
>>>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>>>> I mean that @SuppressWarning would become unnecessary.
>>>>
>>>> Dictionary<?,?> does not allow put of specific types in the next 
>>>> line. But fixed tabs in the same line.
>>>>
>>>>>
>>>>>
>>>>> *SplitPaneDemo.java*
>>>>> 168 
>>>>> divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); 
>>>>>
>>>>> can be simplified to
>>>>> divSize.setText(Integer.toString(splitPane.getDividerSize()));
>>>>> by using static method Integer.toString() method.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>>
>>>>> Shall the copyright year be updated in all the modified files?
>>>>
>>>> Please let me know what would be the correct process.
>>>>
>>>> Cheers,
>>>> -marc
>>>>
>>>>
>>>>
>>>>
>>>>> On 17. Feb 2020, at 15:40, Alexey Ivanov 
>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>
>>>>> Thank you, Marc, for your contribution.
>>>>> And thank you to Sergey for creating the review.
>>>>>
>>>>> *Font2DTest.java*
>>>>> 674???????? if ( selectedText == fp.USER_TEXT )
>>>>> 675?????????? userTextDialog.setVisible(true);
>>>>> 676???????? else
>>>>> 677?????????? userTextDialog.setVisible(false);
>>>>>
>>>>> I'd put the braces around and indent the statements by 4 spaces.
>>>>> However, it's the style used throughout the file: if there's only 
>>>>> one statement, there are no braces and the statement is indented 
>>>>> by 2 spaces rather than 4. Probably, to keep the code consistent, 
>>>>> it's better to leave it as is.
>>>>>
>>>>> 797???????????? else
>>>>> 798?????????????? fontInfoDialog.setVisible(false);
>>>>>
>>>>>
>>>>> *FontPanel.java*
>>>>> 1248??????????? if (valArray == null) {
>>>>> 1249??????????????? valArray = 
>>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>>> 1250??????????? }
>>>>> 1259??????????? if (valArray == null) {
>>>>> 1260??????????????? valArray = 
>>>>> EnumSet.allOf(FMValues.class).toArray(new FMValues[0]);
>>>>> 1261??????????? }
>>>>> Can it be replaced with FMValues.values() as you did in 
>>>>> Font2DTest.java lines 153, 156?
>>>>>
>>>>> And below
>>>>> 1311??????????????? valArray = 
>>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>>> 1324??????????????? valArray = 
>>>>> EnumSet.allOf(AAValues.class).toArray(new AAValues[0]);
>>>>>
>>>>>
>>>>> *ButtonDemo.java*
>>>>> 64???? Vector<Component> buttons = new Vector<>();
>>>>> Shall it be JComponent?
>>>>>
>>>>>
>>>>> *ComboBoxDemo.java*
>>>>> 60???? JComboBox<?> hairCB;
>>>>> Why not JComboBox<String> ?
>>>>> All createXXX methods use this type.
>>>>> Then the cast below would be unnecessary:
>>>>> 282???????????? String name = (String) 
>>>>> parts.get(hairCB.getSelectedItem());
>>>>>
>>>>>
>>>>> 114???????? presetCB = (JComboBox<?>) 
>>>>> comboBoxPanel.add(createPresetComboBox());
>>>>> To avoid cast, you can use two statements:
>>>>> presetCB = createPresetComboBox();
>>>>> comboBoxPanel.add(presetCB);
>>>>>
>>>>>
>>>>> *DirectionPanel.java*
>>>>> 97???????????????? AbstractButton b = e.nextElement();
>>>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>>>> Indentation on line 97 seems incorrect, it should align to line 
>>>>> 98, shouldn't it?
>>>>>
>>>>>
>>>>> *SliderDemo.java*
>>>>> 167???????? @SuppressWarnings("unchecked")
>>>>> 168???????????????? Dictionary<Object, Object> labelTable = 
>>>>> s.getLabelTable();
>>>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>>>> I mean that @SuppressWarning would become unnecessary.
>>>>>
>>>>>
>>>>> *SplitPaneDemo.java*
>>>>> 168 
>>>>> divSize.setText(Integer.valueOf(splitPane.getDividerSize()).toString()); 
>>>>>
>>>>> can be simplified to
>>>>> divSize.setText(Integer.toString(splitPane.getDividerSize()));
>>>>> by using static method Integer.toString() method.
>>>>>
>>>>>
>>>>> Shall the copyright year be updated in all the modified files?
>>>>>
>>>>>
>>>>> On 23/01/2020 08:54, Marc Hoffmann wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> thanks for sponsoring this patch!
>>>>>>
>>>>>> I successfully applied the webrev patch on current JDK head 
>>>>>> (57807:7bae17e00566). The build runs without warnings on the demo 
>>>>>> code :)
>>>>>>
>>>>>> But I noticed a minor glitch: I inserted a tab in 
>>>>>> src/demo/share/jfc/SwingSet2/DirectionPanel.java Line 97 where 
>>>>>> only spaces are used in the rest of the file. Probably this 
>>>>>> should be fixed before merge.
>>>>>>
>>>>>> Regards,
>>>>>> -marc
>>>>>>
>>>>>>
>>>>>>> On 23. Jan 2020, at 01:35, Sergey Bylokhov 
>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>
>>>>>>> Hello.
>>>>>>> Please review the fix for compiler warnings in the demo/jfc in 
>>>>>>> JDK 15.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237746
>>>>>>> Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00
>>>>>>>
>>>>>>> This fix contributed by the Marc Hoffmann:
>>>>>>> https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html 
>>>>>>>
>>>>>>>
>>>>>>> Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs.
>>>>>>>
>>>>>>> -- 
>>>>>>> Best regards, Sergey.
>>>>>>
>>>>> -- 
>>>>> Regards,
>>>>> Alexey
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


From alexey.ivanov at oracle.com  Wed Mar 11 20:07:58 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 11 Mar 2020 20:07:58 +0000
Subject: [OpenJDK 2D-Dev] <Swing Dev> [15] Review Request: 8237746
 Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
References: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
 <C234EDBB-20AA-4921-9836-0F9F1F2AF4B5@mountainminds.com>
 <e199e3ef-f2a8-81b7-9714-dc1f9d07cc39@oracle.com>
 <FBD35B62-ED3D-4C05-9147-60F08E4E3774@mountainminds.com>
 <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
Message-ID: <8d627478-3af5-49cd-df43-c9caf5551be1@oracle.com>

Thank you to Marc for updating webrev and to Sergey for uploading it.

The changes look fine to me as I already stated.

I just wanted to share more comments:

On 22/02/2020 09:50, Sergey Bylokhov wrote:
> Thank you, an updated version is upload:
> http://cr.openjdk.java.net/~serb/8237746/webrev.01
>
> On 2/17/20 11:55 am, Marc Hoffmann wrote:
>> Thanks Alexey for the detailed review! I attached a updated version.
>>
>> The examples have many cleanup opportunities. I wanted to focus on 
>> compiler warnings for now and keep the changeset minimal.

Yes, I agree. It's better to fix one problem at a time.

>> <SNIP>
>>
>>> *ButtonDemo.java*
>>> 64???? Vector<Component> buttons = new Vector<>();
>>> Shall it be JComponent?
>>
>> Doesn?t because JPanel.add() returns Component:
>>
>> ???? buttons.add(p2.add(new JButton(getString("ButtonDemo.button1"))));
>>
>> Should I introduce a local variable?

It could be another opportunity to contribute and clean up.

Vector can be replaced with ArrayList; and Component with 
AbstractButton, then the type casts and instanceof checks in listeners 
can be cleaned up too.

>>> *ComboBoxDemo.java*
>>> 60???? JComboBox<?> hairCB;
>>> Why not JComboBox<String> ?
>>> All createXXX methods use this type.
>>> Then the cast below would be unnecessary:
>>> 282???????????? String name = (String) 
>>> parts.get(hairCB.getSelectedItem());
>>
>> This comes from the lookup in the parts Hashtable. Unfortunately it 
>> has String an ImageIcon values.

Probably this could also be made cleaner then? Or maybe it's not worth it.

>>
>>>
>>>
>>> 114???????? presetCB = (JComboBox<?>) 
>>> comboBoxPanel.add(createPresetComboBox());
>>> To avoid cast, you can use two statements:
>>> presetCB = createPresetComboBox();
>>> comboBoxPanel.add(presetCB);
>>
>> Done for all 4 occurrences.
>>
>>>
>>>
>>> *DirectionPanel.java*
>>> 97???????????????? AbstractButton b = e.nextElement();
>>> 98???????????? if( b.getActionCommand().equals(selection) ) {
>>> Indentation on line 97 seems incorrect, it should align to line 98, 
>>> shouldn't it?
>>
>> Done (replace tab with spaces).
>>
>>>
>>>
>>> *SliderDemo.java*
>>> 167???????? @SuppressWarnings("unchecked")
>>> 168???????????????? Dictionary<Object, Object> labelTable = 
>>> s.getLabelTable();
>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>> I mean that @SuppressWarning would become unnecessary.
>>
>> Dictionary<?,?> does not allow put of specific types in the next 
>> line. But fixed tabs in the same line.

I see, it comes from JSlider.get/setLabelTable which use the raw type 
Dictionary.
So probably the API of JSlider itself can be updated to accept 
Dictionary<Integer, ? extends JComponent>.

The generification of these two methods of JSlider was reverted to raw 
types under https://bugs.openjdk.java.net/browse/JDK-8055254 because 
SwingSet2 did not compile. So it should be a coordinated change to both 
the API and the demo.

>>> <SNIP>
-- 
Regards,
Alexey

From hoffmann at mountainminds.com  Wed Mar 11 20:22:32 2020
From: hoffmann at mountainminds.com (Marc Hoffmann)
Date: Wed, 11 Mar 2020 21:22:32 +0100
Subject: [OpenJDK 2D-Dev] <Swing Dev> [15] Review Request: 8237746
 Fixing compiler warnings in src/demo/share/jfc
In-Reply-To: <8d627478-3af5-49cd-df43-c9caf5551be1@oracle.com>
References: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
 <C234EDBB-20AA-4921-9836-0F9F1F2AF4B5@mountainminds.com>
 <e199e3ef-f2a8-81b7-9714-dc1f9d07cc39@oracle.com>
 <FBD35B62-ED3D-4C05-9147-60F08E4E3774@mountainminds.com>
 <9eae8ba3-dfe8-1e9e-1997-51e213bb45f5@oracle.com>
 <8d627478-3af5-49cd-df43-c9caf5551be1@oracle.com>
Message-ID: <20D3C5AC-C49C-4201-9326-F3EFB8AFB481@mountainminds.com>

Hi Alexey,

I?m happy to add more small fixes at a later point in time. Please understand that I?m not a Swing expert. But I could help to make the code look cleaner and more like modern Java.

Also I think the example code is used in some regression tests, right? So I need to make sure not to break those. Is there documentation or any pointers how to run those tests?

Regards,
-marc 

> On 11. Mar 2020, at 21:07, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
> 
> Thank you to Marc for updating webrev and to Sergey for uploading it.
> 
> The changes look fine to me as I already stated.
> 
> I just wanted to share more comments:
> 
> On 22/02/2020 09:50, Sergey Bylokhov wrote:
>> Thank you, an updated version is upload:
>> http://cr.openjdk.java.net/~serb/8237746/webrev.01
>> 
>> On 2/17/20 11:55 am, Marc Hoffmann wrote:
>>> Thanks Alexey for the detailed review! I attached a updated version.
>>> 
>>> The examples have many cleanup opportunities. I wanted to focus on compiler warnings for now and keep the changeset minimal.
> 
> Yes, I agree. It's better to fix one problem at a time.
> 
>>> <SNIP>
>>> 
>>>> *ButtonDemo.java*
>>>> 64     Vector<Component> buttons = new Vector<>();
>>>> Shall it be JComponent?
>>> 
>>> Doesn?t because JPanel.add() returns Component:
>>> 
>>>      buttons.add(p2.add(new JButton(getString("ButtonDemo.button1"))));
>>> 
>>> Should I introduce a local variable?
> 
> It could be another opportunity to contribute and clean up.
> 
> Vector can be replaced with ArrayList; and Component with AbstractButton, then the type casts and instanceof checks in listeners can be cleaned up too.
> 
>>>> *ComboBoxDemo.java*
>>>> 60     JComboBox<?> hairCB;
>>>> Why not JComboBox<String> ?
>>>> All createXXX methods use this type.
>>>> Then the cast below would be unnecessary:
>>>> 282             String name = (String) parts.get(hairCB.getSelectedItem());
>>> 
>>> This comes from the lookup in the parts Hashtable. Unfortunately it has String an ImageIcon values.
> 
> Probably this could also be made cleaner then? Or maybe it's not worth it.
> 
>>> 
>>>> 
>>>> 
>>>> 114         presetCB = (JComboBox<?>) comboBoxPanel.add(createPresetComboBox());
>>>> To avoid cast, you can use two statements:
>>>> presetCB = createPresetComboBox();
>>>> comboBoxPanel.add(presetCB);
>>> 
>>> Done for all 4 occurrences.
>>> 
>>>> 
>>>> 
>>>> *DirectionPanel.java*
>>>> 97                 AbstractButton b = e.nextElement();
>>>> 98             if( b.getActionCommand().equals(selection) ) {
>>>> Indentation on line 97 seems incorrect, it should align to line 98, shouldn't it?
>>> 
>>> Done (replace tab with spaces).
>>> 
>>>> 
>>>> 
>>>> *SliderDemo.java*
>>>> 167         @SuppressWarnings("unchecked")
>>>> 168                 Dictionary<Object, Object> labelTable = s.getLabelTable();
>>>> Would using Dictionary<?, ?> suppress the warning automatically?
>>>> I mean that @SuppressWarning would become unnecessary.
>>> 
>>> Dictionary<?,?> does not allow put of specific types in the next line. But fixed tabs in the same line.
> 
> I see, it comes from JSlider.get/setLabelTable which use the raw type Dictionary.
> So probably the API of JSlider itself can be updated to accept Dictionary<Integer, ? extends JComponent>.
> 
> The generification of these two methods of JSlider was reverted to raw types under https://bugs.openjdk.java.net/browse/JDK-8055254 because SwingSet2 did not compile. So it should be a coordinated change to both the API and the demo.
> 
>>>> <SNIP>
> -- 
> Regards,
> Alexey


From kustaa.nyholm at sparetimelabs.com  Thu Mar 12 09:40:49 2020
From: kustaa.nyholm at sparetimelabs.com (Kustaa Nyholm)
Date: Thu, 12 Mar 2020 09:40:49 +0000
Subject: [OpenJDK 2D-Dev] Java2D Queue Flusher  crash
Message-ID: <10FEAA8C-55C0-4335-9045-09AE24C63DA7@sparetimelabs.com>

Hi,

not sure this is the right place.

I looked for a place to file bugs or contribute to an existing bug report but did not find the place.

Found a lot of old and newer bugs that looked a lot like this.

It seems that Java2D Queue Flusher is a 'catch all' place to crash for various bugs elsewhere. ;) 

Some bugs are marked as fixed but I just got a report from a customer where this happened three times in one day 
but has not happened since and had not happened for weeks.

There seesm to be no rhyme or reason or repeating pattern when this happens.

The computer was/is MacBook Pro 11 with High Sierra.

The version that this happens with is:

openjdk 11.0.1 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)



I have the full crash reports but if this is the wrong place I won't post them here, so here is
only a sampling of the crash report.

wbr Kusti


Thread 23 Crashed:: Java: Java2D Queue Flusher
0   libsystem_kernel.dylib        	0x00007fff66899b66 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff66a64080 pthread_kill + 333
2   libsystem_c.dylib             	0x00007fff667f51ae abort + 127
3   libGPUSupport.dylib           	0x00007fff57251118 gpusKillClient + 93
4   com.apple.driver.AppleIntelHD3000GraphicsGLDriver	0x000000011be8773f GhalInterface::getCommandBuffer(unsigned char**, unsigned char**, unsigned int*, unsigned int*) + 143
5   com.apple.driver.AppleIntelHD3000GraphicsGLDriver	0x000000011bea3781 GHAL3D::CPrivateCommandTransport::FlushCommandBuffer(GHAL3D::FLUSH_TYPE, unsigned char) + 273
6   com.apple.driver.AppleIntelHD3000GraphicsGLDriver	0x000000011bea3550 g575SubmitPacketsToken + 67
7   libawt_lwawt.dylib            	0x0000000108e7bdbb OGLSD_MakeOGLContextCurrent + 65
8   libawt_lwawt.dylib            	0x0000000108e9be25 OGLContext_SetSurfaces + 133
9   libawt_lwawt.dylib            	0x0000000108e9ffb8 Java_sun_java2d_opengl_OGLRenderQueue_flushBuffer + 2324
10  ???                           	0x0000000111b4e57d 0 + 4592035197
11  ???                           	0x0000000112039ec0 0 + 4597194432


From Sergey.Bylokhov at oracle.com  Thu Mar 12 16:09:02 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 12 Mar 2020 09:09:02 -0700
Subject: [OpenJDK 2D-Dev] Java2D Queue Flusher crash
In-Reply-To: <10FEAA8C-55C0-4335-9045-09AE24C63DA7@sparetimelabs.com>
References: <10FEAA8C-55C0-4335-9045-09AE24C63DA7@sparetimelabs.com>
Message-ID: <81098156-52f8-b8c0-6584-c82ea61027b7@oracle.com>

Hi,

As a first step, I suggest updating JDK to jdk11.0.6 where[1] was fixed(or jdk14[2])

It was the biggest root cause of similar crashes. If it does not help
then we will need some testcase or steps to reproduce the problem because
the crash happens in the intel OGL driver when we simply call glFlush.

[1] https://bugs.openjdk.java.net/browse/JDK-8146238
[2] https://jdk.java.net/14/

On 3/12/20 2:40 am, Kustaa Nyholm wrote:
> Hi,
> 
> not sure this is the right place.
> 
> I looked for a place to file bugs or contribute to an existing bug report but did not find the place.
> 
> Found a lot of old and newer bugs that looked a lot like this.
> 
> It seems that Java2D Queue Flusher is a 'catch all' place to crash for various bugs elsewhere. ;)
> 
> Some bugs are marked as fixed but I just got a report from a customer where this happened three times in one day
> but has not happened since and had not happened for weeks.
> 
> There seesm to be no rhyme or reason or repeating pattern when this happens.
> 
> The computer was/is MacBook Pro 11 with High Sierra.
> 
> The version that this happens with is:
> 
> openjdk 11.0.1 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
> 
> 
> 
> I have the full crash reports but if this is the wrong place I won't post them here, so here is
> only a sampling of the crash report.
> 
> wbr Kusti
> 
> 
> Thread 23 Crashed:: Java: Java2D Queue Flusher
> 0   libsystem_kernel.dylib        	0x00007fff66899b66 __pthread_kill + 10
> 1   libsystem_pthread.dylib       	0x00007fff66a64080 pthread_kill + 333
> 2   libsystem_c.dylib             	0x00007fff667f51ae abort + 127
> 3   libGPUSupport.dylib           	0x00007fff57251118 gpusKillClient + 93
> 4   com.apple.driver.AppleIntelHD3000GraphicsGLDriver	0x000000011be8773f GhalInterface::getCommandBuffer(unsigned char**, unsigned char**, unsigned int*, unsigned int*) + 143
> 5   com.apple.driver.AppleIntelHD3000GraphicsGLDriver	0x000000011bea3781 GHAL3D::CPrivateCommandTransport::FlushCommandBuffer(GHAL3D::FLUSH_TYPE, unsigned char) + 273
> 6   com.apple.driver.AppleIntelHD3000GraphicsGLDriver	0x000000011bea3550 g575SubmitPacketsToken + 67
> 7   libawt_lwawt.dylib            	0x0000000108e7bdbb OGLSD_MakeOGLContextCurrent + 65
> 8   libawt_lwawt.dylib            	0x0000000108e9be25 OGLContext_SetSurfaces + 133
> 9   libawt_lwawt.dylib            	0x0000000108e9ffb8 Java_sun_java2d_opengl_OGLRenderQueue_flushBuffer + 2324
> 10  ???                           	0x0000000111b4e57d 0 + 4592035197
> 11  ???                           	0x0000000112039ec0 0 + 4597194432
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Mar 12 16:17:21 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 12 Mar 2020 09:17:21 -0700
Subject: [OpenJDK 2D-Dev] Java2D Queue Flusher crash
In-Reply-To: <81098156-52f8-b8c0-6584-c82ea61027b7@oracle.com>
References: <10FEAA8C-55C0-4335-9045-09AE24C63DA7@sparetimelabs.com>
 <81098156-52f8-b8c0-6584-c82ea61027b7@oracle.com>
Message-ID: <5E6A6091.80902@oracle.com>


Note that JDK 14 GA's next Tuesday - 17th March 2020.

Also the place to file bugs is https://bugreport.java.com/bugreport/

This list is the place to propose a source code fix for an existing bug.

-phil.

On 3/12/20, 9:09 AM, Sergey Bylokhov wrote:
> Hi,
>
> As a first step, I suggest updating JDK to jdk11.0.6 where[1] was 
> fixed(or jdk14[2])
>
> It was the biggest root cause of similar crashes. If it does not help
> then we will need some testcase or steps to reproduce the problem because
> the crash happens in the intel OGL driver when we simply call glFlush.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8146238
> [2] https://jdk.java.net/14/
>
> On 3/12/20 2:40 am, Kustaa Nyholm wrote:
>> Hi,
>>
>> not sure this is the right place.
>>
>> I looked for a place to file bugs or contribute to an existing bug 
>> report but did not find the place.
>>
>> Found a lot of old and newer bugs that looked a lot like this.
>>
>> It seems that Java2D Queue Flusher is a 'catch all' place to crash 
>> for various bugs elsewhere. ;)
>>
>> Some bugs are marked as fixed but I just got a report from a customer 
>> where this happened three times in one day
>> but has not happened since and had not happened for weeks.
>>
>> There seesm to be no rhyme or reason or repeating pattern when this 
>> happens.
>>
>> The computer was/is MacBook Pro 11 with High Sierra.
>>
>> The version that this happens with is:
>>
>> openjdk 11.0.1 2018-10-16
>> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
>> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
>>
>>
>>
>> I have the full crash reports but if this is the wrong place I won't 
>> post them here, so here is
>> only a sampling of the crash report.
>>
>> wbr Kusti
>>
>>
>> Thread 23 Crashed:: Java: Java2D Queue Flusher
>> 0   libsystem_kernel.dylib            0x00007fff66899b66 
>> __pthread_kill + 10
>> 1   libsystem_pthread.dylib           0x00007fff66a64080 pthread_kill 
>> + 333
>> 2   libsystem_c.dylib                 0x00007fff667f51ae abort + 127
>> 3   libGPUSupport.dylib               0x00007fff57251118 
>> gpusKillClient + 93
>> 4   com.apple.driver.AppleIntelHD3000GraphicsGLDriver    
>> 0x000000011be8773f GhalInterface::getCommandBuffer(unsigned char**, 
>> unsigned char**, unsigned int*, unsigned int*) + 143
>> 5   com.apple.driver.AppleIntelHD3000GraphicsGLDriver    
>> 0x000000011bea3781 
>> GHAL3D::CPrivateCommandTransport::FlushCommandBuffer(GHAL3D::FLUSH_TYPE, 
>> unsigned char) + 273
>> 6   com.apple.driver.AppleIntelHD3000GraphicsGLDriver    
>> 0x000000011bea3550 g575SubmitPacketsToken + 67
>> 7   libawt_lwawt.dylib                0x0000000108e7bdbb 
>> OGLSD_MakeOGLContextCurrent + 65
>> 8   libawt_lwawt.dylib                0x0000000108e9be25 
>> OGLContext_SetSurfaces + 133
>> 9   libawt_lwawt.dylib                0x0000000108e9ffb8 
>> Java_sun_java2d_opengl_OGLRenderQueue_flushBuffer + 2324
>> 10  ???                               0x0000000111b4e57d 0 + 4592035197
>> 11  ???                               0x0000000112039ec0 0 + 4597194432
>>
>
>

From philip.race at oracle.com  Tue Mar 17 16:34:34 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 17 Mar 2020 09:34:34 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
 java/awt/font/WindowsIndicFonts.java fails on windows10
Message-ID: <5E70FC1A.1060403@oracle.com>

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

WindowsIndicFonts has been failing randomly depending on
whether a test system has the Indic fonts installed.
This updates the test to not fail on systems which don't have the expected
fonts installed in the typical default location.

-phil.




From JAYATHIRTH.D.V at ORACLE.COM  Tue Mar 17 17:10:28 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Tue, 17 Mar 2020 22:40:28 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
 java/awt/font/WindowsIndicFonts.java fails on windows10
In-Reply-To: <5E70FC1A.1060403@oracle.com>
References: <5E70FC1A.1060403@oracle.com>
Message-ID: <843163D1-F292-473D-A431-A2EC5EAE777B@ORACLE.COM>

Looks good to me.

Thanks,
Jay

> On 17-Mar-2020, at 10:04 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223935
> Webrev: http://cr.openjdk.java.net/~prr/8223935/
> 
> WindowsIndicFonts has been failing randomly depending on
> whether a test system has the Indic fonts installed.
> This updates the test to not fail on systems which don't have the expected
> fonts installed in the typical default location.
> 
> -phil.
> 
> 
> 


From Sergey.Bylokhov at oracle.com  Tue Mar 17 18:24:44 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Mar 2020 11:24:44 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
 java/awt/font/WindowsIndicFonts.java fails on windows10
In-Reply-To: <5E70FC1A.1060403@oracle.com>
References: <5E70FC1A.1060403@oracle.com>
Message-ID: <a4f3b6e9-2d86-953f-3a5d-e4d5ba925199@oracle.com>

Hi, Phil.

Probably it is better to use "%SYSTEMROOT%\Fonts" instead of "c:\\windows\\fonts"?

On 3/17/20 9:34 am, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223935
> Webrev: http://cr.openjdk.java.net/~prr/8223935/
> 
> WindowsIndicFonts has been failing randomly depending on
> whether a test system has the Indic fonts installed.
> This updates the test to not fail on systems which don't have the expected
> fonts installed in the typical default location.
> 
> -phil.
> 
> 
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Mar 17 23:59:55 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 17 Mar 2020 16:59:55 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
 java/awt/font/WindowsIndicFonts.java fails on windows10
In-Reply-To: <a4f3b6e9-2d86-953f-3a5d-e4d5ba925199@oracle.com>
References: <5E70FC1A.1060403@oracle.com>
 <a4f3b6e9-2d86-953f-3a5d-e4d5ba925199@oracle.com>
Message-ID: <5E71647B.1030006@oracle.com>

Done.

http://cr.openjdk.java.net/~prr/8223935.1/

Log looks like this :-

SysRootDir=C:\\Windows
found:C:\\Windows\\fonts\\mangal.ttf for Devanagari
found:C:\\Windows\\fonts\\vrinda.ttf for Bengali
found:C:\\Windows\\fonts\\raavi.ttf for Gurmukhi
found:C:\\Windows\\fonts\\shruti.ttf for Gujurati
found:C:\\Windows\\fonts\\kalinga.ttf for Oriya
found:C:\\Windows\\fonts\\latha.ttf for Tamil
found:C:\\Windows\\fonts\\gautami.ttf for Telugu
found:C:\\Windows\\fonts\\tunga.ttf for Kannada
found:C:\\Windows\\fonts\\kartika.ttf for Malayalam
found:C:\\Windows\\fonts\\iskpota.ttf for Sinhala
found:C:\\Windows\\fonts\\dokchamp.ttf for Thai
found:C:\\Windows\\fonts\\dokchamp.ttf for Lao
found:C:\\Windows\\fonts\\khmerui.ttf for Khmer
found:C:\\Windows\\fonts\\monbaiti.ttf for Mongolian

-phil.



On 3/17/20, 11:24 AM, Sergey Bylokhov wrote:
> Hi, Phil.
>
> Probably it is better to use "%SYSTEMROOT%\Fonts" instead of 
> "c:\\windows\\fonts"?
>
> On 3/17/20 9:34 am, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223935
>> Webrev: http://cr.openjdk.java.net/~prr/8223935/
>>
>> WindowsIndicFonts has been failing randomly depending on
>> whether a test system has the Indic fonts installed.
>> This updates the test to not fail on systems which don't have the 
>> expected
>> fonts installed in the typical default location.
>>
>> -phil.
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200317/d30d85a0/attachment.htm>

From Sergey.Bylokhov at oracle.com  Wed Mar 18 00:23:09 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Mar 2020 17:23:09 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
 java/awt/font/WindowsIndicFonts.java fails on windows10
In-Reply-To: <5E71647B.1030006@oracle.com>
References: <5E70FC1A.1060403@oracle.com>
 <a4f3b6e9-2d86-953f-3a5d-e4d5ba925199@oracle.com>
 <5E71647B.1030006@oracle.com>
Message-ID: <0cb05105-cba1-2c2c-0901-5887ff9e039b@oracle.com>

Looks fine.

On 3/17/20 4:59 pm, Philip Race wrote:
> Done.
> 
> http://cr.openjdk.java.net/~prr/8223935.1/
> 
> Log looks like this :-
> 
> SysRootDir=C:\\Windows
> found:C:\\Windows\\fonts\\mangal.ttf for Devanagari
> found:C:\\Windows\\fonts\\vrinda.ttf for Bengali
> found:C:\\Windows\\fonts\\raavi.ttf for Gurmukhi
> found:C:\\Windows\\fonts\\shruti.ttf for Gujurati
> found:C:\\Windows\\fonts\\kalinga.ttf for Oriya
> found:C:\\Windows\\fonts\\latha.ttf for Tamil
> found:C:\\Windows\\fonts\\gautami.ttf for Telugu
> found:C:\\Windows\\fonts\\tunga.ttf for Kannada
> found:C:\\Windows\\fonts\\kartika.ttf for Malayalam
> found:C:\\Windows\\fonts\\iskpota.ttf for Sinhala
> found:C:\\Windows\\fonts\\dokchamp.ttf for Thai
> found:C:\\Windows\\fonts\\dokchamp.ttf for Lao
> found:C:\\Windows\\fonts\\khmerui.ttf for Khmer
> found:C:\\Windows\\fonts\\monbaiti.ttf for Mongolian
> 
> -phil.
> 
> 
> 
> On 3/17/20, 11:24 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>>
>> Probably it is better to use "%SYSTEMROOT%\Fonts" instead of "c:\\windows\\fonts"?
>>
>> On 3/17/20 9:34 am, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223935
>>> Webrev: http://cr.openjdk.java.net/~prr/8223935/
>>>
>>> WindowsIndicFonts has been failing randomly depending on
>>> whether a test system has the Indic fonts installed.
>>> This updates the test to not fail on systems which don't have the expected
>>> fonts installed in the typical default location.
>>>
>>> -phil.
>>>
>>>
>>>
>>
>>


-- 
Best regards, Sergey.

From christoph.langer at sap.com  Wed Mar 18 08:39:43 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Mar 2020 08:39:43 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
 java/awt/font/WindowsIndicFonts.java fails on windows10
In-Reply-To: <5E71647B.1030006@oracle.com>
References: <5E70FC1A.1060403@oracle.com>
 <a4f3b6e9-2d86-953f-3a5d-e4d5ba925199@oracle.com>
 <5E71647B.1030006@oracle.com>
Message-ID: <AM0PR02MB5714D26503974355A47D83AD8AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Phil,



good to see this finally getting fixed.



Changes look good to me. I?m wondering, though, whether a SkippedException should be thrown when there fonts are not found? On the other hand, the test still probably always tests something, even if certain fonts are missing.



Best regards

Christoph



From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Philip Race
Sent: Mittwoch, 18. M?rz 2020 01:00
To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
Cc: 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8223935: PIT: java/awt/font/WindowsIndicFonts.java fails on windows10



Done.

http://cr.openjdk.java.net/~prr/8223935.1/

Log looks like this :-

SysRootDir=C:\\Windows
found:C:\\Windows\\fonts\\mangal.ttf for Devanagari
found:C:\\Windows\\fonts\\vrinda.ttf for Bengali
found:C:\\Windows\\fonts\\raavi.ttf for Gurmukhi
found:C:\\Windows\\fonts\\shruti.ttf for Gujurati
found:C:\\Windows\\fonts\\kalinga.ttf for Oriya
found:C:\\Windows\\fonts\\latha.ttf for Tamil
found:C:\\Windows\\fonts\\gautami.ttf for Telugu
found:C:\\Windows\\fonts\\tunga.ttf for Kannada
found:C:\\Windows\\fonts\\kartika.ttf for Malayalam
found:C:\\Windows\\fonts\\iskpota.ttf for Sinhala
found:C:\\Windows\\fonts\\dokchamp.ttf for Thai
found:C:\\Windows\\fonts\\dokchamp.ttf for Lao
found:C:\\Windows\\fonts\\khmerui.ttf for Khmer
found:C:\\Windows\\fonts\\monbaiti.ttf for Mongolian

-phil.



On 3/17/20, 11:24 AM, Sergey Bylokhov wrote:

   Hi, Phil.

   Probably it is better to use "%SYSTEMROOT%\Fonts" instead of "c:\\windows\\fonts"?

   On 3/17/20 9:34 am, Philip Race wrote:



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

      WindowsIndicFonts has been failing randomly depending on
      whether a test system has the Indic fonts installed.
      This updates the test to not fail on systems which don't have the expected
      fonts installed in the typical default location.

      -phil.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200318/9bae04c3/attachment-0001.htm>

From philip.race at oracle.com  Fri Mar 20 23:19:13 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 20 Mar 2020 16:19:13 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8232634: Problem List ICMColorDataTest.java
Message-ID: <5E754F71.8060400@oracle.com>

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

This test ICMColorDataTest.java takes a very long time on Windows and 
still too long on other platforms.
It will be investigated as bug 
https://bugs.openjdk.java.net/browse/JDK-8233028
In the mean time we will problem list it :

Fix:
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -254,6 +254,7 @@
  java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all
  java/awt/FontMetrics/FontCrash.java 8198336 windows-all
  java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305,8231495 
solaris-all,macosx-all,linux-all
+java/awt/image/BufferedImage/ICMColorDataTest/ICMColorDataTest.java 
8233028 generic-all
  java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all
  java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 
windows-all
  java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 
8196025 windows-all

-phil.


From Sergey.Bylokhov at oracle.com  Fri Mar 20 23:34:53 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 20 Mar 2020 16:34:53 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8232634: Problem List
	ICMColorDataTest.java
In-Reply-To: <5E754F71.8060400@oracle.com>
References: <5E754F71.8060400@oracle.com>
Message-ID: <98b6320b-aefd-041b-bd01-5d7fe2747b17@oracle.com>

Looks fine.

On 3/20/20 4:19 pm, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
> 
> This test ICMColorDataTest.java takes a very long time on Windows and still too long on other platforms.
> It will be investigated as bug https://bugs.openjdk.java.net/browse/JDK-8233028
> In the mean time we will problem list it :
> 
> Fix:
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -254,6 +254,7 @@
>  ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all
>  ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all
>  ?java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305,8231495 solaris-all,macosx-all,linux-all
> +java/awt/image/BufferedImage/ICMColorDataTest/ICMColorDataTest.java 8233028 generic-all
>  ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all
>  ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 windows-all
>  ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 8196025 windows-all
> 
> -phil.
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Sat Mar 21 04:28:24 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 21 Mar 2020 09:58:24 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8232634: Problem List
	ICMColorDataTest.java
In-Reply-To: <5E754F71.8060400@oracle.com>
References: <5E754F71.8060400@oracle.com>
Message-ID: <708f69d8-7add-0ad4-a243-c603b21bbf90@oracle.com>

Shouldn't it be only on windows-all as the problem manifests now only in 
windows? linux-mac are working and as fast it can be.

Regards
Prasanta
On 21-Mar-20 4:49 AM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
>
> This test ICMColorDataTest.java takes a very long time on Windows and 
> still too long on other platforms.
> It will be investigated as bug 
> https://bugs.openjdk.java.net/browse/JDK-8233028
> In the mean time we will problem list it :
>
> Fix:
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -254,6 +254,7 @@
> ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all
> ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all
> ?java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305,8231495 
> solaris-all,macosx-all,linux-all
> +java/awt/image/BufferedImage/ICMColorDataTest/ICMColorDataTest.java 
> 8233028 generic-all
> ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 
> generic-all
> ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 
> windows-all
> ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 
> 8196025 windows-all
>
> -phil.
>

From prasanta.sadhukhan at oracle.com  Sat Mar 21 04:30:05 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 21 Mar 2020 10:00:05 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8232634: Problem List
	ICMColorDataTest.java
In-Reply-To: <708f69d8-7add-0ad4-a243-c603b21bbf90@oracle.com>
References: <5E754F71.8060400@oracle.com>
 <708f69d8-7add-0ad4-a243-c603b21bbf90@oracle.com>
Message-ID: <f45fea4e-8c41-4d19-af9a-401bd0522b8c@oracle.com>


On 21-Mar-20 9:58 AM, Prasanta Sadhukhan wrote:
> Shouldn't it be only on windows-all as the problem manifests now only 
> in windows? linux-mac are working and as fast it can be.
I mean it was mentioned it takes 3-4 minutes in linux-mac and 30-odd 
minutes in windows.
>
> Regards
> Prasanta
> On 21-Mar-20 4:49 AM, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
>>
>> This test ICMColorDataTest.java takes a very long time on Windows and 
>> still too long on other platforms.
>> It will be investigated as bug 
>> https://bugs.openjdk.java.net/browse/JDK-8233028
>> In the mean time we will problem list it :
>>
>> Fix:
>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -254,6 +254,7 @@
>> ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all
>> ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all
>> ?java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305,8231495 
>> solaris-all,macosx-all,linux-all
>> +java/awt/image/BufferedImage/ICMColorDataTest/ICMColorDataTest.java 
>> 8233028 generic-all
>> ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 
>> generic-all
>> ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 
>> windows-all
>> ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 
>> 8196025 windows-all
>>
>> -phil.
>>

From philip.race at oracle.com  Sat Mar 21 05:46:44 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 20 Mar 2020 22:46:44 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8232634: Problem List
	ICMColorDataTest.java
In-Reply-To: <f45fea4e-8c41-4d19-af9a-401bd0522b8c@oracle.com>
References: <5E754F71.8060400@oracle.com>
 <708f69d8-7add-0ad4-a243-c603b21bbf90@oracle.com>
 <f45fea4e-8c41-4d19-af9a-401bd0522b8c@oracle.com>
Message-ID: <5E75AA44.8090807@oracle.com>

Fair enough. But I'd still prefer to still p-l it on all platforms since 
there
is no clear explanation of why this is worse on one platform than another.

-phil.

On 3/20/20, 9:30 PM, Prasanta Sadhukhan wrote:
>
> On 21-Mar-20 9:58 AM, Prasanta Sadhukhan wrote:
>> Shouldn't it be only on windows-all as the problem manifests now only 
>> in windows? linux-mac are working and as fast it can be.
> I mean it was mentioned it takes 3-4 minutes in linux-mac and 30-odd 
> minutes in windows.
>>
>> Regards
>> Prasanta
>> On 21-Mar-20 4:49 AM, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
>>>
>>> This test ICMColorDataTest.java takes a very long time on Windows 
>>> and still too long on other platforms.
>>> It will be investigated as bug 
>>> https://bugs.openjdk.java.net/browse/JDK-8233028
>>> In the mean time we will problem list it :
>>>
>>> Fix:
>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>>> --- a/test/jdk/ProblemList.txt
>>> +++ b/test/jdk/ProblemList.txt
>>> @@ -254,6 +254,7 @@
>>>  java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all
>>>  java/awt/FontMetrics/FontCrash.java 8198336 windows-all
>>>  java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305,8231495 
>>> solaris-all,macosx-all,linux-all
>>> +java/awt/image/BufferedImage/ICMColorDataTest/ICMColorDataTest.java 
>>> 8233028 generic-all
>>>  java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 
>>> generic-all
>>>  java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 
>>> 8196025 windows-all
>>>  java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 
>>> 8196025 windows-all
>>>
>>> -phil.
>>>

From prasanta.sadhukhan at oracle.com  Sat Mar 21 05:47:58 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 21 Mar 2020 11:17:58 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8232634: Problem List
	ICMColorDataTest.java
In-Reply-To: <5E75AA44.8090807@oracle.com>
References: <5E754F71.8060400@oracle.com>
 <708f69d8-7add-0ad4-a243-c603b21bbf90@oracle.com>
 <f45fea4e-8c41-4d19-af9a-401bd0522b8c@oracle.com>
 <5E75AA44.8090807@oracle.com>
Message-ID: <acee4165-5492-6dca-726d-1254f58bb2ef@oracle.com>

ok.

Regards
Prasanta
On 21-Mar-20 11:16 AM, Philip Race wrote:
> Fair enough. But I'd still prefer to still p-l it on all platforms 
> since there
> is no clear explanation of why this is worse on one platform than 
> another.
>
> -phil.
>
> On 3/20/20, 9:30 PM, Prasanta Sadhukhan wrote:
>>
>> On 21-Mar-20 9:58 AM, Prasanta Sadhukhan wrote:
>>> Shouldn't it be only on windows-all as the problem manifests now 
>>> only in windows? linux-mac are working and as fast it can be.
>> I mean it was mentioned it takes 3-4 minutes in linux-mac and 30-odd 
>> minutes in windows.
>>>
>>> Regards
>>> Prasanta
>>> On 21-Mar-20 4:49 AM, Philip Race wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
>>>>
>>>> This test ICMColorDataTest.java takes a very long time on Windows 
>>>> and still too long on other platforms.
>>>> It will be investigated as bug 
>>>> https://bugs.openjdk.java.net/browse/JDK-8233028
>>>> In the mean time we will problem list it :
>>>>
>>>> Fix:
>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>>>> --- a/test/jdk/ProblemList.txt
>>>> +++ b/test/jdk/ProblemList.txt
>>>> @@ -254,6 +254,7 @@
>>>> ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all
>>>> ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all
>>>> ?java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305,8231495 
>>>> solaris-all,macosx-all,linux-all
>>>> +java/awt/image/BufferedImage/ICMColorDataTest/ICMColorDataTest.java 
>>>> 8233028 generic-all
>>>> ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 
>>>> generic-all
>>>> ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 
>>>> 8196025 windows-all
>>>> ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 
>>>> 8196025 windows-all
>>>>
>>>> -phil.
>>>>

From magnus.ihse.bursie at oracle.com  Mon Mar 23 19:03:26 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 23 Mar 2020 20:03:26 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to respective
	modules
Message-ID: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>

The build tools (small java tools that are run during the build to 
generate source code, or data, needed in the JDK) have historically been 
placed in the "make" directory. This maybe made sense long time ago, but 
does not do so anymore.

Instead, the build tools source code should move the the module that 
needs them. For instance, compilefontconfig should move to java.desktop, 
etc.

There are multiple reasons for this:

* Currently we build *all* build tools at once, which mean that we 
cannot compile java.base until e.g. the compilefontconfig tool is 
compiled, even though it is not needed.

* If a build tool, e.g. compilefontconfig is modified, all build tools 
are recompiled, which triggers a rebuild of more or less the entire JDK. 
This makes development of the build tools unnecessary tedious.

* When the build tools are modified, the group owning the corresponding 
module is the proper review instance, not the build team. But since they 
reside under "make", the review mails often include build-dev, but this 
is mostly noise for us. With this move, the ownership is made clear.

In this patch, I have not modified how and when the build tools are 
compiled, but this shuffle is the prerequisite for continuing with that 
in a follow-up patch.

I have also moved the build tools to the org.openjdk.buildtools.* 
package name space (inspired by Skara), instead of the strangely named 
build.tools.* name space.

A few build tools are not moved in this patch. Two of them, 
charsetmapping and cldrconverter, are shared between two modules. (I 
think they should move to modules nevertheless, but they need some more 
thought to make sure I do this right.) The rest are tools that are 
needed for the build in general, like linking or javadoc support. I'll 
move this to a better location too, but in a separate patch.

Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01

/Magnus


From erik.joelsson at oracle.com  Mon Mar 23 19:54:44 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Mar 2020 12:54:44 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to
	respective modules
In-Reply-To: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
References: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
Message-ID: <705f74a1-8f64-166c-63d1-7174c89443cd@oracle.com>

Looks good.

/Erik

On 2020-03-23 12:03, Magnus Ihse Bursie wrote:
> The build tools (small java tools that are run during the build to 
> generate source code, or data, needed in the JDK) have historically 
> been placed in the "make" directory. This maybe made sense long time 
> ago, but does not do so anymore.
>
> Instead, the build tools source code should move the the module that 
> needs them. For instance, compilefontconfig should move to 
> java.desktop, etc.
>
> There are multiple reasons for this:
>
> * Currently we build *all* build tools at once, which mean that we 
> cannot compile java.base until e.g. the compilefontconfig tool is 
> compiled, even though it is not needed.
>
> * If a build tool, e.g. compilefontconfig is modified, all build tools 
> are recompiled, which triggers a rebuild of more or less the entire 
> JDK. This makes development of the build tools unnecessary tedious.
>
> * When the build tools are modified, the group owning the 
> corresponding module is the proper review instance, not the build 
> team. But since they reside under "make", the review mails often 
> include build-dev, but this is mostly noise for us. With this move, 
> the ownership is made clear.
>
> In this patch, I have not modified how and when the build tools are 
> compiled, but this shuffle is the prerequisite for continuing with 
> that in a follow-up patch.
>
> I have also moved the build tools to the org.openjdk.buildtools.* 
> package name space (inspired by Skara), instead of the strangely named 
> build.tools.* name space.
>
> A few build tools are not moved in this patch. Two of them, 
> charsetmapping and cldrconverter, are shared between two modules. (I 
> think they should move to modules nevertheless, but they need some 
> more thought to make sure I do this right.) The rest are tools that 
> are needed for the build in general, like linking or javadoc support. 
> I'll move this to a better location too, but in a separate patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01
>
> /Magnus
>

From mandy.chung at oracle.com  Mon Mar 23 20:19:13 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Mar 2020 13:19:13 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to
	respective modules
In-Reply-To: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
References: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
Message-ID: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com>

Hi Magnus,

Modularizing the build tools is a good move.??? This patch suggests to 
place the build tools under
 ??? src/$MODULE/share/tools/$PACKAGE/*.java

I think the modular source location of the build tools needs more 
discussion, including jigsaw-dev for this discussion.

The JDK source as specified in JEP 201 is under:
 ??? src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java

Compiling the source files from the `src` directory are the intermediate 
input to build the resulting image.??? Build tools are used to generate 
additional intermediate input (that is not part of the `src` directory) 
to build the image.?? So I wonder if make/$MODULE/share/tools or 
make/tools/$MODULE? may be better location for the build tools.

Mandy

On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote:
> The build tools (small java tools that are run during the build to 
> generate source code, or data, needed in the JDK) have historically 
> been placed in the "make" directory. This maybe made sense long time 
> ago, but does not do so anymore.
>
> Instead, the build tools source code should move the the module that 
> needs them. For instance, compilefontconfig should move to 
> java.desktop, etc.
>
> There are multiple reasons for this:
>
> * Currently we build *all* build tools at once, which mean that we 
> cannot compile java.base until e.g. the compilefontconfig tool is 
> compiled, even though it is not needed.
>
> * If a build tool, e.g. compilefontconfig is modified, all build tools 
> are recompiled, which triggers a rebuild of more or less the entire 
> JDK. This makes development of the build tools unnecessary tedious.
>
> * When the build tools are modified, the group owning the 
> corresponding module is the proper review instance, not the build 
> team. But since they reside under "make", the review mails often 
> include build-dev, but this is mostly noise for us. With this move, 
> the ownership is made clear.
>
> In this patch, I have not modified how and when the build tools are 
> compiled, but this shuffle is the prerequisite for continuing with 
> that in a follow-up patch.
>
> I have also moved the build tools to the org.openjdk.buildtools.* 
> package name space (inspired by Skara), instead of the strangely named 
> build.tools.* name space.
>
> A few build tools are not moved in this patch. Two of them, 
> charsetmapping and cldrconverter, are shared between two modules. (I 
> think they should move to modules nevertheless, but they need some 
> more thought to make sure I do this right.) The rest are tools that 
> are needed for the build in general, like linking or javadoc support. 
> I'll move this to a better location too, but in a separate patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01
>
> /Magnus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200323/9eabd984/attachment.htm>

From Alan.Bateman at oracle.com  Mon Mar 23 20:33:50 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2020 20:33:50 +0000
Subject: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to
	respective modules
In-Reply-To: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
References: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
Message-ID: <20158b4b-f6f1-92e1-59da-d0f6c07a85ca@oracle.com>



On 23/03/2020 19:03, Magnus Ihse Bursie wrote:
> The build tools (small java tools that are run during the build to 
> generate source code, or data, needed in the JDK) have historically 
> been placed in the "make" directory. This maybe made sense long time 
> ago, but does not do so anymore.
>
> Instead, the build tools source code should move the the module that 
> needs them. For instance, compilefontconfig should move to 
> java.desktop, etc.
>
> There are multiple reasons for this:
>
> * Currently we build *all* build tools at once, which mean that we 
> cannot compile java.base until e.g. the compilefontconfig tool is 
> compiled, even though it is not needed.
>
> * If a build tool, e.g. compilefontconfig is modified, all build tools 
> are recompiled, which triggers a rebuild of more or less the entire 
> JDK. This makes development of the build tools unnecessary tedious.
>
> * When the build tools are modified, the group owning the 
> corresponding module is the proper review instance, not the build 
> team. But since they reside under "make", the review mails often 
> include build-dev, but this is mostly noise for us. With this move, 
> the ownership is made clear.
>
> In this patch, I have not modified how and when the build tools are 
> compiled, but this shuffle is the prerequisite for continuing with 
> that in a follow-up patch.
>
> I have also moved the build tools to the org.openjdk.buildtools.* 
> package name space (inspired by Skara), instead of the strangely named 
> build.tools.* name space.
>
> A few build tools are not moved in this patch. Two of them, 
> charsetmapping and cldrconverter, are shared between two modules. (I 
> think they should move to modules nevertheless, but they need some 
> more thought to make sure I do this right.) The rest are tools that 
> are needed for the build in general, like linking or javadoc support. 
> I'll move this to a better location too, but in a separate patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01
I think this will require further discussion, maybe even an update to 
JEP 201. I think it would be useful to see what other options were 
exploring, in particular options that organize the tools by module in 
the make tree (as it will confuse people to put them in the src tree).

-Alan

From naoto.sato at oracle.com  Mon Mar 23 22:15:31 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 23 Mar 2020 15:15:31 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to
	respective modules
In-Reply-To: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
References: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
Message-ID: <bea03feb-9ead-7261-0385-01d18a70688e@oracle.com>

Hi Magnus,

I looked at i18n related changes:

make/CopyInterimTZDB.gmk
make/ToolsJdk.gmk
make/gendata/Gendata-java.base.gmk
make/gendata/GendataBreakIterator.gmk
make/gendata/GendataTZDB.gmk
make/gensrc/GensrcCharacterData.gmk
make/gensrc/GensrcEmojiData.gmk

They look ok to me.

The *.java changes should have copyright year update.

As to charsetmapping and cldrconverter, I believe they can reside in 
java.base, as jdk.charsets and jdk.localedata modules depend on it.

Naoto

On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote:
> The build tools (small java tools that are run during the build to 
> generate source code, or data, needed in the JDK) have historically been 
> placed in the "make" directory. This maybe made sense long time ago, but 
> does not do so anymore.
> 
> Instead, the build tools source code should move the the module that 
> needs them. For instance, compilefontconfig should move to java.desktop, 
> etc.
> 
> There are multiple reasons for this:
> 
> * Currently we build *all* build tools at once, which mean that we 
> cannot compile java.base until e.g. the compilefontconfig tool is 
> compiled, even though it is not needed.
> 
> * If a build tool, e.g. compilefontconfig is modified, all build tools 
> are recompiled, which triggers a rebuild of more or less the entire JDK. 
> This makes development of the build tools unnecessary tedious.
> 
> * When the build tools are modified, the group owning the corresponding 
> module is the proper review instance, not the build team. But since they 
> reside under "make", the review mails often include build-dev, but this 
> is mostly noise for us. With this move, the ownership is made clear.
> 
> In this patch, I have not modified how and when the build tools are 
> compiled, but this shuffle is the prerequisite for continuing with that 
> in a follow-up patch.
> 
> I have also moved the build tools to the org.openjdk.buildtools.* 
> package name space (inspired by Skara), instead of the strangely named 
> build.tools.* name space.
> 
> A few build tools are not moved in this patch. Two of them, 
> charsetmapping and cldrconverter, are shared between two modules. (I 
> think they should move to modules nevertheless, but they need some more 
> thought to make sure I do this right.) The rest are tools that are 
> needed for the build in general, like linking or javadoc support. I'll 
> move this to a better location too, but in a separate patch.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 
> 
> 
> /Magnus
> 

From magnus.ihse.bursie at oracle.com  Tue Mar 24 12:12:45 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 24 Mar 2020 13:12:45 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8241463 Move build tools to
	respective modules
In-Reply-To: <bea03feb-9ead-7261-0385-01d18a70688e@oracle.com>
References: <ff05910f-9656-94e6-2aaa-ce722443017f@oracle.com>
 <bea03feb-9ead-7261-0385-01d18a70688e@oracle.com>
Message-ID: <01a1c812-1adb-a4a2-3db0-327f76c0b21c@oracle.com>

On 2020-03-23 23:15, naoto.sato at oracle.com wrote:
> Hi Magnus,
>
> I looked at i18n related changes:
>
> make/CopyInterimTZDB.gmk
> make/ToolsJdk.gmk
> make/gendata/Gendata-java.base.gmk
> make/gendata/GendataBreakIterator.gmk
> make/gendata/GendataTZDB.gmk
> make/gensrc/GensrcCharacterData.gmk
> make/gensrc/GensrcEmojiData.gmk
>
> They look ok to me.
Thank you!
>
> The *.java changes should have copyright year update.
Ok, I'll update them.
>
> As to charsetmapping and cldrconverter, I believe they can reside in 
> java.base, as jdk.charsets and jdk.localedata modules depend on it.
Okay. It's not ideal, but I think you're right. I'll move them as well.

I'll publish an updated webrev with these changes when there's agreement 
on where in the source code tree to move the files.

/Magnus
>
> Naoto
>
> On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote:
>> The build tools (small java tools that are run during the build to 
>> generate source code, or data, needed in the JDK) have historically 
>> been placed in the "make" directory. This maybe made sense long time 
>> ago, but does not do so anymore.
>>
>> Instead, the build tools source code should move the the module that 
>> needs them. For instance, compilefontconfig should move to 
>> java.desktop, etc.
>>
>> There are multiple reasons for this:
>>
>> * Currently we build *all* build tools at once, which mean that we 
>> cannot compile java.base until e.g. the compilefontconfig tool is 
>> compiled, even though it is not needed.
>>
>> * If a build tool, e.g. compilefontconfig is modified, all build 
>> tools are recompiled, which triggers a rebuild of more or less the 
>> entire JDK. This makes development of the build tools unnecessary 
>> tedious.
>>
>> * When the build tools are modified, the group owning the 
>> corresponding module is the proper review instance, not the build 
>> team. But since they reside under "make", the review mails often 
>> include build-dev, but this is mostly noise for us. With this move, 
>> the ownership is made clear.
>>
>> In this patch, I have not modified how and when the build tools are 
>> compiled, but this shuffle is the prerequisite for continuing with 
>> that in a follow-up patch.
>>
>> I have also moved the build tools to the org.openjdk.buildtools.* 
>> package name space (inspired by Skara), instead of the strangely 
>> named build.tools.* name space.
>>
>> A few build tools are not moved in this patch. Two of them, 
>> charsetmapping and cldrconverter, are shared between two modules. (I 
>> think they should move to modules nevertheless, but they need some 
>> more thought to make sure I do this right.) The rest are tools that 
>> are needed for the build in general, like linking or javadoc support. 
>> I'll move this to a better location too, but in a separate patch.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 
>>
>>
>> /Magnus
>>


From matthias.baesken at sap.com  Tue Mar 24 14:40:07 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 24 Mar 2020 14:40:07 +0000
Subject: [OpenJDK 2D-Dev] RFR [XXS]: JDK-8241491 : Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix
Message-ID: <AM0PR02MB4227EAAFE9D0942ACD9FD34A93F10@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello please review this very small fix .

Bug https://bugs.openjdk.java.net/browse/JDK-8241228   states
we need to problem list https://bugs.openjdk.java.net/browse/JDK-8241228 .
This has been done on linux + solaris already with the issue
https://bugs.openjdk.java.net/browse/JDK-8241229
but we miss aix - there we see the problem too.

Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8241491
http://cr.openjdk.java.net/~mbaesken/webrevs/8241491.0/


Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200324/4ee87beb/attachment.htm>

From christoph.langer at sap.com  Wed Mar 25 17:27:10 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 25 Mar 2020 17:27:10 +0000
Subject: [OpenJDK 2D-Dev] RFR [XXS]: JDK-8241491 : Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix
In-Reply-To: <AM0PR02MB4227EAAFE9D0942ACD9FD34A93F10@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227EAAFE9D0942ACD9FD34A93F10@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57144943BB69B1612087C0328ACE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

this looks correct, thanks for doing this. I suggest you push this exclusion directly to jdk/jdk.

Best regards
Christoph


From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Baesken, Matthias
Sent: Dienstag, 24. M?rz 2020 15:40
To: 2d-dev at openjdk.java.net; Phil Race (philip.race at oracle.com) <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: [CAUTION] [OpenJDK 2D-Dev] RFR [XXS]: JDK-8241491 : Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix

Hello please review this very small fix .

Bug https://bugs.openjdk.java.net/browse/JDK-8241228   states
we need to problem list https://bugs.openjdk.java.net/browse/JDK-8241228 .
This has been done on linux + solaris already with the issue
https://bugs.openjdk.java.net/browse/JDK-8241229
but we miss aix - there we see the problem too.

Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8241491
http://cr.openjdk.java.net/~mbaesken/webrevs/8241491.0/


Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200325/8a1cc66d/attachment.htm>

From matthias.baesken at sap.com  Thu Mar 26 07:34:54 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 26 Mar 2020 07:34:54 +0000
Subject: [OpenJDK 2D-Dev] RFR [XXS]: JDK-8241491 : Problem list
 jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix
In-Reply-To: <AM0PR02MB57144943BB69B1612087C0328ACE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227EAAFE9D0942ACD9FD34A93F10@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57144943BB69B1612087C0328ACE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB4227874326A2F63E7163775193CF0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Thanks for the review!

From: Langer, Christoph <christoph.langer at sap.com>
Sent: Mittwoch, 25. M?rz 2020 18:27
To: Baesken, Matthias <matthias.baesken at sap.com>; 2d-dev at openjdk.java.net; Phil Race (philip.race at oracle.com) <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: RE: RFR [XXS]: JDK-8241491 : Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix

Hi Matthias,

this looks correct, thanks for doing this. I suggest you push this exclusion directly to jdk/jdk.

Best regards
Christoph


From: 2d-dev <2d-dev-bounces at openjdk.java.net<mailto:2d-dev-bounces at openjdk.java.net>> On Behalf Of Baesken, Matthias
Sent: Dienstag, 24. M?rz 2020 15:40
To: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Phil Race (philip.race at oracle.com<mailto:philip.race at oracle.com>) <philip.race at oracle.com<mailto:philip.race at oracle.com>>
Cc: awt-dev at openjdk.java.net<mailto:awt-dev at openjdk.java.net>
Subject: [CAUTION] [OpenJDK 2D-Dev] RFR [XXS]: JDK-8241491 : Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix

Hello please review this very small fix .

Bug https://bugs.openjdk.java.net/browse/JDK-8241228   states
we need to problem list https://bugs.openjdk.java.net/browse/JDK-8241228 .
This has been done on linux + solaris already with the issue
https://bugs.openjdk.java.net/browse/JDK-8241229
but we miss aix - there we see the problem too.

Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8241491
http://cr.openjdk.java.net/~mbaesken/webrevs/8241491.0/


Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200326/0cb29bd6/attachment-0001.htm>

From Sergey.Bylokhov at oracle.com  Mon Mar 30 13:43:41 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 30 Mar 2020 06:43:41 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8241829 Cleanup the code for PrinterJob on
	windows
Message-ID: <4641c244-051b-cb45-cc29-7cb845b8bc31@oracle.com>

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8241829
Fix: http://cr.openjdk.java.net/~serb/8241829/webrev.00

In PrintServiceLookupProvider.java we always pass NULL to
the notifyFirstPrinterChange as a name of the printer, so
we can remove the code which expects a non-null value.

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Mon Mar 30 14:46:29 2020
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 30 Mar 2020 20:16:29 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8241829 Cleanup the code for PrinterJob
 on windows
In-Reply-To: <4641c244-051b-cb45-cc29-7cb845b8bc31@oracle.com>
References: <4641c244-051b-cb45-cc29-7cb845b8bc31@oracle.com>
Message-ID: <7dae7a3d-a5db-520d-6df6-14cbb3a0f66d@oracle.com>

Hi Sergey,

I guess it is better if you directly pass NULL to OpenPrinter, rather 
than create an unnecessary variable.

Also, I think it will be good if we do a ClosePrinter() if 
FindFirstPrinterChangeNotification() fails.

Regards
Prasanta
On 30-Mar-20 7:13 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241829
> Fix: http://cr.openjdk.java.net/~serb/8241829/webrev.00
>
> In PrintServiceLookupProvider.java we always pass NULL to
> the notifyFirstPrinterChange as a name of the printer, so
> we can remove the code which expects a non-null value.
>

From philip.race at oracle.com  Tue Mar 31 20:37:01 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 31 Mar 2020 13:37:01 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8240342: Custom composite is ignored when
 printing an opaque image to a page
Message-ID: <5E83A9ED.4090809@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8240342
webrev : http://cr.openjdk.java.net/~prr/8240342/

The code that determines if we could print an image via platform APIs
was not checking for custom composites.

The fix is in code used on Linux/Solaris and Windows only.
The Mac printing path is quite different and was not affected.

-phil.

From Sergey.Bylokhov at oracle.com  Tue Mar 31 22:21:45 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 31 Mar 2020 15:21:45 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8241829 Cleanup the code for PrinterJob
 on windows
In-Reply-To: <7dae7a3d-a5db-520d-6df6-14cbb3a0f66d@oracle.com>
References: <4641c244-051b-cb45-cc29-7cb845b8bc31@oracle.com>
 <7dae7a3d-a5db-520d-6df6-14cbb3a0f66d@oracle.com>
Message-ID: <39bb33da-692e-20a6-07b8-7cf628a9a5a9@oracle.com>

Hi, Prasanta.

On 3/30/20 7:46 am, Prasanta Sadhukhan wrote:
> I guess it is better if you directly pass NULL to OpenPrinter, rather than create an unnecessary variable.

That was done only for documentation purposes.

> Also, I think it will be good if we do a ClosePrinter() if FindFirstPrinterChangeNotification() fails.

Nice catch! webrev is updated:
http://cr.openjdk.java.net/~serb/8241829/webrev.01

> 
> Regards
> Prasanta
> On 30-Mar-20 7:13 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241829
>> Fix: http://cr.openjdk.java.net/~serb/8241829/webrev.00
>>
>> In PrintServiceLookupProvider.java we always pass NULL to
>> the notifyFirstPrinterChange as a name of the printer, so
>> we can remove the code which expects a non-null value.
>>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Mar 31 23:57:44 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 31 Mar 2020 16:57:44 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8240342: Custom composite is ignored when
 printing an opaque image to a page
In-Reply-To: <5E83A9ED.4090809@oracle.com>
References: <5E83A9ED.4090809@oracle.com>
Message-ID: <2c1cf718-a7a1-9555-5cbe-417a33f353ba@oracle.com>

Hi, Phil.

Why the "AlphaComposite.SRC_OVER" is counted as "non-compositing" mode?

1904             if (alpha != 1.0
1905                     || (rule != AlphaComposite.SRC
1906                         && rule != AlphaComposite.SRC_OVER))
1907             {
1908                 isCompositing = true;
1909             }

On 3/31/20 1:37 pm, Philip Race wrote:
> The fix is in code used on Linux/Solaris and Windows only.
> The Mac printing path is quite different and was not affected.

I have run the test on macOS 10.15 and it fails by the same reason:
   "Exception in thread "main" java.lang.RuntimeException: Compose called 0times. Expected at least 2"


-- 
Best regards, Sergey.