From sergey.bylokhov at oracle.com  Fri May  5 01:15:25 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 4 May 2017 18:15:25 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8179596 Update java.desktop to be
	HTML-5 friendly
Message-ID: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>

Hello,
Please review the fix for jdk9-dev.
This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.

In the fix the most common issues are fixed.
The issues related to tables will be fixed later, because it is depends from the new html styles which are under review[1].

After the fix the number of errors reported during the build in java.desktop module decreased from 300+ to 110.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
Webrev can be found at: http://cr.openjdk.java.net/~serb/8179596/webrev.00
Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html


From prasanta.sadhukhan at oracle.com  Fri May  5 04:56:09 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 5 May 2017 10:26:09 +0530
Subject: <Swing Dev> [9] JDK-8169897: [PIT]
 javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails
In-Reply-To: <58C95BE8.80305@oracle.com>
References: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com>
 <58C7E405.7090508@oracle.com>
 <62d27dfd-2638-26aa-8cb6-f31d5e133dde@oracle.com>
 <fbfe41a5-f907-1a55-d9b6-65bf918218b0@oracle.com> <58C95BE8.80305@oracle.com>
Message-ID: <72f4632a-8941-dbe7-052d-d1beb80c82d1@oracle.com>

I have updated the fix to calculate "xx" (the x coordinate along which 
background changes willbe calculated from top to bottom of 
bufferedimage) to point to centre of "O"
so that background change can clearly demarcate between O and underline. 
I also have increased the font size a bit to make sure the demarcation 
between O and underline is more prominent
for this automated test to calculate background changes properly.
Tested in windows, linux, mac.
http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.01/

Regards
Prasanta
On 3/15/2017 8:51 PM, Philip Race wrote:
> This test sounds flaky and changing the font is clearly the wrong fix.
>
> -phil.
>
> On 3/14/17, 11:21 PM, Prasanta Sadhukhan wrote:
>>
>>
>> On 3/14/2017 6:48 PM, Alexandr Scherbatiy wrote:
>>> On 3/14/2017 3:37 PM, Philip Race wrote:
>>>> I am not sure why the test went to the trouble of looking for Arial.
>>>> If there was a good reason (Alexander ??) an alternative is to 
>>>> initialise
>>>   The test tries to calculate number of intersection with letter O 
>>> and its underline. It is sensitive to the position of the letter.
>>>
>> If I use "SansSerif", it passes in windows,linux but
>> fails in mac and screenshot of the letter O in mac is different 
>> compared to windows,linux [1]
>> For Serif, the screenshot are same in all platforms.
>>
>> Alex, can you tell me how do you arrive at this hardcoded 
>> intersection number?
>> if (backgroundChangesCount != intersections * 2) {
>>             throw new RuntimeException("String is not properly drawn!");
>>         }
>>
>> [1] screenshot windows: 
>> http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-windows.png
>>       linux: 
>> http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-ubuntu.png
>>       mac: 
>> http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-mac.png
>>
>> Regards
>> Prasanta
>>>   Thanks,
>>>   Alexandr.
>>>> String fontName = "Serif".
>>>>
>>>> although swapping out Arial for Serif is a very odd choice.
>>>> Arial is a Sans Serif font and Serif fonts are not usually used in 
>>>> UIs.
>>>>
>>>> So "SansSerif" would be better
>>>> -phil.
>>>>
>>>> On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a testbug fix where the testcase is failing in linux 
>>>>> because it is not able to find "Arial" font and tries to use the 
>>>>> font found in 0th index of getAvailableFontFamilyNames()
>>>>> which is "Abyssinica SIL".
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169897
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/
>>>>>
>>>>> Modified the testcode to use "Serif" which is present in all 
>>>>> platforms. Tested in windows,linux,mac.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/c7c6a3a0/attachment.html>

From mikhail.cherkasov at oracle.com  Fri May  5 19:19:43 2017
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Fri, 5 May 2017 22:19:43 +0300
Subject: <Swing Dev> [9] Review Request: 8175915: NullPointerException from
 JComboBox and JList when Accessibility enabled
Message-ID: <c2a032e1-ae41-a6a9-12d8-9225253c4932@oracle.com>

Hello,

Could you please review the very simple fix:

Bug: https://bugs.openjdk.java.net/browse/JDK-8175915
Webrev: http://cr.openjdk.java.net/~mcherkas/8175915/webrev/

The problem is that for debug message there's no null check, I added this check.

Thanks,
Mikhail.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/0ce41718/attachment.html>

From rocky.sloan at oracle.com  Fri May  5 19:34:38 2017
From: rocky.sloan at oracle.com (Rocky Sloan)
Date: Fri, 5 May 2017 12:34:38 -0700
Subject: <Swing Dev> [9] Review Request: 8175915: NullPointerException
 from JComboBox and JList when Accessibility enabled
In-Reply-To: <c2a032e1-ae41-a6a9-12d8-9225253c4932@oracle.com>
References: <c2a032e1-ae41-a6a9-12d8-9225253c4932@oracle.com>
Message-ID: <05a4726d-8fd1-9687-01a9-fd3f958554af@oracle.com>

+1


On 5/5/2017 12:19 PM, Mikhail Cherkasov wrote:
> Hello,
>
> Could you please review the very simple fix:
> Bug:https://bugs.openjdk.java.net/browse/JDK-8175915
> Webrev:http://cr.openjdk.java.net/~mcherkas/8175915/webrev/
>
> The problem is that for debug message there's no null check, I added this check.
>
> Thanks,
> Mikhail.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/2b5da1ad/attachment.html>

From sergey.bylokhov at oracle.com  Fri May  5 19:37:17 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 May 2017 12:37:17 -0700 (PDT)
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
Message-ID: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>

Hi, Alexey.
Yes it is possible to add </p> to this changes, but actually </p> tag is not used in JavaSound docs. The last one were removed a few years ago. The <p> tag is used in assumption that it affect the text till the next <p> or till the end of the doc.
So for example in the MidiMessage.java/SizeSequence.java there are a few <p> tags which affects the text till the next <p>, and in this fix just one more <p> was added in the middle.

----- alexey.menkov at oracle.com wrote:

> Overall looks good.
> One minor point - there are several places when you replace <center> 
> with <p> without end </p>.
> Usually absent </p> doesn't cause any problem, but it would be better
> to 
> have end tags for all elements.
> 
> I see this in
> src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
> src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
> src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
> src/java.desktop/share/classes/javax/swing/SizeSequence.java
> 
> --alex
> 
> On 05/04/2017 18:15, Sergey Bylokhov wrote:
> > Hello,
> > Please review the fix for jdk9-dev.
> > This fix is a part of the effort to make all javadoc in jdk9 be
> compatible to HTML5.
> >
> > In the fix the most common issues are fixed.
> > The issues related to tables will be fixed later, because it is
> depends from the new html styles which are under review[1].
> >
> > After the fix the number of errors reported during the build in
> java.desktop module decreased from 300+ to 110.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
> > Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8179596/webrev.00
> > Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
> >
> > [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html
> >


From sergey.bylokhov at oracle.com  Fri May  5 19:54:45 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 May 2017 12:54:45 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8175915: NullPointerException
 from JComboBox and JList when Accessibility enabled
Message-ID: <dfa649d1-0c07-40c1-9c30-fbef1411f079@default>

Hi, Mikhail. 
Do you check why the role is null? I think that in case of JList it should be "AccessibleRole.LIST", no? 

----- mikhail.cherkasov at oracle.com wrote: 
> 
Hello, 
> 
> Could you please review the very simple fix: 
> 
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175915 Webrev: http://cr.openjdk.java.net/~mcherkas/8175915/webrev/ The problem is that for debug message there's no null check, I added this check.

Thanks,
Mikhail. 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/63969f77/attachment.html>

From philip.race at oracle.com  Fri May  5 20:02:16 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 5 May 2017 13:02:16 -0700
Subject: <Swing Dev> [9] Review Request: 8179596 Update java.desktop to
 be HTML-5 friendly
In-Reply-To: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
References: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
Message-ID: <ac772f7e-e131-9811-b67f-f3ebe54b7f15@oracle.com>

This all looks OK to me.

-phil.

On 05/04/2017 06:15 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9-dev.
> This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
>
> In the fix the most common issues are fixed.
> The issues related to tables will be fixed later, because it is depends from the new html styles which are under review[1].
>
> After the fix the number of errors reported during the build in java.desktop module decreased from 300+ to 110.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8179596/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html



From alexandr.scherbatiy at oracle.com  Wed May 10 05:39:11 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 10 May 2017 08:39:11 +0300
Subject: <Swing Dev> [9] JDK-8169897: [PIT]
 javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails
In-Reply-To: <72f4632a-8941-dbe7-052d-d1beb80c82d1@oracle.com>
References: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com>
 <58C7E405.7090508@oracle.com>
 <62d27dfd-2638-26aa-8cb6-f31d5e133dde@oracle.com>
 <fbfe41a5-f907-1a55-d9b6-65bf918218b0@oracle.com> <58C95BE8.80305@oracle.com>
 <72f4632a-8941-dbe7-052d-d1beb80c82d1@oracle.com>
Message-ID: <f2af3bd7-f89d-21c2-1d20-a7bd84368b13@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 5/5/2017 7:56 AM, Prasanta Sadhukhan wrote:
> I have updated the fix to calculate "xx" (the x coordinate along which 
> background changes willbe calculated from top to bottom of 
> bufferedimage) to point to centre of "O"
> so that background change can clearly demarcate between O and 
> underline. I also have increased the font size a bit to make sure the 
> demarcation between O and underline is more prominent
> for this automated test to calculate background changes properly.
> Tested in windows, linux, mac.
> http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.01/
>
> Regards
> Prasanta
> On 3/15/2017 8:51 PM, Philip Race wrote:
>> This test sounds flaky and changing the font is clearly the wrong fix.
>>
>> -phil.
>>
>> On 3/14/17, 11:21 PM, Prasanta Sadhukhan wrote:
>>>
>>>
>>> On 3/14/2017 6:48 PM, Alexandr Scherbatiy wrote:
>>>> On 3/14/2017 3:37 PM, Philip Race wrote:
>>>>> I am not sure why the test went to the trouble of looking for Arial.
>>>>> If there was a good reason (Alexander ??) an alternative is to 
>>>>> initialise
>>>>   The test tries to calculate number of intersection with letter O 
>>>> and its underline. It is sensitive to the position of the letter.
>>>>
>>> If I use "SansSerif", it passes in windows,linux but
>>> fails in mac and screenshot of the letter O in mac is different 
>>> compared to windows,linux [1]
>>> For Serif, the screenshot are same in all platforms.
>>>
>>> Alex, can you tell me how do you arrive at this hardcoded 
>>> intersection number?
>>> if (backgroundChangesCount != intersections * 2) {
>>>             throw new RuntimeException("String is not properly 
>>> drawn!");
>>>         }
>>>
>>> [1] screenshot windows: 
>>> http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-windows.png
>>>       linux: 
>>> http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-ubuntu.png
>>>       mac: 
>>> http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-mac.png
>>>
>>> Regards
>>> Prasanta
>>>>   Thanks,
>>>>   Alexandr.
>>>>> String fontName = "Serif".
>>>>>
>>>>> although swapping out Arial for Serif is a very odd choice.
>>>>> Arial is a Sans Serif font and Serif fonts are not usually used in 
>>>>> UIs.
>>>>>
>>>>> So "SansSerif" would be better
>>>>> -phil.
>>>>>
>>>>> On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a testbug fix where the testcase is failing in 
>>>>>> linux because it is not able to find "Arial" font and tries to 
>>>>>> use the font found in 0th index of getAvailableFontFamilyNames()
>>>>>> which is "Abyssinica SIL".
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169897
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/
>>>>>>
>>>>>> Modified the testcode to use "Serif" which is present in all 
>>>>>> platforms. Tested in windows,linux,mac.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170510/97da86bd/attachment.html>

From ashutosh.pandey at causeway.com  Fri May  5 11:08:16 2017
From: ashutosh.pandey at causeway.com (Ashutosh Pandey)
Date: Fri, 5 May 2017 11:08:16 +0000
Subject: <Swing Dev> Nimbus class extending.
Message-ID: <0c8a3594f2af4e92b2d2fc69d0df825c@causeway.com>

Hello,
            I was wondering if someone can offer an advice on how can I  modify Nimbus L& F classes.
We have used Nimbus L&F in a sizable desktop product. But lately our customers have been reporting class cast exceptions which upon some digging appears to be threading issues.

I am looking to modify some of your classes and will benefit greatly from an example if you have one.

Thank you.

Kind Regards,

Ashutosh Pandey
Senior Principal Engineer

[cid:image001.png at 01D1FA38.4B2FEE40]
Causeway Technologies Limited | Frensham House, Farnham Business Park, Weydon Lane, GU9 8QT
T: +44 (0) 1628 552000

Connect:  Twitter<https://twitter.com/causewaytech>  |  Linkedin<https://www.linkedin.com/company/causeway-technologies>  |  Facebook<https://www.facebook.com/CausewayTech>  |  YouTube<https://www.youtube.com/causeway>  |  www.causeway.com<http://www.causeway.com/>


________________________________

Go green!  - Consider the environment. Please don't print this e-mail unless you really need to....

________________________________


Disclaimer Notice :-

The message and any attachments contained in this e-mail are intended for the named recipient(s) only. It may contain privileged or confidential information or information which is exempt from disclosure under the applicable laws. If you are not the intended recipient(s), you must not read, print, retain, copy distribute, forward or take any or refrain from taking any action in reliance on it or any of its attachments. If you have received or have been forwarded this e-mail in error, please notify us immediately by return e-mail or telephone (+44 (0)1628 552000) and delete this message from the computer or any other data-reading device in its entirety.

Please advise us immediately if you do not or your employer does not consent to Internet e-mail for messages of this nature.

Internet communications cannot be guaranteed to be secure and error-free as the information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender and this Company therefore do not and shall not accept any liability or responsibility of whatsoever nature in the context of this message and its attachment(s) which arises as a result of Internet transmission. Opinions, conclusion, representations, views and such other information in this message that do not relate to the official business of this Company shall be understood as neither given nor endorsed by it.

Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, SL8 5AQ
Registered in England No: 3921897 www.causeway.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/85766352/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3119 bytes
Desc: image001.png
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/85766352/image001.png>

From alexey.menkov at oracle.com  Fri May  5 17:43:58 2017
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 5 May 2017 10:43:58 -0700
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
References: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
Message-ID: <e0795dbe-5529-89be-43fa-ffd0b55156d2@oracle.com>

Overall looks good.
One minor point - there are several places when you replace <center> 
with <p> without end </p>.
Usually absent </p> doesn't cause any problem, but it would be better to 
have end tags for all elements.

I see this in
src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
src/java.desktop/share/classes/javax/swing/SizeSequence.java

--alex

On 05/04/2017 18:15, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9-dev.
> This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
>
> In the fix the most common issues are fixed.
> The issues related to tables will be fixed later, because it is depends from the new html styles which are under review[1].
>
> After the fix the number of errors reported during the build in java.desktop module decreased from 300+ to 110.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8179596/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html
>


From alexey.menkov at oracle.com  Fri May  5 21:21:33 2017
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 5 May 2017 14:21:33 -0700
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
References: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
Message-ID: <33a88ff4-de38-90ff-576e-d073ec360ab7@oracle.com>

Okay,

Then +1 to Phil's approval

--alex

On 05/05/2017 12:37, Sergey Bylokhov wrote:
> Hi, Alexey.
> Yes it is possible to add </p> to this changes, but actually </p> tag is not used in JavaSound docs. The last one were removed a few years ago. The <p> tag is used in assumption that it affect the text till the next <p> or till the end of the doc.
> So for example in the MidiMessage.java/SizeSequence.java there are a few <p> tags which affects the text till the next <p>, and in this fix just one more <p> was added in the middle.
>
> ----- alexey.menkov at oracle.com wrote:
>
>> Overall looks good.
>> One minor point - there are several places when you replace <center>
>> with <p> without end </p>.
>> Usually absent </p> doesn't cause any problem, but it would be better
>> to
>> have end tags for all elements.
>>
>> I see this in
>> src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
>> src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
>> src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
>> src/java.desktop/share/classes/javax/swing/SizeSequence.java
>>
>> --alex
>>
>> On 05/04/2017 18:15, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9-dev.
>>> This fix is a part of the effort to make all javadoc in jdk9 be
>> compatible to HTML5.
>>>
>>> In the fix the most common issues are fixed.
>>> The issues related to tables will be fixed later, because it is
>> depends from the new html styles which are under review[1].
>>>
>>> After the fix the number of errors reported during the build in
>> java.desktop module decreased from 300+ to 110.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
>>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8179596/webrev.00
>>> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>>>
>>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html
>>>


From jonathan.gibbons at oracle.com  Fri May  5 22:22:43 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 05 May 2017 15:22:43 -0700
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
References: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
Message-ID: <590CFB33.7010106@oracle.com>

Sergey,

This is not a comment on the content of the review; it is a minor 
comment on your interpretation of <p>.

<p> is a block-level tag that is implicitly terminated by any of many 
block-level tags. For the full list, see the W3C definition of the p 
element in HTML 5:
https://www.w3.org/TR/html5/grouping-content.html#the-p-element

> Tag omission in text/html 
> <https://www.w3.org/TR/html5/dom.html#element-dfn-tag-omission>:
>
>     A |p
>     <https://www.w3.org/TR/html5/grouping-content.html#the-p-element>|
>     element's end tag
>     <https://www.w3.org/TR/html5/syntax.html#syntax-end-tag> may be
>     omitted if the |p
>     <https://www.w3.org/TR/html5/grouping-content.html#the-p-element>|
>     element is immediately followed by an |address
>     <https://www.w3.org/TR/html5/sections.html#the-address-element>|,
>     |article
>     <https://www.w3.org/TR/html5/sections.html#the-article-element>|,
>     |aside
>     <https://www.w3.org/TR/html5/sections.html#the-aside-element>|,
>     |blockquote
>     <https://www.w3.org/TR/html5/grouping-content.html#the-blockquote-element>|,
>     |div
>     <https://www.w3.org/TR/html5/grouping-content.html#the-div-element>|,
>     |dl
>     <https://www.w3.org/TR/html5/grouping-content.html#the-dl-element>|,
>     |fieldset
>     <https://www.w3.org/TR/html5/forms.html#the-fieldset-element>|,
>     |footer
>     <https://www.w3.org/TR/html5/sections.html#the-footer-element>|,
>     |form <https://www.w3.org/TR/html5/forms.html#the-form-element>|,
>     |h1
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h2
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h3
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h4
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h5
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h6
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |header
>     <https://www.w3.org/TR/html5/sections.html#the-header-element>|,
>     |hgroup <https://www.w3.org/TR/html5/obsolete.html#hgroup>|, |hr
>     <https://www.w3.org/TR/html5/grouping-content.html#the-hr-element>|,
>     |main
>     <https://www.w3.org/TR/html5/grouping-content.html#the-main-element>|,
>     |nav <https://www.w3.org/TR/html5/sections.html#the-nav-element>|,
>     |ol
>     <https://www.w3.org/TR/html5/grouping-content.html#the-ol-element>|,
>     |p
>     <https://www.w3.org/TR/html5/grouping-content.html#the-p-element>|, |pre
>     <https://www.w3.org/TR/html5/grouping-content.html#the-pre-element>|,
>     |section
>     <https://www.w3.org/TR/html5/sections.html#the-section-element>|,
>     |table
>     <https://www.w3.org/TR/html5/tabular-data.html#the-table-element>|, or
>     |ul
>     <https://www.w3.org/TR/html5/grouping-content.html#the-ul-element>|,
>     element, or if there is no more content in the parent element and
>     the parent element is not an |a
>     <https://www.w3.org/TR/html5/text-level-semantics.html#the-a-element>|
>     element.
>


-- Jon

On 05/05/2017 12:37 PM, Sergey Bylokhov wrote:
> Hi, Alexey.
> Yes it is possible to add </p> to this changes, but actually </p> tag is not used in JavaSound docs. The last one were removed a few years ago. The <p> tag is used in assumption that it affect the text till the next <p> or till the end of the doc.
> So for example in the MidiMessage.java/SizeSequence.java there are a few <p> tags which affects the text till the next <p>, and in this fix just one more <p> was added in the middle.
>
> ----- alexey.menkov at oracle.com wrote:
>
>> Overall looks good.
>> One minor point - there are several places when you replace <center>
>> with <p> without end </p>.
>> Usually absent </p> doesn't cause any problem, but it would be better
>> to
>> have end tags for all elements.
>>
>> I see this in
>> src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
>> src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
>> src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
>> src/java.desktop/share/classes/javax/swing/SizeSequence.java
>>
>> --alex
>>
>> On 05/04/2017 18:15, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9-dev.
>>> This fix is a part of the effort to make all javadoc in jdk9 be
>> compatible to HTML5.
>>> In the fix the most common issues are fixed.
>>> The issues related to tables will be fixed later, because it is
>> depends from the new html styles which are under review[1].
>>> After the fix the number of errors reported during the build in
>> java.desktop module decreased from 300+ to 110.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
>>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8179596/webrev.00
>>> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>>>
>>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170505/615d5fde/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed May 10 05:48:50 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 10 May 2017 08:48:50 +0300
Subject: <Swing Dev> Nimbus class extending.
In-Reply-To: <0c8a3594f2af4e92b2d2fc69d0df825c@causeway.com>
References: <0c8a3594f2af4e92b2d2fc69d0df825c@causeway.com>
Message-ID: <5818196e-3f32-624a-f026-5bd73d07d597@oracle.com>

On 5/5/2017 2:08 PM, Ashutosh Pandey wrote:
>
> Hello,
>
> I was wondering if someone can offer an advice on how can I modify 
> Nimbus L& F classes.
>
> We have used Nimbus L&F in a sizable desktop product. But lately our 
> customers have been reporting class cast exceptions which upon some 
> digging appears to be threading issues.
>

   Could you provide the code snippet that reproduces the exception?

   You can also file an issue on  http://bugreport.java.com/bugreport

   Thanks,
   Alexandr.
>
> I am looking to modify some of your classes and will benefit greatly 
> from an example if you have one.
>
> Thank you.
>
> Kind Regards,
>
> Ashutosh Pandey
>
> Senior Principal Engineer
>
> cid:image001.png at 01D1FA38.4B2FEE40
> Causeway Technologies Limited | Frensham House, Farnham Business Park, 
> Weydon Lane, GU9 8QT
> T: +44 (0) 1628 552000
>
>
> Connect: Twitter <https://twitter.com/causewaytech>  | Linkedin 
> <https://www.linkedin.com/company/causeway-technologies> | Facebook 
> <https://www.facebook.com/CausewayTech>  | YouTube 
> <https://www.youtube.com/causeway> | www.causeway.com 
> <http://www.causeway.com/>
>
>
> ------------------------------------------------------------------------
>
> Go green!  - Consider the environment. Please don't print this e-mail 
> unless you really need to....
>
> ------------------------------------------------------------------------
>
>
> Disclaimer Notice :-
>
> The message and any attachments contained in this e-mail are intended 
> for the named recipient(s) only. It may contain privileged or 
> confidential information or information which is exempt from 
> disclosure under the applicable laws. If you are not the intended 
> recipient(s), you must not read, print, retain, copy distribute, 
> forward or take any or refrain from taking any action in reliance on 
> it or any of its attachments. If you have received or have been 
> forwarded this e-mail in error, please notify us immediately by return 
> e-mail or telephone (+44 (0)1628 552000) and delete this message from 
> the computer or any other data-reading device in its entirety.
>
> Please advise us immediately if you do not or your employer does not 
> consent to Internet e-mail for messages of this nature.
>
> Internet communications cannot be guaranteed to be secure and 
> error-free as the information could be intercepted, corrupted, lost, 
> arrive late or contain viruses. The sender and this Company therefore 
> do not and shall not accept any liability or responsibility of 
> whatsoever nature in the context of this message and its attachment(s) 
> which arises as a result of Internet transmission. Opinions, 
> conclusion, representations, views and such other information in this 
> message that do not relate to the official business of this Company 
> shall be understood as neither given nor endorsed by it.
>
> Registered Office: Comino House, Furlong Road, Bourne End, 
> Buckinghamshire, SL8 5AQ
> Registered in England No: 3921897 www.causeway.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170510/76826a0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3119 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170510/76826a0c/attachment.png>

From mikhail.cherkasov at oracle.com  Thu May 11 17:54:36 2017
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Thu, 11 May 2017 20:54:36 +0300
Subject: <Swing Dev> [9] Review Request: 8175915: NullPointerException
 from JComboBox and JList when Accessibility enabled
In-Reply-To: <dfa649d1-0c07-40c1-9c30-fbef1411f079@default>
References: <dfa649d1-0c07-40c1-9c30-fbef1411f079@default>
Message-ID: <8c84ec58-4ab1-9df5-bcf3-dc3e0cac0cde@oracle.com>

Hi Sergey,

it's the same problem as in https://bugs.openjdk.java.net/browse/JDK-8076249

AccessBridge trys to request information from obsoleted 
ActionableAccessibleJListChild, as result getCurrentAccessibleContext 
return null,
and ActionableAccessibleJListChild return null for Role.

Thanks,
Mikhail.

On 05.05.2017 22:54, Sergey Bylokhov wrote:
> Hi, Mikhail.
> Do you check why the role is null? I think that in case of JList it 
> should be "AccessibleRole.LIST", no?
>
> ----- mikhail.cherkasov at oracle.com wrote:
> >
> Hello,
> >
> > Could you please review the very simple fix:
> >
> >
> >
> >
> Bug:https://bugs.openjdk.java.net/browse/JDK-8175915
> Webrev:http://cr.openjdk.java.net/~mcherkas/8175915/webrev/
>
> The problem is that for debug message there's no null check, I added this check.
>
> Thanks,
> Mikhail.
>
> >
> >
>
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170511/64fc7fd1/attachment.html>

From sergey.bylokhov at oracle.com  Thu May 11 19:31:18 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 11 May 2017 12:31:18 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8175915: NullPointerException
 from JComboBox and JList when Accessibility enabled
Message-ID: <e21296ae-5b13-4fdb-8cea-2b91ac266bc7@default>

Thanks, Looks fine. 

----- mikhail.cherkasov at oracle.com wrote: 
> 
Hi Sergey, 
> 
> it's the same problem as in https://bugs.openjdk.java.net/browse/JDK-8076249 
> 
> AccessBridge trys to request information from obsoleted ActionableAccessibleJListChild, as result getCurrentAccessibleContext return null, 
> and ActionableAccessibleJListChild return null for Role. 
> 
> Thanks, 
> Mikhail. 
> 
> 
> On 05.05.2017 22:54, Sergey Bylokhov wrote: 
> 


> Hi, Mikhail. 
Do you check why the role is null? I think that in case of JList it should be "AccessibleRole.LIST", no? 

> ----- mikhail.cherkasov at oracle.com wrote: 
> > 
Hello, 
> > 
> > Could you please review the very simple fix: 
> > 
> > 
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8175915 Webrev: http://cr.openjdk.java.net/~mcherkas/8175915/webrev/ The problem is that for debug message there's no null check, I added this check.

Thanks,
Mikhail. 
> > 
> > 
> > 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170511/2fb18242/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri May 12 07:51:49 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 12 May 2017 13:21:49 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
Message-ID: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>

Hi All,

Please review a spec violation issue whereby if in 
JOptionPane.showInternalConfirmDialog(Component parentComponent, Object 
message)
"parentComponent" is null, we are getting RuntimeException 
"parentComponent does not have a valid parent"

but as per spec, 
https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
it says "|parentComponent| - determines the |Frame| in which the dialog 
is displayed; if |null|, or if the |parentComponent| has no |Frame|, a 
default |Frame| is used"

This violation exists for all overridden showInternalConfirmDialog 
methods and showInternalOptionDialog.

The proposed fix creates a default JFrame and shows the confirm dialog 
in it, as stated in the spec.

Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170512/c003d7cf/attachment.html>

From semyon.sadetsky at oracle.com  Fri May 12 14:32:54 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 12 May 2017 07:32:54 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
Message-ID: <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>

The fix covers the parentComponent=null case.

What about the second case when non-null component is provided but it 
has no frame?

--Semyon


On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>
> Hi All,
>
> Please review a spec violation issue whereby if in 
> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
> Object message)
> "parentComponent" is null, we are getting RuntimeException 
> "parentComponent does not have a valid parent"
>
> but as per spec, 
> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
> it says "|parentComponent| - determines the |Frame| in which the 
> dialog is displayed; if |null|, or if the |parentComponent| has no 
> |Frame|, a default |Frame| is used"
>
> This violation exists for all overridden showInternalConfirmDialog 
> methods and showInternalOptionDialog.
>
> The proposed fix creates a default JFrame and shows the confirm dialog 
> in it, as stated in the spec.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>
> Regards
> Prasanta 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170512/222d249e/attachment.html>

From semyon.sadetsky at oracle.com  Fri May 12 14:38:27 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 12 May 2017 07:38:27 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
Message-ID: <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>

Also the spec says to use the default frame but the fix creates new 
frame each time.


On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>
> The fix covers the parentComponent=null case.
>
> What about the second case when non-null component is provided but it 
> has no frame?
>
> --Semyon
>
>
> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>
>> Hi All,
>>
>> Please review a spec violation issue whereby if in 
>> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
>> Object message)
>> "parentComponent" is null, we are getting RuntimeException 
>> "parentComponent does not have a valid parent"
>>
>> but as per spec, 
>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>> it says "|parentComponent| - determines the |Frame| in which the 
>> dialog is displayed; if |null|, or if the |parentComponent| has no 
>> |Frame|, a default |Frame| is used"
>>
>> This violation exists for all overridden showInternalConfirmDialog 
>> methods and showInternalOptionDialog.
>>
>> The proposed fix creates a default JFrame and shows the confirm 
>> dialog in it, as stated in the spec.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>
>> Regards
>> Prasanta 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170512/ab76767c/attachment.html>

From philip.race at oracle.com  Fri May 12 15:46:48 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 12 May 2017 08:46:48 -0700
Subject: <Swing Dev> [9] Review Request: 8175915: NullPointerException
 from JComboBox and JList when Accessibility enabled
In-Reply-To: <e21296ae-5b13-4fdb-8cea-2b91ac266bc7@default>
References: <e21296ae-5b13-4fdb-8cea-2b91ac266bc7@default>
Message-ID: <39bd7647-417b-b1f4-90c5-6a5d351a12b9@oracle.com>

+1

-phil.

On 05/11/2017 12:31 PM, Sergey Bylokhov wrote:
> Thanks, Looks fine.
>
> ----- mikhail.cherkasov at oracle.com wrote:
> >
> Hi Sergey,
> >
> > it's the same problem as in 
> https://bugs.openjdk.java.net/browse/JDK-8076249
> >
> > AccessBridge trys to request information from obsoleted 
> ActionableAccessibleJListChild, as result getCurrentAccessibleContext 
> return null,
> > and ActionableAccessibleJListChild return null for Role.
> >
> > Thanks,
> > Mikhail.
> >
> >
> > On 05.05.2017 22:54, Sergey Bylokhov wrote:
> >
>
>     > Hi, Mikhail.
>     Do you check why the role is null? I think that in case of JList
>     it should be "AccessibleRole.LIST", no?
>
>     > ----- mikhail.cherkasov at oracle.com wrote:
>     > >
>     Hello,
>     > >
>     > > Could you please review the very simple fix:
>     > >
>     > >
>     > >
>     > >
>
>     Bug:https://bugs.openjdk.java.net/browse/JDK-8175915
>     Webrev:http://cr.openjdk.java.net/~mcherkas/8175915/webrev/
>
>     The problem is that for debug message there's no null check, I added this check.
>
>     Thanks,
>     Mikhail.
>
>
>     > >
>     > >
>
>     > >
>
>
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170512/99022abd/attachment.html>

From sergey.bylokhov at oracle.com  Fri May 12 23:25:08 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 12 May 2017 16:25:08 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
Message-ID: <d542b7bf-08e9-44ea-befb-329956eab69a@default>

Hello,
Please review the fix for jdk9-dev.

This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
It covers all errors which are reported by the javadoc tool during the build of jdk for java.desktop module.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.01

Note that an appearance of some tables were changed after the fix:

Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
After: http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html

Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
After : http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html

Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
After: http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From philip.race at oracle.com  Fri May 12 23:36:39 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 16:36:39 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <d542b7bf-08e9-44ea-befb-329956eab69a@default>
References: <d542b7bf-08e9-44ea-befb-329956eab69a@default>
Message-ID: <59164707.7040605@oracle.com>

Adding 2d-dev because a number of the files are 2D.

What is the general reason for changing the appearance of the tables?

-phil.

On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9-dev.
>
> This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
> It covers all errors which are reported by the javadoc tool during the build of jdk for java.desktop module.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.01
>
> Note that an appearance of some tables were changed after the fix:
>
> Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> After: http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>
> Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> After : http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>
> Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> After: http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From sergey.bylokhov at oracle.com  Fri May 12 23:52:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 12 May 2017 16:52:06 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
Message-ID: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>

This is because I use the same style for most of the tables 'class="striped"', which apply the same/unified style for all(most) of our tables.
Also this is because I removed 'inlined' styles, like here:
http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html

----- philip.race at oracle.com wrote:

> Adding 2d-dev because a number of the files are 2D.
> 
> What is the general reason for changing the appearance of the tables?
> 
> -phil.
> 
> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> > Hello,
> > Please review the fix for jdk9-dev.
> >
> > This fix is a part of the effort to make all javadoc in jdk9 be
> compatible to HTML5.
> > It covers all errors which are reported by the javadoc tool during
> the build of jdk for java.desktop module.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> > Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> >
> > Note that an appearance of some tables were changed after the fix:
> >
> > Before:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> > After:
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> >
> > Before:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> > After :
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> >
> > Before:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> > After:
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From philip.race at oracle.com  Fri May 12 23:54:09 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 16:54:09 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
Message-ID: <59164B21.3050803@oracle.com>

Does this in any way match the rest of the docs ? Or is everyone left to 
style things how they want.
I thought (?) maybe there is to be some javadoc tool support for CSS styles.

Also why are all the table summaries removed ?

-phil.

On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> This is because I use the same style for most of the tables 'class="striped"', which apply the same/unified style for all(most) of our tables.
> Also this is because I removed 'inlined' styles, like here:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>
> ----- philip.race at oracle.com wrote:
>
>> Adding 2d-dev because a number of the files are 2D.
>>
>> What is the general reason for changing the appearance of the tables?
>>
>> -phil.
>>
>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9-dev.
>>>
>>> This fix is a part of the effort to make all javadoc in jdk9 be
>> compatible to HTML5.
>>> It covers all errors which are reported by the javadoc tool during
>> the build of jdk for java.desktop module.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>> Note that an appearance of some tables were changed after the fix:
>>>
>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>>> After :
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From jonathan.gibbons at oracle.com  Fri May 12 23:58:55 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 16:58:55 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <59164B21.3050803@oracle.com>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
 <59164B21.3050803@oracle.com>
Message-ID: <59164C3F.8070606@oracle.com>

Phil,

1. javadoc now provides support for 3 named styles in the default 
stylesheet:
         borderless:  no borders
         plain:  simple 1px borders around tables and cells
         striped: reduced borders; rows have alternating white and light 
grey backgrounds


2. summary attributes are not legal in HTML 5.
     For accessibility reasons, you should consider having a table 
caption instead.

-- Jon


On 05/12/2017 04:54 PM, Philip Race wrote:
> Does this in any way match the rest of the docs ? Or is everyone left 
> to style things how they want.
> I thought (?) maybe there is to be some javadoc tool support for CSS 
> styles.
>
> Also why are all the table summaries removed ?
>
> -phil.
>
> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>> This is because I use the same style for most of the tables 
>> 'class="striped"', which apply the same/unified style for all(most) 
>> of our tables.
>> Also this is because I removed 'inlined' styles, like here:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>
>>
>> ----- philip.race at oracle.com wrote:
>>
>>> Adding 2d-dev because a number of the files are 2D.
>>>
>>> What is the general reason for changing the appearance of the tables?
>>>
>>> -phil.
>>>
>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk9-dev.
>>>>
>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>> compatible to HTML5.
>>>> It covers all errors which are reported by the javadoc tool during
>>> the build of jdk for java.desktop module.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>> Note that an appearance of some tables were changed after the fix:
>>>>
>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>
>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>> After :
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>
>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>



From sergey.bylokhov at oracle.com  Sat May 13 00:00:30 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 12 May 2017 17:00:30 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
Message-ID: <cc06639b-5267-4b26-a487-e05aaf40879c@default>

The "summary" is unsupported by the HTML5 and we replace it by invisible caption.
These new styles are located in the stylesheet.css in the root of the JavaDoc api folder, so I assume these styles should be used by others as well.
They were added by this fix:
https://bugs.openjdk.java.net/browse/JDK-8179479

----- philip.race at oracle.com wrote:

> Does this in any way match the rest of the docs ? Or is everyone left
> to 
> style things how they want.
> I thought (?) maybe there is to be some javadoc tool support for CSS
> styles.
> 
> Also why are all the table summaries removed ?
> 
> -phil.
> 
> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> > This is because I use the same style for most of the tables
> 'class="striped"', which apply the same/unified style for all(most) of
> our tables.
> > Also this is because I removed 'inlined' styles, like here:
> >
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> >
> > ----- philip.race at oracle.com wrote:
> >
> >> Adding 2d-dev because a number of the files are 2D.
> >>
> >> What is the general reason for changing the appearance of the
> tables?
> >>
> >> -phil.
> >>
> >> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> >>> Hello,
> >>> Please review the fix for jdk9-dev.
> >>>
> >>> This fix is a part of the effort to make all javadoc in jdk9 be
> >> compatible to HTML5.
> >>> It covers all errors which are reported by the javadoc tool
> during
> >> the build of jdk for java.desktop module.
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> >>> Webrev can be found at:
> >> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> >>> Note that an appearance of some tables were changed after the
> fix:
> >>>
> >>> Before:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> >>> After:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> >>> Before:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> >>> After :
> >>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> >>> Before:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> >>> After:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From philip.race at oracle.com  Sat May 13 00:03:38 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 17:03:38 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <59164C3F.8070606@oracle.com>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
 <59164B21.3050803@oracle.com> <59164C3F.8070606@oracle.com>
Message-ID: <59164D5A.60200@oracle.com>



On 5/12/17, 4:58 PM, Jonathan Gibbons wrote:
> Phil,
>
> 1. javadoc now provides support for 3 named styles in the default 
> stylesheet:
>         borderless:  no borders
>         plain:  simple 1px borders around tables and cells
>         striped: reduced borders; rows have alternating white and 
> light grey backgrounds
>
OK .. I see these being used.
>
> 2. summary attributes are not legal in HTML 5.
>     For accessibility reasons, you should consider having a table 
> caption instead.

OK. I saw these but I wasn't clear it was a direct replacement. HTML 5 
sometimes
seems to be different just to be different ..

-phil.
>
> -- Jon
>
>
> On 05/12/2017 04:54 PM, Philip Race wrote:
>> Does this in any way match the rest of the docs ? Or is everyone left 
>> to style things how they want.
>> I thought (?) maybe there is to be some javadoc tool support for CSS 
>> styles.
>>
>> Also why are all the table summaries removed ?
>>
>> -phil.
>>
>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>> This is because I use the same style for most of the tables 
>>> 'class="striped"', which apply the same/unified style for all(most) 
>>> of our tables.
>>> Also this is because I removed 'inlined' styles, like here:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Adding 2d-dev because a number of the files are 2D.
>>>>
>>>> What is the general reason for changing the appearance of the tables?
>>>>
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk9-dev.
>>>>>
>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>> compatible to HTML5.
>>>>> It covers all errors which are reported by the javadoc tool during
>>>> the build of jdk for java.desktop module.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>> Note that an appearance of some tables were changed after the fix:
>>>>>
>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>> After :
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>
>


From jonathan.gibbons at oracle.com  Sat May 13 00:07:20 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 17:07:20 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <59164D5A.60200@oracle.com>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
 <59164B21.3050803@oracle.com> <59164C3F.8070606@oracle.com>
 <59164D5A.60200@oracle.com>
Message-ID: <59164E38.5090809@oracle.com>



On 05/12/2017 05:03 PM, Philip Race wrote:
>
>
> On 5/12/17, 4:58 PM, Jonathan Gibbons wrote:
>> Phil,
>>
>> 1. javadoc now provides support for 3 named styles in the default 
>> stylesheet:
>>         borderless:  no borders
>>         plain:  simple 1px borders around tables and cells
>>         striped: reduced borders; rows have alternating white and 
>> light grey backgrounds
>>
> OK .. I see these being used.
>>
>> 2. summary attributes are not legal in HTML 5.
>>     For accessibility reasons, you should consider having a table 
>> caption instead.
>
> OK. I saw these but I wasn't clear it was a direct replacement. HTML 5 
> sometimes
> seems to be different just to be different ..

It's not a direct replacement. The summary attribute was used to give a 
more descriptive value
of the contents of the table.   A caption is more like a title. But the 
ARIA guidelines essentially
say, use one or the other, unless you want to dig deeper into aria 
attributes (not recommended.)

>
> -phil.
>>
>> -- Jon
>>
>>
>> On 05/12/2017 04:54 PM, Philip Race wrote:
>>> Does this in any way match the rest of the docs ? Or is everyone 
>>> left to style things how they want.
>>> I thought (?) maybe there is to be some javadoc tool support for CSS 
>>> styles.
>>>
>>> Also why are all the table summaries removed ?
>>>
>>> -phil.
>>>
>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>> This is because I use the same style for most of the tables 
>>>> 'class="striped"', which apply the same/unified style for all(most) 
>>>> of our tables.
>>>> Also this is because I removed 'inlined' styles, like here:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>
>>>> ----- philip.race at oracle.com wrote:
>>>>
>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>
>>>>> What is the general reason for changing the appearance of the tables?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk9-dev.
>>>>>>
>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>> compatible to HTML5.
>>>>>> It covers all errors which are reported by the javadoc tool during
>>>>> the build of jdk for java.desktop module.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>> Note that an appearance of some tables were changed after the fix:
>>>>>>
>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>> After :
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>



From jonathan.gibbons at oracle.com  Sat May 13 00:11:21 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 17:11:21 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
Message-ID: <59164F29.8070300@oracle.com>

Sergey,

FWIW, the invisible caption should be regarded as a temporary solution, 
until content authors can review/update the text of the caption and make 
it visible.

The general guideline in this conversion work has been to avoid changing 
the visible text of the specification, and captions fall into a grey 
area of whether the text is significant/normative or not.  Hence the 
temporary step to make them not displayed for now.

-- Jon

On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
> The "summary" is unsupported by the HTML5 and we replace it by invisible caption.
> These new styles are located in the stylesheet.css in the root of the JavaDoc api folder, so I assume these styles should be used by others as well.
> They were added by this fix:
> https://bugs.openjdk.java.net/browse/JDK-8179479
>
> ----- philip.race at oracle.com wrote:
>
>> Does this in any way match the rest of the docs ? Or is everyone left
>> to
>> style things how they want.
>> I thought (?) maybe there is to be some javadoc tool support for CSS
>> styles.
>>
>> Also why are all the table summaries removed ?
>>
>> -phil.
>>
>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>> This is because I use the same style for most of the tables
>> 'class="striped"', which apply the same/unified style for all(most) of
>> our tables.
>>> Also this is because I removed 'inlined' styles, like here:
>>>
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Adding 2d-dev because a number of the files are 2D.
>>>>
>>>> What is the general reason for changing the appearance of the
>> tables?
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk9-dev.
>>>>>
>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>> compatible to HTML5.
>>>>> It covers all errors which are reported by the javadoc tool
>> during
>>>> the build of jdk for java.desktop module.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>> Note that an appearance of some tables were changed after the
>> fix:
>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>>>>> After :
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html



From semyon.sadetsky at oracle.com  Mon May 15 17:34:59 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 15 May 2017 10:34:59 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
Message-ID: <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>

I don't see how this change fixes the issue.

I still got

Exception in thread "main" java.lang.RuntimeException: JOptionPane: 
parentComponent does not have a valid parent

after applying it.

--Semyon


On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>
> Updated webrev to use getRootFrame() via createDialog() to get the 
> default Frame when a frame is not provided.
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>
> Regards
> Prasanta
> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>
>> Also the spec says to use the default frame but the fix creates new 
>> frame each time.
>>
>>
>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>
>>> The fix covers the parentComponent=null case.
>>>
>>> What about the second case when non-null component is provided but 
>>> it has no frame?
>>>
>>> --Semyon
>>>
>>>
>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Please review a spec violation issue whereby if in 
>>>> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
>>>> Object message)
>>>> "parentComponent" is null, we are getting RuntimeException 
>>>> "parentComponent does not have a valid parent"
>>>>
>>>> but as per spec, 
>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>> it says "|parentComponent| - determines the |Frame| in which the 
>>>> dialog is displayed; if |null|, or if the |parentComponent| has no 
>>>> |Frame|, a default |Frame| is used"
>>>>
>>>> This violation exists for all overridden showInternalConfirmDialog 
>>>> methods and showInternalOptionDialog.
>>>>
>>>> The proposed fix creates a default JFrame and shows the confirm 
>>>> dialog in it, as stated in the spec.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta 
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170515/9ff1601a/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon May 15 10:14:17 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 15 May 2017 15:44:17 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
Message-ID: <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>

Updated webrev to use getRootFrame() via createDialog() to get the 
default Frame when a frame is not provided.

http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/

Regards
Prasanta
On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>
> Also the spec says to use the default frame but the fix creates new 
> frame each time.
>
>
> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>
>> The fix covers the parentComponent=null case.
>>
>> What about the second case when non-null component is provided but it 
>> has no frame?
>>
>> --Semyon
>>
>>
>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>
>>> Hi All,
>>>
>>> Please review a spec violation issue whereby if in 
>>> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
>>> Object message)
>>> "parentComponent" is null, we are getting RuntimeException 
>>> "parentComponent does not have a valid parent"
>>>
>>> but as per spec, 
>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>> it says "|parentComponent| - determines the |Frame| in which the 
>>> dialog is displayed; if |null|, or if the |parentComponent| has no 
>>> |Frame|, a default |Frame| is used"
>>>
>>> This violation exists for all overridden showInternalConfirmDialog 
>>> methods and showInternalOptionDialog.
>>>
>>> The proposed fix creates a default JFrame and shows the confirm 
>>> dialog in it, as stated in the spec.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>
>>> Regards
>>> Prasanta 
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170515/179bc4e3/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue May 16 05:44:34 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 16 May 2017 11:14:34 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
Message-ID: <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>

Not sure which testcase you are running. I do not see this exception 
when I run my testcase in the webrev.

I am using createDialog in the fix for null parentComponent and not 
createInternalFrame() which throws this exception.

Regards
Prasanta
On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>
> I don't see how this change fixes the issue.
>
> I still got
>
> Exception in thread "main" java.lang.RuntimeException: JOptionPane: 
> parentComponent does not have a valid parent
>
> after applying it.
>
> --Semyon
>
>
> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>
>> Updated webrev to use getRootFrame() via createDialog() to get the 
>> default Frame when a frame is not provided.
>>
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>
>> Regards
>> Prasanta
>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>
>>> Also the spec says to use the default frame but the fix creates new 
>>> frame each time.
>>>
>>>
>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>
>>>> The fix covers the parentComponent=null case.
>>>>
>>>> What about the second case when non-null component is provided but 
>>>> it has no frame?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Please review a spec violation issue whereby if in 
>>>>> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
>>>>> Object message)
>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>> "parentComponent does not have a valid parent"
>>>>>
>>>>> but as per spec, 
>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>> it says "|parentComponent| - determines the |Frame| in which the 
>>>>> dialog is displayed; if |null|, or if the |parentComponent| has no 
>>>>> |Frame|, a default |Frame| is used"
>>>>>
>>>>> This violation exists for all overridden showInternalConfirmDialog 
>>>>> methods and showInternalOptionDialog.
>>>>>
>>>>> The proposed fix creates a default JFrame and shows the confirm 
>>>>> dialog in it, as stated in the spec.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta 
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170516/3216b7ec/attachment.html>

From semyon.sadetsky at oracle.com  Tue May 16 15:17:35 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 16 May 2017 08:17:35 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
Message-ID: <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>

Yes, sorry. I meant the case I've mentioned in my first comment : when 
the component has no frame.

parentComponent determines the <code>Frame</code> * in which the dialog 
is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used


--Semyon

On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>
> Not sure which testcase you are running. I do not see this exception 
> when I run my testcase in the webrev.
>
> I am using createDialog in the fix for null parentComponent and not 
> createInternalFrame() which throws this exception.
>
> Regards
> Prasanta
> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>
>> I don't see how this change fixes the issue.
>>
>> I still got
>>
>> Exception in thread "main" java.lang.RuntimeException: JOptionPane: 
>> parentComponent does not have a valid parent
>>
>> after applying it.
>>
>> --Semyon
>>
>>
>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>
>>> Updated webrev to use getRootFrame() via createDialog() to get the 
>>> default Frame when a frame is not provided.
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>
>>> Regards
>>> Prasanta
>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>
>>>> Also the spec says to use the default frame but the fix creates new 
>>>> frame each time.
>>>>
>>>>
>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>
>>>>> The fix covers the parentComponent=null case.
>>>>>
>>>>> What about the second case when non-null component is provided but 
>>>>> it has no frame?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a spec violation issue whereby if in 
>>>>>> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
>>>>>> Object message)
>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>> "parentComponent does not have a valid parent"
>>>>>>
>>>>>> but as per spec, 
>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>> it says "|parentComponent| - determines the |Frame| in which the 
>>>>>> dialog is displayed; if |null|, or if the |parentComponent| has 
>>>>>> no |Frame|, a default |Frame| is used"
>>>>>>
>>>>>> This violation exists for all overridden 
>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>
>>>>>> The proposed fix creates a default JFrame and shows the confirm 
>>>>>> dialog in it, as stated in the spec.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta 
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170516/61034402/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed May 17 07:55:53 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 17 May 2017 13:25:53 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
Message-ID: <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>

Ok, sorry. Updated code to get the default Frame when component has no 
Frame and
testcase to test that case too.
Updated webrev
http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/

Regards
Prasanta
On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>
> Yes, sorry. I meant the case I've mentioned in my first comment : when 
> the component has no frame.
>
> parentComponent determines the <code>Frame</code> * in which the 
> dialog is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used
>
> --Semyon
>
> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>
>> Not sure which testcase you are running. I do not see this exception 
>> when I run my testcase in the webrev.
>>
>> I am using createDialog in the fix for null parentComponent and not 
>> createInternalFrame() which throws this exception.
>>
>> Regards
>> Prasanta
>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>>
>>> I don't see how this change fixes the issue.
>>>
>>> I still got
>>>
>>> Exception in thread "main" java.lang.RuntimeException: JOptionPane: 
>>> parentComponent does not have a valid parent
>>>
>>> after applying it.
>>>
>>> --Semyon
>>>
>>>
>>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>>
>>>> Updated webrev to use getRootFrame() via createDialog() to get the 
>>>> default Frame when a frame is not provided.
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>>
>>>>> Also the spec says to use the default frame but the fix creates 
>>>>> new frame each time.
>>>>>
>>>>>
>>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>>
>>>>>> The fix covers the parentComponent=null case.
>>>>>>
>>>>>> What about the second case when non-null component is provided 
>>>>>> but it has no frame?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a spec violation issue whereby if in 
>>>>>>> JOptionPane.showInternalConfirmDialog(Component parentComponent, 
>>>>>>> Object message)
>>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>>> "parentComponent does not have a valid parent"
>>>>>>>
>>>>>>> but as per spec, 
>>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>>> it says "|parentComponent| - determines the |Frame| in which the 
>>>>>>> dialog is displayed; if |null|, or if the |parentComponent| has 
>>>>>>> no |Frame|, a default |Frame| is used"
>>>>>>>
>>>>>>> This violation exists for all overridden 
>>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>>
>>>>>>> The proposed fix creates a default JFrame and shows the confirm 
>>>>>>> dialog in it, as stated in the spec.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta 
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170517/74219722/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed May 17 10:31:32 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 17 May 2017 16:01:32 +0530
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
Message-ID: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>

Hi All,

Please review a fix for an issue whereby it is seen that 
WindowsLookAndFeel classes are built for non-windows platform,
where it is not needed.
Proposed fix is to remove building these classes for non-windows platform.

JPRT build is successful. Also, fixed the regression tests which expects 
this classes to be available in non-unix platform.

Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/

There are some closed regression test which will be taken care after 
this in a separate crucible review.

Regards
Prasanta


From magnus.ihse.bursie at oracle.com  Wed May 17 10:46:52 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 12:46:52 +0200
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
In-Reply-To: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
Message-ID: <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>

Build changes looks good. However in 
src/java.desktop/share/classes/module-info.java you are trying to check 
in commented-out code instead of removing it.

/Magnus

On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue whereby it is seen that 
> WindowsLookAndFeel classes are built for non-windows platform,
> where it is not needed.
> Proposed fix is to remove building these classes for non-windows 
> platform.
>
> JPRT build is successful. Also, fixed the regression tests which 
> expects this classes to be available in non-unix platform.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>
> There are some closed regression test which will be taken care after 
> this in a separate crucible review.
>
> Regards
> Prasanta



From prasanta.sadhukhan at oracle.com  Wed May 17 10:49:14 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 17 May 2017 16:19:14 +0530
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
In-Reply-To: <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
Message-ID: <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>

Yes, actually I am bit unsure of how to proceed with that. It is meant 
to open internal java.desktop classes "only" to jdk.jconsole but now 
afer this fix, these classes will only be available in windows platform, 
so it should be a conditional "open" and I am not sure if 
module-info.java allows conditional open.

Regards
Prasanta
On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
> Build changes looks good. However in 
> src/java.desktop/share/classes/module-info.java you are trying to 
> check in commented-out code instead of removing it.
>
> /Magnus
>
> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue whereby it is seen that 
>> WindowsLookAndFeel classes are built for non-windows platform,
>> where it is not needed.
>> Proposed fix is to remove building these classes for non-windows 
>> platform.
>>
>> JPRT build is successful. Also, fixed the regression tests which 
>> expects this classes to be available in non-unix platform.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>
>> There are some closed regression test which will be taken care after 
>> this in a separate crucible review.
>>
>> Regards
>> Prasanta
>



From erik.joelsson at oracle.com  Wed May 17 11:24:28 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 13:24:28 +0200
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
In-Reply-To: <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
Message-ID: <fd2ac322-e9a3-7d9e-9600-59a61e73be4c@oracle.com>

Instead of adding more explicit excludes, I would recommend moving the 
windows specific source files to:

jdk/src/java.desktop/windows/classes

That is the intended way of making sources platform specific.

If you still need to add the qualified export to jdk.jconsole, but just 
for windows, you can achieve this by creating:

jdk/src/java.desktop/windows/classes/module-info.java.extra

With the following content (+copyright header):

opens com.sun.java.swing.plaf.windows to jdk.jconsole

/Erik


On 2017-05-17 12:49, Prasanta Sadhukhan wrote:
> Yes, actually I am bit unsure of how to proceed with that. It is meant 
> to open internal java.desktop classes "only" to jdk.jconsole but now 
> afer this fix, these classes will only be available in windows 
> platform, so it should be a conditional "open" and I am not sure if 
> module-info.java allows conditional open.
>
> Regards
> Prasanta
> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>> Build changes looks good. However in 
>> src/java.desktop/share/classes/module-info.java you are trying to 
>> check in commented-out code instead of removing it.
>>
>> /Magnus
>>
>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue whereby it is seen that 
>>> WindowsLookAndFeel classes are built for non-windows platform,
>>> where it is not needed.
>>> Proposed fix is to remove building these classes for non-windows 
>>> platform.
>>>
>>> JPRT build is successful. Also, fixed the regression tests which 
>>> expects this classes to be available in non-unix platform.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>
>>> There are some closed regression test which will be taken care after 
>>> this in a separate crucible review.
>>>
>>> Regards
>>> Prasanta
>>
>



From semyon.sadetsky at oracle.com  Wed May 17 14:53:24 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 17 May 2017 07:53:24 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
Message-ID: <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>

It seems, !(parentComponent instanceof Frame)) is not what the spec means.

--Semyon

On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
> Ok, sorry. Updated code to get the default Frame when component has no 
> Frame and
> testcase to test that case too.
> Updated webrev
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/
>
> Regards
> Prasanta
> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>>
>> Yes, sorry. I meant the case I've mentioned in my first comment : 
>> when the component has no frame.
>>
>> parentComponent determines the <code>Frame</code> * in which the 
>> dialog is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used
>>
>> --Semyon
>>
>> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>>
>>> Not sure which testcase you are running. I do not see this exception 
>>> when I run my testcase in the webrev.
>>>
>>> I am using createDialog in the fix for null parentComponent and not 
>>> createInternalFrame() which throws this exception.
>>>
>>> Regards
>>> Prasanta
>>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>>>
>>>> I don't see how this change fixes the issue.
>>>>
>>>> I still got
>>>>
>>>> Exception in thread "main" java.lang.RuntimeException: JOptionPane: 
>>>> parentComponent does not have a valid parent
>>>>
>>>> after applying it.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Updated webrev to use getRootFrame() via createDialog() to get the 
>>>>> default Frame when a frame is not provided.
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>>>
>>>>>> Also the spec says to use the default frame but the fix creates 
>>>>>> new frame each time.
>>>>>>
>>>>>>
>>>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>>>
>>>>>>> The fix covers the parentComponent=null case.
>>>>>>>
>>>>>>> What about the second case when non-null component is provided 
>>>>>>> but it has no frame?
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review a spec violation issue whereby if in 
>>>>>>>> JOptionPane.showInternalConfirmDialog(Component 
>>>>>>>> parentComponent, Object message)
>>>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>>>> "parentComponent does not have a valid parent"
>>>>>>>>
>>>>>>>> but as per spec, 
>>>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>>>> it says "|parentComponent| - determines the |Frame| in which 
>>>>>>>> the dialog is displayed; if |null|, or if the |parentComponent| 
>>>>>>>> has no |Frame|, a default |Frame| is used"
>>>>>>>>
>>>>>>>> This violation exists for all overridden 
>>>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>>>
>>>>>>>> The proposed fix creates a default JFrame and shows the confirm 
>>>>>>>> dialog in it, as stated in the spec.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta 
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170517/eade86b5/attachment.html>

From philip.race at oracle.com  Wed May 17 18:19:01 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:19:01 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <59164F29.8070300@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
Message-ID: <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>

I am not sure we are using the summary in a way that  makes it worthwhile.
As you noted in the other mail
"The summary attribute was used to give a more descriptive value
of the contents of the table.   A caption is more like a title"

The values I see are more like a title and as you say that is not the 
idea. See the example here

https://www.w3.org/TR/WCAG20-TECHS/H73.html

Caption sounds like a title so it might actually be more appropriate 
than summary
for the text we have except that its not clear why we'd want it to be 
visible when we were fine without.

But being there and invisible may be pointless unless screen readers 
look for it even if invisible.

But if its not doing any harm I guess we can leave it as proposed

I still need to look at the rest of the changes.

-phil.

On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
> Sergey,
>
> FWIW, the invisible caption should be regarded as a temporary 
> solution, until content authors can review/update the text of the 
> caption and make it visible.
>
> The general guideline in this conversion work has been to avoid 
> changing the visible text of the specification, and captions fall into 
> a grey area of whether the text is significant/normative or not.  
> Hence the temporary step to make them not displayed for now.
>
> -- Jon
>
> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>> The "summary" is unsupported by the HTML5 and we replace it by 
>> invisible caption.
>> These new styles are located in the stylesheet.css in the root of the 
>> JavaDoc api folder, so I assume these styles should be used by others 
>> as well.
>> They were added by this fix:
>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>
>> ----- philip.race at oracle.com wrote:
>>
>>> Does this in any way match the rest of the docs ? Or is everyone left
>>> to
>>> style things how they want.
>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>> styles.
>>>
>>> Also why are all the table summaries removed ?
>>>
>>> -phil.
>>>
>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>> This is because I use the same style for most of the tables
>>> 'class="striped"', which apply the same/unified style for all(most) of
>>> our tables.
>>>> Also this is because I removed 'inlined' styles, like here:
>>>>
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>> ----- philip.race at oracle.com wrote:
>>>>
>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>
>>>>> What is the general reason for changing the appearance of the
>>> tables?
>>>>> -phil.
>>>>>
>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk9-dev.
>>>>>>
>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>> compatible to HTML5.
>>>>>> It covers all errors which are reported by the javadoc tool
>>> during
>>>>> the build of jdk for java.desktop module.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>> Note that an appearance of some tables were changed after the
>>> fix:
>>>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>
>>>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>>>> After :
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>
>>>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>
>



From jonathan.gibbons at oracle.com  Wed May 17 18:52:25 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 17 May 2017 11:52:25 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
Message-ID: <591C9BE9.1080905@oracle.com>

Phil,

The bottom line is that in the JDK docs, tables should not have a 
summary attribute and should have a caption. This comes down to 
accessibility requirements, where we are slowly raising the bar on our 
docs, to be in accordance with Oracle's guidelines.

Hiding the caption (style="display:none") is an interim measure we have 
been using during the HTML 5 updates, especially in cases where the 
person doing the markup changes did not know enough to create an 
appropriate caption that should be displayed. In time, we should locate 
and update all table captions (in our standard docs bundle) that are not 
being displayed such that the text is both appropriate and visible.  If 
you guys want to do that as part of this update, go ahead.  FWIW, that 
is what we did for the java.xml module in the jaxp repo ... pretty much 
all tables there now have a reasonable, visible caption.

-- Jon



On 05/17/2017 11:19 AM, Phil Race wrote:
> I am not sure we are using the summary in a way that makes it worthwhile.
> As you noted in the other mail
> "The summary attribute was used to give a more descriptive value
> of the contents of the table.   A caption is more like a title"
>
> The values I see are more like a title and as you say that is not the 
> idea. See the example here
>
> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>
> Caption sounds like a title so it might actually be more appropriate 
> than summary
> for the text we have except that its not clear why we'd want it to be 
> visible when we were fine without.
>
> But being there and invisible may be pointless unless screen readers 
> look for it even if invisible.
>
> But if its not doing any harm I guess we can leave it as proposed
>
> I still need to look at the rest of the changes.
>
> -phil.
>
> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>> Sergey,
>>
>> FWIW, the invisible caption should be regarded as a temporary 
>> solution, until content authors can review/update the text of the 
>> caption and make it visible.
>>
>> The general guideline in this conversion work has been to avoid 
>> changing the visible text of the specification, and captions fall 
>> into a grey area of whether the text is significant/normative or 
>> not.  Hence the temporary step to make them not displayed for now.
>>
>> -- Jon
>>
>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>> invisible caption.
>>> These new styles are located in the stylesheet.css in the root of 
>>> the JavaDoc api folder, so I assume these styles should be used by 
>>> others as well.
>>> They were added by this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Does this in any way match the rest of the docs ? Or is everyone left
>>>> to
>>>> style things how they want.
>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>> styles.
>>>>
>>>> Also why are all the table summaries removed ?
>>>>
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>> This is because I use the same style for most of the tables
>>>> 'class="striped"', which apply the same/unified style for all(most) of
>>>> our tables.
>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> ----- philip.race at oracle.com wrote:
>>>>>
>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>
>>>>>> What is the general reason for changing the appearance of the
>>>> tables?
>>>>>> -phil.
>>>>>>
>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>> Hello,
>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>
>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>> compatible to HTML5.
>>>>>>> It covers all errors which are reported by the javadoc tool
>>>> during
>>>>>> the build of jdk for java.desktop module.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>> Note that an appearance of some tables were changed after the
>>>> fix:
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> After :
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>
>



From philip.race at oracle.com  Wed May 17 18:52:04 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:52:04 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
Message-ID: <5322c0d0-1ce4-10e8-e9e0-df305420274c@oracle.com>

I've looked through all the files now. No other comments. So approved.

-phil.

On 05/17/2017 11:19 AM, Phil Race wrote:
> I am not sure we are using the summary in a way that makes it worthwhile.
> As you noted in the other mail
> "The summary attribute was used to give a more descriptive value
> of the contents of the table.   A caption is more like a title"
>
> The values I see are more like a title and as you say that is not the 
> idea. See the example here
>
> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>
> Caption sounds like a title so it might actually be more appropriate 
> than summary
> for the text we have except that its not clear why we'd want it to be 
> visible when we were fine without.
>
> But being there and invisible may be pointless unless screen readers 
> look for it even if invisible.
>
> But if its not doing any harm I guess we can leave it as proposed
>
> I still need to look at the rest of the changes.
>
> -phil.
>
> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>> Sergey,
>>
>> FWIW, the invisible caption should be regarded as a temporary 
>> solution, until content authors can review/update the text of the 
>> caption and make it visible.
>>
>> The general guideline in this conversion work has been to avoid 
>> changing the visible text of the specification, and captions fall 
>> into a grey area of whether the text is significant/normative or 
>> not.  Hence the temporary step to make them not displayed for now.
>>
>> -- Jon
>>
>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>> invisible caption.
>>> These new styles are located in the stylesheet.css in the root of 
>>> the JavaDoc api folder, so I assume these styles should be used by 
>>> others as well.
>>> They were added by this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Does this in any way match the rest of the docs ? Or is everyone left
>>>> to
>>>> style things how they want.
>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>> styles.
>>>>
>>>> Also why are all the table summaries removed ?
>>>>
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>> This is because I use the same style for most of the tables
>>>> 'class="striped"', which apply the same/unified style for all(most) of
>>>> our tables.
>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> ----- philip.race at oracle.com wrote:
>>>>>
>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>
>>>>>> What is the general reason for changing the appearance of the
>>>> tables?
>>>>>> -phil.
>>>>>>
>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>> Hello,
>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>
>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>> compatible to HTML5.
>>>>>>> It covers all errors which are reported by the javadoc tool
>>>> during
>>>>>> the build of jdk for java.desktop module.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>> Note that an appearance of some tables were changed after the
>>>> fix:
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> After :
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>
>



From philip.race at oracle.com  Wed May 17 18:54:42 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:54:42 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <591C9BE9.1080905@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
 <591C9BE9.1080905@oracle.com>
Message-ID: <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>

I will leave the decision on whether to do that now up to Sergey although
it seems all he has to do here is remove "invisible".
Many of the "summary" ones had wrong or misleading text but they
seem to have been all fixed.

I'd want to see what the new HTML looks like with a visible title of 
course ..

-phil.

On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
> Phil,
>
> The bottom line is that in the JDK docs, tables should not have a 
> summary attribute and should have a caption. This comes down to 
> accessibility requirements, where we are slowly raising the bar on our 
> docs, to be in accordance with Oracle's guidelines.
>
> Hiding the caption (style="display:none") is an interim measure we 
> have been using during the HTML 5 updates, especially in cases where 
> the person doing the markup changes did not know enough to create an 
> appropriate caption that should be displayed. In time, we should 
> locate and update all table captions (in our standard docs bundle) 
> that are not being displayed such that the text is both appropriate 
> and visible.  If you guys want to do that as part of this update, go 
> ahead.  FWIW, that is what we did for the java.xml module in the jaxp 
> repo ... pretty much all tables there now have a reasonable, visible 
> caption.
>
> -- Jon
>
>
>
> On 05/17/2017 11:19 AM, Phil Race wrote:
>> I am not sure we are using the summary in a way that makes it 
>> worthwhile.
>> As you noted in the other mail
>> "The summary attribute was used to give a more descriptive value
>> of the contents of the table.   A caption is more like a title"
>>
>> The values I see are more like a title and as you say that is not the 
>> idea. See the example here
>>
>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>
>> Caption sounds like a title so it might actually be more appropriate 
>> than summary
>> for the text we have except that its not clear why we'd want it to be 
>> visible when we were fine without.
>>
>> But being there and invisible may be pointless unless screen readers 
>> look for it even if invisible.
>>
>> But if its not doing any harm I guess we can leave it as proposed
>>
>> I still need to look at the rest of the changes.
>>
>> -phil.
>>
>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>> Sergey,
>>>
>>> FWIW, the invisible caption should be regarded as a temporary 
>>> solution, until content authors can review/update the text of the 
>>> caption and make it visible.
>>>
>>> The general guideline in this conversion work has been to avoid 
>>> changing the visible text of the specification, and captions fall 
>>> into a grey area of whether the text is significant/normative or 
>>> not.  Hence the temporary step to make them not displayed for now.
>>>
>>> -- Jon
>>>
>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>>> invisible caption.
>>>> These new styles are located in the stylesheet.css in the root of 
>>>> the JavaDoc api folder, so I assume these styles should be used by 
>>>> others as well.
>>>> They were added by this fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>
>>>> ----- philip.race at oracle.com wrote:
>>>>
>>>>> Does this in any way match the rest of the docs ? Or is everyone left
>>>>> to
>>>>> style things how they want.
>>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>>> styles.
>>>>>
>>>>> Also why are all the table summaries removed ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>> This is because I use the same style for most of the tables
>>>>> 'class="striped"', which apply the same/unified style for 
>>>>> all(most) of
>>>>> our tables.
>>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>>
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>
>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>
>>>>>>> What is the general reason for changing the appearance of the
>>>>> tables?
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello,
>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>
>>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>>> compatible to HTML5.
>>>>>>>> It covers all errors which are reported by the javadoc tool
>>>>> during
>>>>>>> the build of jdk for java.desktop module.
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>> Note that an appearance of some tables were changed after the
>>>>> fix:
>>>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>>>> After :
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>>
>>
>



From philip.race at oracle.com  Wed May 17 18:58:53 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:58:53 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
 <591C9BE9.1080905@oracle.com>
 <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>
Message-ID: <f1af3ebd-abde-d4e4-1091-e6165612cba6@oracle.com>

And PS I was not saying anything to contradict
 > tables should not have a summary attribute and should have a caption.

However that the docs I read on the web did seem to imply that
summary was very much intended for ATs but it was not at all clear this
is the point of caption. I'm sure they can read it, but I don't get how 
making
it visible matters to them so how it making it visible relates to 
accessibility
requirements is not an obvious connection to me. So why do we have
to make it visible for ATs ?

-phil.

On 05/17/2017 11:54 AM, Phil Race wrote:
> I will leave the decision on whether to do that now up to Sergey although
> it seems all he has to do here is remove "invisible".
> Many of the "summary" ones had wrong or misleading text but they
> seem to have been all fixed.
>
> I'd want to see what the new HTML looks like with a visible title of 
> course ..
>
> -phil.
>
> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>> Phil,
>>
>> The bottom line is that in the JDK docs, tables should not have a 
>> summary attribute and should have a caption. This comes down to 
>> accessibility requirements, where we are slowly raising the bar on 
>> our docs, to be in accordance with Oracle's guidelines.
>>
>> Hiding the caption (style="display:none") is an interim measure we 
>> have been using during the HTML 5 updates, especially in cases where 
>> the person doing the markup changes did not know enough to create an 
>> appropriate caption that should be displayed. In time, we should 
>> locate and update all table captions (in our standard docs bundle) 
>> that are not being displayed such that the text is both appropriate 
>> and visible. If you guys want to do that as part of this update, go 
>> ahead. FWIW, that is what we did for the java.xml module in the jaxp 
>> repo ... pretty much all tables there now have a reasonable, visible 
>> caption.
>>
>> -- Jon
>>
>>
>>
>> On 05/17/2017 11:19 AM, Phil Race wrote:
>>> I am not sure we are using the summary in a way that makes it 
>>> worthwhile.
>>> As you noted in the other mail
>>> "The summary attribute was used to give a more descriptive value
>>> of the contents of the table.   A caption is more like a title"
>>>
>>> The values I see are more like a title and as you say that is not 
>>> the idea. See the example here
>>>
>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>>
>>> Caption sounds like a title so it might actually be more appropriate 
>>> than summary
>>> for the text we have except that its not clear why we'd want it to 
>>> be visible when we were fine without.
>>>
>>> But being there and invisible may be pointless unless screen readers 
>>> look for it even if invisible.
>>>
>>> But if its not doing any harm I guess we can leave it as proposed
>>>
>>> I still need to look at the rest of the changes.
>>>
>>> -phil.
>>>
>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>>> Sergey,
>>>>
>>>> FWIW, the invisible caption should be regarded as a temporary 
>>>> solution, until content authors can review/update the text of the 
>>>> caption and make it visible.
>>>>
>>>> The general guideline in this conversion work has been to avoid 
>>>> changing the visible text of the specification, and captions fall 
>>>> into a grey area of whether the text is significant/normative or 
>>>> not.  Hence the temporary step to make them not displayed for now.
>>>>
>>>> -- Jon
>>>>
>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>>>> invisible caption.
>>>>> These new styles are located in the stylesheet.css in the root of 
>>>>> the JavaDoc api folder, so I assume these styles should be used by 
>>>>> others as well.
>>>>> They were added by this fix:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>>
>>>>> ----- philip.race at oracle.com wrote:
>>>>>
>>>>>> Does this in any way match the rest of the docs ? Or is everyone 
>>>>>> left
>>>>>> to
>>>>>> style things how they want.
>>>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>>>> styles.
>>>>>>
>>>>>> Also why are all the table summaries removed ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>>> This is because I use the same style for most of the tables
>>>>>> 'class="striped"', which apply the same/unified style for 
>>>>>> all(most) of
>>>>>> our tables.
>>>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>>>
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>
>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>
>>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>>
>>>>>>>> What is the general reason for changing the appearance of the
>>>>>> tables?
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello,
>>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>>
>>>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>>>> compatible to HTML5.
>>>>>>>>> It covers all errors which are reported by the javadoc tool
>>>>>> during
>>>>>>>> the build of jdk for java.desktop module.
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>>> Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>>> Note that an appearance of some tables were changed after the
>>>>>> fix:
>>>>>>>>> Before:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>
>>>>>>>>> After:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>>
>>>>>>>>> Before:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>>
>>>>>>>>> After :
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>>
>>>>>>>>> Before:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>>
>>>>>>>>> After:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Wed May 17 19:06:51 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 12:06:51 -0700
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
In-Reply-To: <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
Message-ID: <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>

The way to do this is to create a file
src/java.desktop/windows/classes/module-info.java.extra

and move the opens there.

See for example
src/java.base/windows/classes/module-info.java.extra

But are you sure jdk.jconsole needs these only on Windows ?
Better make sure of it.

-phil.

On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
> Yes, actually I am bit unsure of how to proceed with that. It is meant 
> to open internal java.desktop classes "only" to jdk.jconsole but now 
> afer this fix, these classes will only be available in windows 
> platform, so it should be a conditional "open" and I am not sure if 
> module-info.java allows conditional open.
>
> Regards
> Prasanta
> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>> Build changes looks good. However in 
>> src/java.desktop/share/classes/module-info.java you are trying to 
>> check in commented-out code instead of removing it.
>>
>> /Magnus
>>
>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue whereby it is seen that 
>>> WindowsLookAndFeel classes are built for non-windows platform,
>>> where it is not needed.
>>> Proposed fix is to remove building these classes for non-windows 
>>> platform.
>>>
>>> JPRT build is successful. Also, fixed the regression tests which 
>>> expects this classes to be available in non-unix platform.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>
>>> There are some closed regression test which will be taken care after 
>>> this in a separate crucible review.
>>>
>>> Regards
>>> Prasanta
>>
>



From jonathan.gibbons at oracle.com  Wed May 17 21:41:17 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 17 May 2017 14:41:17 -0700
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
In-Reply-To: <f1af3ebd-abde-d4e4-1091-e6165612cba6@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
 <591C9BE9.1080905@oracle.com>
 <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>
 <f1af3ebd-abde-d4e4-1091-e6165612cba6@oracle.com>
Message-ID: <591CC37D.70709@oracle.com>

Phil,

I have no evidence one way or the other whether screen readers pay 
attention
to undisplayed or invisible captions. It seemed safest to assume that 
they would
read a visible caption, and that we should head in that general direction.

-- Jon


On 05/17/2017 11:58 AM, Phil Race wrote:
> And PS I was not saying anything to contradict
> > tables should not have a summary attribute and should have a caption.
>
> However that the docs I read on the web did seem to imply that
> summary was very much intended for ATs but it was not at all clear this
> is the point of caption. I'm sure they can read it, but I don't get 
> how making
> it visible matters to them so how it making it visible relates to 
> accessibility
> requirements is not an obvious connection to me. So why do we have
> to make it visible for ATs ?
>
> -phil.
>
> On 05/17/2017 11:54 AM, Phil Race wrote:
>> I will leave the decision on whether to do that now up to Sergey 
>> although
>> it seems all he has to do here is remove "invisible".
>> Many of the "summary" ones had wrong or misleading text but they
>> seem to have been all fixed.
>>
>> I'd want to see what the new HTML looks like with a visible title of 
>> course ..
>>
>> -phil.
>>
>> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>>> Phil,
>>>
>>> The bottom line is that in the JDK docs, tables should not have a 
>>> summary attribute and should have a caption. This comes down to 
>>> accessibility requirements, where we are slowly raising the bar on 
>>> our docs, to be in accordance with Oracle's guidelines.
>>>
>>> Hiding the caption (style="display:none") is an interim measure we 
>>> have been using during the HTML 5 updates, especially in cases where 
>>> the person doing the markup changes did not know enough to create an 
>>> appropriate caption that should be displayed. In time, we should 
>>> locate and update all table captions (in our standard docs bundle) 
>>> that are not being displayed such that the text is both appropriate 
>>> and visible. If you guys want to do that as part of this update, go 
>>> ahead. FWIW, that is what we did for the java.xml module in the jaxp 
>>> repo ... pretty much all tables there now have a reasonable, visible 
>>> caption.
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 05/17/2017 11:19 AM, Phil Race wrote:
>>>> I am not sure we are using the summary in a way that makes it 
>>>> worthwhile.
>>>> As you noted in the other mail
>>>> "The summary attribute was used to give a more descriptive value
>>>> of the contents of the table.   A caption is more like a title"
>>>>
>>>> The values I see are more like a title and as you say that is not 
>>>> the idea. See the example here
>>>>
>>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>>>
>>>> Caption sounds like a title so it might actually be more 
>>>> appropriate than summary
>>>> for the text we have except that its not clear why we'd want it to 
>>>> be visible when we were fine without.
>>>>
>>>> But being there and invisible may be pointless unless screen 
>>>> readers look for it even if invisible.
>>>>
>>>> But if its not doing any harm I guess we can leave it as proposed
>>>>
>>>> I still need to look at the rest of the changes.
>>>>
>>>> -phil.
>>>>
>>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>>>> Sergey,
>>>>>
>>>>> FWIW, the invisible caption should be regarded as a temporary 
>>>>> solution, until content authors can review/update the text of the 
>>>>> caption and make it visible.
>>>>>
>>>>> The general guideline in this conversion work has been to avoid 
>>>>> changing the visible text of the specification, and captions fall 
>>>>> into a grey area of whether the text is significant/normative or 
>>>>> not.  Hence the temporary step to make them not displayed for now.
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>>>>> invisible caption.
>>>>>> These new styles are located in the stylesheet.css in the root of 
>>>>>> the JavaDoc api folder, so I assume these styles should be used 
>>>>>> by others as well.
>>>>>> They were added by this fix:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>>>
>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>
>>>>>>> Does this in any way match the rest of the docs ? Or is everyone 
>>>>>>> left
>>>>>>> to
>>>>>>> style things how they want.
>>>>>>> I thought (?) maybe there is to be some javadoc tool support for 
>>>>>>> CSS
>>>>>>> styles.
>>>>>>>
>>>>>>> Also why are all the table summaries removed ?
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>>>> This is because I use the same style for most of the tables
>>>>>>> 'class="striped"', which apply the same/unified style for 
>>>>>>> all(most) of
>>>>>>> our tables.
>>>>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>>
>>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>>
>>>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>>>
>>>>>>>>> What is the general reason for changing the appearance of the
>>>>>>> tables?
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>>>
>>>>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>>>>> compatible to HTML5.
>>>>>>>>>> It covers all errors which are reported by the javadoc tool
>>>>>>> during
>>>>>>>>> the build of jdk for java.desktop module.
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>>>> Webrev can be found at:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>>>> Note that an appearance of some tables were changed after the
>>>>>>> fix:
>>>>>>>>>> Before:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>>
>>>>>>>>>> After:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>>>
>>>>>>>>>> Before:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>>>
>>>>>>>>>> After :
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>>>
>>>>>>>>>> Before:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>>>
>>>>>>>>>> After:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>>>
>>>>>
>>>>
>>>
>>
>



From prasanta.sadhukhan at oracle.com  Thu May 18 07:01:07 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 18 May 2017 12:31:07 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
Message-ID: <68147697-046a-1db5-c954-af6e2063b643@oracle.com>

Not sure about the exact meaning of that but anyways tried to make the 
code spec-compliant.

http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/

If you think it still does not adhere to spec, please suggest what more 
needs to be done.

Regards
Prasanta
On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>
> It seems, !(parentComponent instanceof Frame)) is not what the spec means.
>
> --Semyon
>
> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
>> Ok, sorry. Updated code to get the default Frame when component has 
>> no Frame and
>> testcase to test that case too.
>> Updated webrev
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/
>>
>> Regards
>> Prasanta
>> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>>>
>>> Yes, sorry. I meant the case I've mentioned in my first comment : 
>>> when the component has no frame.
>>>
>>> parentComponent determines the <code>Frame</code> * in which the 
>>> dialog is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used
>>>
>>> --Semyon
>>>
>>> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>>>
>>>> Not sure which testcase you are running. I do not see this 
>>>> exception when I run my testcase in the webrev.
>>>>
>>>> I am using createDialog in the fix for null parentComponent and not 
>>>> createInternalFrame() which throws this exception.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>>>>
>>>>> I don't see how this change fixes the issue.
>>>>>
>>>>> I still got
>>>>>
>>>>> Exception in thread "main" java.lang.RuntimeException: 
>>>>> JOptionPane: parentComponent does not have a valid parent
>>>>>
>>>>> after applying it.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Updated webrev to use getRootFrame() via createDialog() to get 
>>>>>> the default Frame when a frame is not provided.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>>>>
>>>>>>> Also the spec says to use the default frame but the fix creates 
>>>>>>> new frame each time.
>>>>>>>
>>>>>>>
>>>>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>>>>
>>>>>>>> The fix covers the parentComponent=null case.
>>>>>>>>
>>>>>>>> What about the second case when non-null component is provided 
>>>>>>>> but it has no frame?
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a spec violation issue whereby if in 
>>>>>>>>> JOptionPane.showInternalConfirmDialog(Component 
>>>>>>>>> parentComponent, Object message)
>>>>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>>>>> "parentComponent does not have a valid parent"
>>>>>>>>>
>>>>>>>>> but as per spec, 
>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>>>>> it says "|parentComponent| - determines the |Frame| in which 
>>>>>>>>> the dialog is displayed; if |null|, or if the 
>>>>>>>>> |parentComponent| has no |Frame|, a default |Frame| is used"
>>>>>>>>>
>>>>>>>>> This violation exists for all overridden 
>>>>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>>>>
>>>>>>>>> The proposed fix creates a default JFrame and shows the 
>>>>>>>>> confirm dialog in it, as stated in the spec.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta 
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170518/6f502786/attachment.html>

From prasanta.sadhukhan at oracle.com  Thu May 18 08:01:55 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 18 May 2017 13:31:55 +0530
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
In-Reply-To: <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
 <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>
Message-ID: <21fb6605-e4d3-657c-766c-0a93cd15f721@oracle.com>

So far I have looked, it seems jdk.jconsole uses this classes for 
windows only. These classes are specified in
JConsole.java where it checks (for non-windows, it will come as 
GTKLookAndFeel)

String systemLaF = UIManager.getSystemLookAndFeelClassName();
if (systemLaF.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") ||
systemLaF.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) {

try {
UIManager.setLookAndFeel(systemLaF); MaximizableInternalFrame.java where 
it checks for this classes in windows only if (JConsole.IS_WIN) {
try {
Class<?> Part =
Class.forName("com.sun.java.swing.plaf.windows.TMSchema$Part"); and 
Utilities.java where it checks LookAndFeel laf = UIManager.getLookAndFeel();
boolean transparent = laf.getClass().getName().equals(windowsLaF);

Modified webrev
http://cr.openjdk.java.net/~psadhukhan/6461834/01/

Regards
Prasanta

On 5/18/2017 12:36 AM, Phil Race wrote:
> The way to do this is to create a file
> src/java.desktop/windows/classes/module-info.java.extra
>
> and move the opens there.
>
> See for example
> src/java.base/windows/classes/module-info.java.extra
>
> But are you sure jdk.jconsole needs these only on Windows ?
> Better make sure of it.
>
> -phil.
>
> On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
>> Yes, actually I am bit unsure of how to proceed with that. It is 
>> meant to open internal java.desktop classes "only" to jdk.jconsole 
>> but now afer this fix, these classes will only be available in 
>> windows platform, so it should be a conditional "open" and I am not 
>> sure if module-info.java allows conditional open.
>>
>> Regards
>> Prasanta
>> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>>> Build changes looks good. However in 
>>> src/java.desktop/share/classes/module-info.java you are trying to 
>>> check in commented-out code instead of removing it.
>>>
>>> /Magnus
>>>
>>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue whereby it is seen that 
>>>> WindowsLookAndFeel classes are built for non-windows platform,
>>>> where it is not needed.
>>>> Proposed fix is to remove building these classes for non-windows 
>>>> platform.
>>>>
>>>> JPRT build is successful. Also, fixed the regression tests which 
>>>> expects this classes to be available in non-unix platform.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>>
>>>> There are some closed regression test which will be taken care 
>>>> after this in a separate crucible review.
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170518/788a7f46/attachment.html>

From semyon.sadetsky at oracle.com  Thu May 18 15:14:15 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 18 May 2017 08:14:15 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
Message-ID: <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>

This version of the fix formally corresponds to the spec. (I did not 
check the spec for validity.)

         if (parentComponent == null)
             return false;
         if (parentComponent instanceof Frame)
             return true;
         return 
JOptionPane.checkFrameForComponent(parentComponent.getParent());

- "JOptionPane." is not necessary.

- Please, add braces to the both if conditions.

         if (parentComponent == null || 
!(checkFrameForComponent(parentComponent))) {

- "parentComponent == null" is not necessary now

- to avoid extra "not" operation the if statement could be inverted.

--Semyon


On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:
>
> Not sure about the exact meaning of that but anyways tried to make the 
> code spec-compliant.
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/
>
> If you think it still does not adhere to spec, please suggest what 
> more needs to be done.
>
> Regards
> Prasanta
> On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>>
>> It seems, !(parentComponent instanceof Frame)) is not what the spec 
>> means.
>>
>> --Semyon
>>
>> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
>>> Ok, sorry. Updated code to get the default Frame when component has 
>>> no Frame and
>>> testcase to test that case too.
>>> Updated webrev
>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>>>>
>>>> Yes, sorry. I meant the case I've mentioned in my first comment : 
>>>> when the component has no frame.
>>>>
>>>> parentComponent determines the <code>Frame</code> * in which the 
>>>> dialog is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used
>>>>
>>>> --Semyon
>>>>
>>>> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Not sure which testcase you are running. I do not see this 
>>>>> exception when I run my testcase in the webrev.
>>>>>
>>>>> I am using createDialog in the fix for null parentComponent and 
>>>>> not createInternalFrame() which throws this exception.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>>>>>
>>>>>> I don't see how this change fixes the issue.
>>>>>>
>>>>>> I still got
>>>>>>
>>>>>> Exception in thread "main" java.lang.RuntimeException: 
>>>>>> JOptionPane: parentComponent does not have a valid parent
>>>>>>
>>>>>> after applying it.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> Updated webrev to use getRootFrame() via createDialog() to get 
>>>>>>> the default Frame when a frame is not provided.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>>>>>
>>>>>>>> Also the spec says to use the default frame but the fix creates 
>>>>>>>> new frame each time.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>>>>>
>>>>>>>>> The fix covers the parentComponent=null case.
>>>>>>>>>
>>>>>>>>> What about the second case when non-null component is provided 
>>>>>>>>> but it has no frame?
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review a spec violation issue whereby if in 
>>>>>>>>>> JOptionPane.showInternalConfirmDialog(Component 
>>>>>>>>>> parentComponent, Object message)
>>>>>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>>>>>> "parentComponent does not have a valid parent"
>>>>>>>>>>
>>>>>>>>>> but as per spec, 
>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>>>>>> it says "|parentComponent| - determines the |Frame| in which 
>>>>>>>>>> the dialog is displayed; if |null|, or if the 
>>>>>>>>>> |parentComponent| has no |Frame|, a default |Frame| is used"
>>>>>>>>>>
>>>>>>>>>> This violation exists for all overridden 
>>>>>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>>>>>
>>>>>>>>>> The proposed fix creates a default JFrame and shows the 
>>>>>>>>>> confirm dialog in it, as stated in the spec.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta 
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170518/2b86c692/attachment.html>

From sergey.bylokhov at oracle.com  Thu May 18 21:48:39 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 May 2017 14:48:39 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8180326 Update the tables in
 java.desktop to be HTML-5 friendly
Message-ID: <541766fe-bd76-487f-9d4d-946cd87906c5@default>

Hello.
Here is an updated version where most of the caption are visible.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.02/
Specdiff: http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html

You can use search to check the changes in some specific class:
Old docs: http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
New docs: http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html


----- jonathan.gibbons at oracle.com wrote:

> Phil,
> 
> I have no evidence one way or the other whether screen readers pay 
> attention
> to undisplayed or invisible captions. It seemed safest to assume that
> 
> they would
> read a visible caption, and that we should head in that general
> direction.
> 
> -- Jon
> 
> 
> On 05/17/2017 11:58 AM, Phil Race wrote:
> > And PS I was not saying anything to contradict
> > > tables should not have a summary attribute and should have a
> caption.
> >
> > However that the docs I read on the web did seem to imply that
> > summary was very much intended for ATs but it was not at all clear
> this
> > is the point of caption. I'm sure they can read it, but I don't get
> 
> > how making
> > it visible matters to them so how it making it visible relates to 
> > accessibility
> > requirements is not an obvious connection to me. So why do we have
> > to make it visible for ATs ?
> >
> > -phil.
> >
> > On 05/17/2017 11:54 AM, Phil Race wrote:
> >> I will leave the decision on whether to do that now up to Sergey 
> >> although
> >> it seems all he has to do here is remove "invisible".
> >> Many of the "summary" ones had wrong or misleading text but they
> >> seem to have been all fixed.
> >>
> >> I'd want to see what the new HTML looks like with a visible title
> of 
> >> course ..
> >>
> >> -phil.
> >>
> >> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
> >>> Phil,
> >>>
> >>> The bottom line is that in the JDK docs, tables should not have a
> 
> >>> summary attribute and should have a caption. This comes down to 
> >>> accessibility requirements, where we are slowly raising the bar on
> 
> >>> our docs, to be in accordance with Oracle's guidelines.
> >>>
> >>> Hiding the caption (style="display:none") is an interim measure we
> 
> >>> have been using during the HTML 5 updates, especially in cases
> where 
> >>> the person doing the markup changes did not know enough to create
> an 
> >>> appropriate caption that should be displayed. In time, we should 
> >>> locate and update all table captions (in our standard docs bundle)
> 
> >>> that are not being displayed such that the text is both
> appropriate 
> >>> and visible. If you guys want to do that as part of this update,
> go 
> >>> ahead. FWIW, that is what we did for the java.xml module in the
> jaxp 
> >>> repo ... pretty much all tables there now have a reasonable,
> visible 
> >>> caption.
> >>>
> >>> -- Jon
> >>>
> >>>
> >>>
> >>> On 05/17/2017 11:19 AM, Phil Race wrote:
> >>>> I am not sure we are using the summary in a way that makes it 
> >>>> worthwhile.
> >>>> As you noted in the other mail
> >>>> "The summary attribute was used to give a more descriptive value
> >>>> of the contents of the table.   A caption is more like a title"
> >>>>
> >>>> The values I see are more like a title and as you say that is not
> 
> >>>> the idea. See the example here
> >>>>
> >>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
> >>>>
> >>>> Caption sounds like a title so it might actually be more 
> >>>> appropriate than summary
> >>>> for the text we have except that its not clear why we'd want it
> to 
> >>>> be visible when we were fine without.
> >>>>
> >>>> But being there and invisible may be pointless unless screen 
> >>>> readers look for it even if invisible.
> >>>>
> >>>> But if its not doing any harm I guess we can leave it as
> proposed
> >>>>
> >>>> I still need to look at the rest of the changes.
> >>>>
> >>>> -phil.
> >>>>
> >>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
> >>>>> Sergey,
> >>>>>
> >>>>> FWIW, the invisible caption should be regarded as a temporary 
> >>>>> solution, until content authors can review/update the text of
> the 
> >>>>> caption and make it visible.
> >>>>>
> >>>>> The general guideline in this conversion work has been to avoid
> 
> >>>>> changing the visible text of the specification, and captions
> fall 
> >>>>> into a grey area of whether the text is significant/normative or
> 
> >>>>> not.  Hence the temporary step to make them not displayed for
> now.
> >>>>>
> >>>>> -- Jon
> >>>>>
> >>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
> >>>>>> The "summary" is unsupported by the HTML5 and we replace it by
> 
> >>>>>> invisible caption.
> >>>>>> These new styles are located in the stylesheet.css in the root
> of 
> >>>>>> the JavaDoc api folder, so I assume these styles should be used
> 
> >>>>>> by others as well.
> >>>>>> They were added by this fix:
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
> >>>>>>
> >>>>>> ----- philip.race at oracle.com wrote:
> >>>>>>
> >>>>>>> Does this in any way match the rest of the docs ? Or is
> everyone 
> >>>>>>> left
> >>>>>>> to
> >>>>>>> style things how they want.
> >>>>>>> I thought (?) maybe there is to be some javadoc tool support
> for 
> >>>>>>> CSS
> >>>>>>> styles.
> >>>>>>>
> >>>>>>> Also why are all the table summaries removed ?
> >>>>>>>
> >>>>>>> -phil.
> >>>>>>>
> >>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> >>>>>>>> This is because I use the same style for most of the tables
> >>>>>>> 'class="striped"', which apply the same/unified style for 
> >>>>>>> all(most) of
> >>>>>>> our tables.
> >>>>>>>> Also this is because I removed 'inlined' styles, like here:
> >>>>>>>>
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> 
> >>>>>>>
> >>>>>>>> ----- philip.race at oracle.com wrote:
> >>>>>>>>
> >>>>>>>>> Adding 2d-dev because a number of the files are 2D.
> >>>>>>>>>
> >>>>>>>>> What is the general reason for changing the appearance of
> the
> >>>>>>> tables?
> >>>>>>>>> -phil.
> >>>>>>>>>
> >>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> >>>>>>>>>> Hello,
> >>>>>>>>>> Please review the fix for jdk9-dev.
> >>>>>>>>>>
> >>>>>>>>>> This fix is a part of the effort to make all javadoc in
> jdk9 be
> >>>>>>>>> compatible to HTML5.
> >>>>>>>>>> It covers all errors which are reported by the javadoc
> tool
> >>>>>>> during
> >>>>>>>>> the build of jdk for java.desktop module.
> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> >>>>>>>>>> Webrev can be found at:
> >>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> >>>>>>>>>> Note that an appearance of some tables were changed after
> the
> >>>>>>> fix:
> >>>>>>>>>> Before:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> 
> >>>>>>>
> >>>>>>>>>> After:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> 
> >>>>>>>
> >>>>>>>>>> Before:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> 
> >>>>>>>
> >>>>>>>>>> After :
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> 
> >>>>>>>
> >>>>>>>>>> Before:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> 
> >>>>>>>
> >>>>>>>>>> After:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html
> 
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >


From prasanta.sadhukhan at oracle.com  Fri May 19 06:07:17 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 19 May 2017 11:37:17 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
 <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
Message-ID: <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>

Please find the modified webrev

http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.04/

Regards
Prasanta
On 5/18/2017 8:44 PM, Semyon Sadetsky wrote:
>
> This version of the fix formally corresponds to the spec. (I did not 
> check the spec for validity.)
>
>         if (parentComponent == null)
>             return false;
>         if (parentComponent instanceof Frame)
>             return true;
>         return 
> JOptionPane.checkFrameForComponent(parentComponent.getParent());
>
> - "JOptionPane." is not necessary.
>
> - Please, add braces to the both if conditions.
>
>         if (parentComponent == null || 
> !(checkFrameForComponent(parentComponent))) {
>
> - "parentComponent == null" is not necessary now
>
> - to avoid extra "not" operation the if statement could be inverted.
>
> --Semyon
>
>
> On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:
>>
>> Not sure about the exact meaning of that but anyways tried to make 
>> the code spec-compliant.
>>
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/
>>
>> If you think it still does not adhere to spec, please suggest what 
>> more needs to be done.
>>
>> Regards
>> Prasanta
>> On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>>>
>>> It seems, !(parentComponent instanceof Frame)) is not what the spec 
>>> means.
>>>
>>> --Semyon
>>>
>>> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
>>>> Ok, sorry. Updated code to get the default Frame when component has 
>>>> no Frame and
>>>> testcase to test that case too.
>>>> Updated webrev
>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>>>>>
>>>>> Yes, sorry. I meant the case I've mentioned in my first comment : 
>>>>> when the component has no frame.
>>>>>
>>>>> parentComponent determines the <code>Frame</code> * in which the 
>>>>> dialog is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Not sure which testcase you are running. I do not see this 
>>>>>> exception when I run my testcase in the webrev.
>>>>>>
>>>>>> I am using createDialog in the fix for null parentComponent and 
>>>>>> not createInternalFrame() which throws this exception.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>>>>>>
>>>>>>> I don't see how this change fixes the issue.
>>>>>>>
>>>>>>> I still got
>>>>>>>
>>>>>>> Exception in thread "main" java.lang.RuntimeException: 
>>>>>>> JOptionPane: parentComponent does not have a valid parent
>>>>>>>
>>>>>>> after applying it.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>> Updated webrev to use getRootFrame() via createDialog() to get 
>>>>>>>> the default Frame when a frame is not provided.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>>>>>>
>>>>>>>>> Also the spec says to use the default frame but the fix 
>>>>>>>>> creates new frame each time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>>>>>>
>>>>>>>>>> The fix covers the parentComponent=null case.
>>>>>>>>>>
>>>>>>>>>> What about the second case when non-null component is 
>>>>>>>>>> provided but it has no frame?
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review a spec violation issue whereby if in 
>>>>>>>>>>> JOptionPane.showInternalConfirmDialog(Component 
>>>>>>>>>>> parentComponent, Object message)
>>>>>>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>>>>>>> "parentComponent does not have a valid parent"
>>>>>>>>>>>
>>>>>>>>>>> but as per spec, 
>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>>>>>>> it says "|parentComponent| - determines the |Frame| in which 
>>>>>>>>>>> the dialog is displayed; if |null|, or if the 
>>>>>>>>>>> |parentComponent| has no |Frame|, a default |Frame| is used"
>>>>>>>>>>>
>>>>>>>>>>> This violation exists for all overridden 
>>>>>>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>>>>>>
>>>>>>>>>>> The proposed fix creates a default JFrame and shows the 
>>>>>>>>>>> confirm dialog in it, as stated in the spec.
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>>>>>>> webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta 
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170519/f1ec7699/attachment.html>

From semyon.sadetsky at oracle.com  Fri May 19 13:55:14 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 19 May 2017 06:55:14 -0700
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
 <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
 <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>
Message-ID: <26bc0b4c-a8bc-2f02-b66e-2608456c829d@oracle.com>

Looks good.

--Semyon


On 05/18/2017 11:07 PM, Prasanta Sadhukhan wrote:
>
> Please find the modified webrev
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.04/
>
> Regards
> Prasanta
> On 5/18/2017 8:44 PM, Semyon Sadetsky wrote:
>>
>> This version of the fix formally corresponds to the spec. (I did not 
>> check the spec for validity.)
>>
>>         if (parentComponent == null)
>>             return false;
>>         if (parentComponent instanceof Frame)
>>             return true;
>>         return 
>> JOptionPane.checkFrameForComponent(parentComponent.getParent());
>>
>> - "JOptionPane." is not necessary.
>>
>> - Please, add braces to the both if conditions.
>>
>>         if (parentComponent == null || 
>> !(checkFrameForComponent(parentComponent))) {
>>
>> - "parentComponent == null" is not necessary now
>>
>> - to avoid extra "not" operation the if statement could be inverted.
>>
>> --Semyon
>>
>>
>> On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:
>>>
>>> Not sure about the exact meaning of that but anyways tried to make 
>>> the code spec-compliant.
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/
>>>
>>> If you think it still does not adhere to spec, please suggest what 
>>> more needs to be done.
>>>
>>> Regards
>>> Prasanta
>>> On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>>>>
>>>> It seems, !(parentComponent instanceof Frame)) is not what the spec 
>>>> means.
>>>>
>>>> --Semyon
>>>>
>>>> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
>>>>> Ok, sorry. Updated code to get the default Frame when component 
>>>>> has no Frame and
>>>>> testcase to test that case too.
>>>>> Updated webrev
>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>>>>>>
>>>>>> Yes, sorry. I meant the case I've mentioned in my first comment : 
>>>>>> when the component has no frame.
>>>>>>
>>>>>> parentComponent determines the <code>Frame</code> * in which the 
>>>>>> dialog is displayed; if <code>null</code>, * *_or if the _**_<code>_**_parentComponent_**_</code> _**_has no _**_* _**_<code>_**_Frame_**_</code>_**_***_*, a default <code>Frame</code> is used
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> Not sure which testcase you are running. I do not see this 
>>>>>>> exception when I run my testcase in the webrev.
>>>>>>>
>>>>>>> I am using createDialog in the fix for null parentComponent and 
>>>>>>> not createInternalFrame() which throws this exception.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>>>>>>>
>>>>>>>> I don't see how this change fixes the issue.
>>>>>>>>
>>>>>>>> I still got
>>>>>>>>
>>>>>>>> Exception in thread "main" java.lang.RuntimeException: 
>>>>>>>> JOptionPane: parentComponent does not have a valid parent
>>>>>>>>
>>>>>>>> after applying it.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>
>>>>>>>>> Updated webrev to use getRootFrame() via createDialog() to get 
>>>>>>>>> the default Frame when a frame is not provided.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>>>>>>>>>
>>>>>>>>>> Also the spec says to use the default frame but the fix 
>>>>>>>>>> creates new frame each time.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>>>>>>>>>>
>>>>>>>>>>> The fix covers the parentComponent=null case.
>>>>>>>>>>>
>>>>>>>>>>> What about the second case when non-null component is 
>>>>>>>>>>> provided but it has no frame?
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review a spec violation issue whereby if in 
>>>>>>>>>>>> JOptionPane.showInternalConfirmDialog(Component 
>>>>>>>>>>>> parentComponent, Object message)
>>>>>>>>>>>> "parentComponent" is null, we are getting RuntimeException 
>>>>>>>>>>>> "parentComponent does not have a valid parent"
>>>>>>>>>>>>
>>>>>>>>>>>> but as per spec, 
>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>>>>>>>>>>>> it says "|parentComponent| - determines the |Frame| in 
>>>>>>>>>>>> which the dialog is displayed; if |null|, or if the 
>>>>>>>>>>>> |parentComponent| has no |Frame|, a default |Frame| is used"
>>>>>>>>>>>>
>>>>>>>>>>>> This violation exists for all overridden 
>>>>>>>>>>>> showInternalConfirmDialog methods and showInternalOptionDialog.
>>>>>>>>>>>>
>>>>>>>>>>>> The proposed fix creates a default JFrame and shows the 
>>>>>>>>>>>> confirm dialog in it, as stated in the spec.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>>>>>>>>>>>> webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta 
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170519/56e620b1/attachment.html>

From jason_mehrens at hotmail.com  Fri May 19 21:16:19 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 19 May 2017 21:16:19 +0000
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <26bc0b4c-a8bc-2f02-b66e-2608456c829d@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
 <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
 <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>,
 <26bc0b4c-a8bc-2f02-b66e-2608456c829d@oracle.com>
Message-ID: <CY4PR18MB098466FC688E05F3175C78FF83E50@CY4PR18MB0984.namprd18.prod.outlook.com>

Prasanta,

Couldn't getRootFrame().getComponentOrientation() thow a null pointer?  The case that always burned me was is showing a dialog from a minimized internal frame.  JInternalFrame is actually two components and when the minimized icon is showing the JInternalFrame doesn't have a parent.

Jason
________________________________________
From: swing-dev <swing-dev-bounces at openjdk.java.net> on behalf of Semyon Sadetsky <semyon.sadetsky at oracle.com>
Sent: Friday, May 19, 2017 8:55 AM
To: Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException

Looks good.

--Semyon

On 05/18/2017 11:07 PM, Prasanta Sadhukhan wrote:

Please find the modified webrev

http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.04/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.04/>

Regards
Prasanta
On 5/18/2017 8:44 PM, Semyon Sadetsky wrote:

This version of the fix formally corresponds to the spec. (I did not check the spec for validity.)

        if (parentComponent == null)
            return false;
        if (parentComponent instanceof Frame)
            return true;
        return JOptionPane.checkFrameForComponent(parentComponent.getParent());

- "JOptionPane." is not necessary.

- Please, add braces to the both if conditions.

        if (parentComponent == null || !(checkFrameForComponent(parentComponent))) {

- "parentComponent == null" is not necessary now

- to avoid extra "not" operation the if statement could be inverted.

--Semyon

On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:

Not sure about the exact meaning of that but anyways tried to make the code spec-compliant.

http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.03/>

If you think it still does not adhere to spec, please suggest what more needs to be done.

Regards
Prasanta
On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:

It seems, !(parentComponent instanceof Frame)) is not what the spec means.

--Semyon

On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
Ok, sorry. Updated code to get the default Frame when component has no Frame and
testcase to test that case too.
Updated webrev
http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.02/>

Regards
Prasanta
On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:

Yes, sorry. I meant the case I've mentioned in my first comment : when the component has no frame.

parentComponent determines the <code>Frame</code>
*          in which the dialog is displayed; if <code>null</code>,
*          or if the <code>parentComponent</code> has no
*          <code>Frame</code>***, a default <code>Frame</code> is used

--Semyon

On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:

Not sure which testcase you are running. I do not see this exception when I run my testcase in the webrev.

I am using createDialog in the fix for null parentComponent and not createInternalFrame() which throws this exception.

Regards
Prasanta
On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:

I don't see how this change fixes the issue.

I still got

Exception in thread "main" java.lang.RuntimeException: JOptionPane: parentComponent does not have a valid parent

after applying it.

--Semyon

On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:

Updated webrev to use getRootFrame() via createDialog() to get the default Frame when a frame is not provided.

http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.01/>

Regards
Prasanta
On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:

Also the spec says to use the default frame but the fix creates new frame each time.

On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:

The fix covers the parentComponent=null case.

What about the second case when non-null component is provided but it has no frame?

--Semyon

On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review a spec violation issue whereby if in JOptionPane.showInternalConfirmDialog(Component parentComponent, Object message)
"parentComponent" is null, we are getting RuntimeException "parentComponent does not have a valid parent"

but as per spec, https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
it says "parentComponent - determines the Frame in which the dialog is displayed; if null, or if the parentComponent has no Frame, a default Frame is used"

This violation exists for all overridden showInternalConfirmDialog methods and showInternalOptionDialog.

The proposed fix creates a default JFrame and shows the confirm dialog in it, as stated in the spec.

Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.00/>

Regards
Prasanta














From prasanta.sadhukhan at oracle.com  Sat May 20 04:35:08 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 20 May 2017 10:05:08 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <CY4PR18MB098466FC688E05F3175C78FF83E50@CY4PR18MB0984.namprd18.prod.outlook.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
 <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
 <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>
 <26bc0b4c-a8bc-2f02-b66e-2608456c829d@oracle.com>
 <CY4PR18MB098466FC688E05F3175C78FF83E50@CY4PR18MB0984.namprd18.prod.outlook.com>
Message-ID: <c9cd0049-54c1-2426-9586-12b689c86076@oracle.com>

AFAIS, getComponentOrientation() will return 
ComponentOrientation.UNKNOWN and not null so I guess we are covered there.

Regards
Prasanta
On 5/20/2017 2:46 AM, Jason Mehrens wrote:
> Prasanta,
>
> Couldn't getRootFrame().getComponentOrientation() thow a null pointer?  The case that always burned me was is showing a dialog from a minimized internal frame.  JInternalFrame is actually two components and when the minimized icon is showing the JInternalFrame doesn't have a parent.
>
> Jason
> ________________________________________
> From: swing-dev <swing-dev-bounces at openjdk.java.net> on behalf of Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Sent: Friday, May 19, 2017 8:55 AM
> To: Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
>
> Looks good.
>
> --Semyon
>
> On 05/18/2017 11:07 PM, Prasanta Sadhukhan wrote:
>
> Please find the modified webrev
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.04/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.04/>
>
> Regards
> Prasanta
> On 5/18/2017 8:44 PM, Semyon Sadetsky wrote:
>
> This version of the fix formally corresponds to the spec. (I did not check the spec for validity.)
>
>          if (parentComponent == null)
>              return false;
>          if (parentComponent instanceof Frame)
>              return true;
>          return JOptionPane.checkFrameForComponent(parentComponent.getParent());
>
> - "JOptionPane." is not necessary.
>
> - Please, add braces to the both if conditions.
>
>          if (parentComponent == null || !(checkFrameForComponent(parentComponent))) {
>
> - "parentComponent == null" is not necessary now
>
> - to avoid extra "not" operation the if statement could be inverted.
>
> --Semyon
>
> On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:
>
> Not sure about the exact meaning of that but anyways tried to make the code spec-compliant.
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.03/>
>
> If you think it still does not adhere to spec, please suggest what more needs to be done.
>
> Regards
> Prasanta
> On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>
> It seems, !(parentComponent instanceof Frame)) is not what the spec means.
>
> --Semyon
>
> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
> Ok, sorry. Updated code to get the default Frame when component has no Frame and
> testcase to test that case too.
> Updated webrev
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.02/>
>
> Regards
> Prasanta
> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>
> Yes, sorry. I meant the case I've mentioned in my first comment : when the component has no frame.
>
> parentComponent determines the <code>Frame</code>
> *          in which the dialog is displayed; if <code>null</code>,
> *          or if the <code>parentComponent</code> has no
> *          <code>Frame</code>***, a default <code>Frame</code> is used
>
> --Semyon
>
> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>
> Not sure which testcase you are running. I do not see this exception when I run my testcase in the webrev.
>
> I am using createDialog in the fix for null parentComponent and not createInternalFrame() which throws this exception.
>
> Regards
> Prasanta
> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>
> I don't see how this change fixes the issue.
>
> I still got
>
> Exception in thread "main" java.lang.RuntimeException: JOptionPane: parentComponent does not have a valid parent
>
> after applying it.
>
> --Semyon
>
> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>
> Updated webrev to use getRootFrame() via createDialog() to get the default Frame when a frame is not provided.
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.01/>
>
> Regards
> Prasanta
> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>
> Also the spec says to use the default frame but the fix creates new frame each time.
>
> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>
> The fix covers the parentComponent=null case.
>
> What about the second case when non-null component is provided but it has no frame?
>
> --Semyon
>
> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>
> Hi All,
>
> Please review a spec violation issue whereby if in JOptionPane.showInternalConfirmDialog(Component parentComponent, Object message)
> "parentComponent" is null, we are getting RuntimeException "parentComponent does not have a valid parent"
>
> but as per spec, https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
> it says "parentComponent - determines the Frame in which the dialog is displayed; if null, or if the parentComponent has no Frame, a default Frame is used"
>
> This violation exists for all overridden showInternalConfirmDialog methods and showInternalOptionDialog.
>
> The proposed fix creates a default JFrame and shows the confirm dialog in it, as stated in the spec.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.00/>
>
> Regards
> Prasanta
>
>
>
>
>
>
>
>
>
>
>
>



From avik.niyogi at oracle.com  Mon May 22 05:32:41 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 22 May 2017 11:02:41 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
	javax.swing.JOptionPane.showInternalConfirmDialog throws
	RuntimeException
In-Reply-To: <1b4b9329-66fc-0b8b-8735-bfa299480e42@oracle.com>
References: <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <1b4b9329-66fc-0b8b-8735-bfa299480e42@oracle.com>
Message-ID: <556C921A-7DC1-43AF-B5CE-10A56E21FAD6@oracle.com>

Hi,
The fix looks good to me.
With Regards,
Avik Niyogi
> 
> Subject:	Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
> Date:	Mon, 15 May 2017 15:44:17 +0530
> From:	Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> <mailto:prasanta.sadhukhan at oracle.com>
> Organization:	Oracle Corporation
> To:	Semyon Sadetsky <semyon.sadetsky at oracle.com> <mailto:semyon.sadetsky at oracle.com>, swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net> <swing-dev at openjdk.java.net> <mailto:swing-dev at openjdk.java.net>
> 
> Updated webrev to use getRootFrame() via createDialog() to get the default Frame when a frame is not provided.
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/ <http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.01/>
> 
> Regards
> Prasanta
> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>> Also the spec says to use the default frame but the fix creates new frame each time. 
>> 
>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>> The fix covers the parentComponent=null case.
>>> What about the second case when non-null component is provided but it has no frame?
>>> 
>>> --Semyon
>>> 
>>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>> 
>>>> Please review a spec violation issue whereby if in JOptionPane.showInternalConfirmDialog(Component parentComponent, Object message)
>>>> "parentComponent" is null, we are getting RuntimeException "parentComponent does not have a valid parent"
>>>> 
>>>> but as per spec, https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html <https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html>
>>>> it says "parentComponent - determines the Frame in which the dialog is displayed; if null, or if the parentComponent has no Frame, a default Frame is used"
>>>> 
>>>> This violation exists for all overridden showInternalConfirmDialog methods and showInternalOptionDialog.
>>>> 
>>>> The proposed fix creates a default JFrame and shows the confirm dialog in it, as stated in the spec.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497 <https://bugs.openjdk.java.net/browse/JDK-7042497>
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.00/>
>>>> 
>>>> Regards
>>>> Prasanta
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170522/9e19a635/attachment.html>

From jason_mehrens at hotmail.com  Mon May 22 14:02:58 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 22 May 2017 14:02:58 +0000
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <c9cd0049-54c1-2426-9586-12b689c86076@oracle.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
 <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
 <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>
 <26bc0b4c-a8bc-2f02-b66e-2608456c829d@oracle.com>
 <CY4PR18MB098466FC688E05F3175C78FF83E50@CY4PR18MB0984.namprd18.prod.outlook.com>,
 <c9cd0049-54c1-2426-9586-12b689c86076@oracle.com>
Message-ID: <CY4PR18MB0984383C0E276E84C72E372183F80@CY4PR18MB0984.namprd18.prod.outlook.com>

What I mean is getRootFrame() can return null.  Scan the rest of the source and notice the rest of the class handles that.
________________________________________
From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
Sent: Friday, May 19, 2017 11:35 PM
To: Jason Mehrens; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException

AFAIS, getComponentOrientation() will return
ComponentOrientation.UNKNOWN and not null so I guess we are covered there.

Regards
Prasanta
On 5/20/2017 2:46 AM, Jason Mehrens wrote:
> Prasanta,
>
> Couldn't getRootFrame().getComponentOrientation() thow a null pointer?  The case that always burned me was is showing a dialog from a minimized internal frame.  JInternalFrame is actually two components and when the minimized icon is showing the JInternalFrame doesn't have a parent.
>
> Jason
> ________________________________________
> From: swing-dev <swing-dev-bounces at openjdk.java.net> on behalf of Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Sent: Friday, May 19, 2017 8:55 AM
> To: Prasanta Sadhukhan; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
>
> Looks good.
>
> --Semyon
>
> On 05/18/2017 11:07 PM, Prasanta Sadhukhan wrote:
>
> Please find the modified webrev
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.04/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.04/>
>
> Regards
> Prasanta
> On 5/18/2017 8:44 PM, Semyon Sadetsky wrote:
>
> This version of the fix formally corresponds to the spec. (I did not check the spec for validity.)
>
>          if (parentComponent == null)
>              return false;
>          if (parentComponent instanceof Frame)
>              return true;
>          return JOptionPane.checkFrameForComponent(parentComponent.getParent());
>
> - "JOptionPane." is not necessary.
>
> - Please, add braces to the both if conditions.
>
>          if (parentComponent == null || !(checkFrameForComponent(parentComponent))) {
>
> - "parentComponent == null" is not necessary now
>
> - to avoid extra "not" operation the if statement could be inverted.
>
> --Semyon
>
> On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:
>
> Not sure about the exact meaning of that but anyways tried to make the code spec-compliant.
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.03/>
>
> If you think it still does not adhere to spec, please suggest what more needs to be done.
>
> Regards
> Prasanta
> On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>
> It seems, !(parentComponent instanceof Frame)) is not what the spec means.
>
> --Semyon
>
> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
> Ok, sorry. Updated code to get the default Frame when component has no Frame and
> testcase to test that case too.
> Updated webrev
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.02/>
>
> Regards
> Prasanta
> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>
> Yes, sorry. I meant the case I've mentioned in my first comment : when the component has no frame.
>
> parentComponent determines the <code>Frame</code>
> *          in which the dialog is displayed; if <code>null</code>,
> *          or if the <code>parentComponent</code> has no
> *          <code>Frame</code>***, a default <code>Frame</code> is used
>
> --Semyon
>
> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>
> Not sure which testcase you are running. I do not see this exception when I run my testcase in the webrev.
>
> I am using createDialog in the fix for null parentComponent and not createInternalFrame() which throws this exception.
>
> Regards
> Prasanta
> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>
> I don't see how this change fixes the issue.
>
> I still got
>
> Exception in thread "main" java.lang.RuntimeException: JOptionPane: parentComponent does not have a valid parent
>
> after applying it.
>
> --Semyon
>
> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>
> Updated webrev to use getRootFrame() via createDialog() to get the default Frame when a frame is not provided.
>
> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.01/>
>
> Regards
> Prasanta
> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>
> Also the spec says to use the default frame but the fix creates new frame each time.
>
> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>
> The fix covers the parentComponent=null case.
>
> What about the second case when non-null component is provided but it has no frame?
>
> --Semyon
>
> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>
> Hi All,
>
> Please review a spec violation issue whereby if in JOptionPane.showInternalConfirmDialog(Component parentComponent, Object message)
> "parentComponent" is null, we are getting RuntimeException "parentComponent does not have a valid parent"
>
> but as per spec, https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
> it says "parentComponent - determines the Frame in which the dialog is displayed; if null, or if the parentComponent has no Frame, a default Frame is used"
>
> This violation exists for all overridden showInternalConfirmDialog methods and showInternalOptionDialog.
>
> The proposed fix creates a default JFrame and shows the confirm dialog in it, as stated in the spec.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.00/>
>
> Regards
> Prasanta
>
>
>
>
>
>
>
>
>
>
>
>



From prasanta.sadhukhan at oracle.com  Tue May 23 06:41:28 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 23 May 2017 12:11:28 +0530
Subject: <Swing Dev> [10] RFR JDK-7042497:
 javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
In-Reply-To: <CY4PR18MB0984383C0E276E84C72E372183F80@CY4PR18MB0984.namprd18.prod.outlook.com>
References: <ba1c5b09-6a54-7c8a-9338-500262e081bb@oracle.com>
 <65e0a26f-db9b-735a-d52e-284f15e60abe@oracle.com>
 <4c07ec59-fa8e-0549-d815-3db6aeb3af99@oracle.com>
 <c9c8cf6b-4030-6426-313e-bfb3790ad14c@oracle.com>
 <7ba29b9d-3533-b7d1-625e-7059bc68eb70@oracle.com>
 <cda0c73a-c8ca-e915-d798-8af28bb1b214@oracle.com>
 <a1efbd5c-c48b-c867-65b8-51bd9f5edce3@oracle.com>
 <0f9b7bd7-8705-b9a6-6ee8-d7d4154b196f@oracle.com>
 <982a8e07-7f1d-3902-a6b4-4284456b069f@oracle.com>
 <68147697-046a-1db5-c954-af6e2063b643@oracle.com>
 <cd78596b-8fdc-ca25-6361-04c0472e1a10@oracle.com>
 <7f9b15dc-cf19-3a9b-23dd-f80dc66a5670@oracle.com>
 <26bc0b4c-a8bc-2f02-b66e-2608456c829d@oracle.com>
 <CY4PR18MB098466FC688E05F3175C78FF83E50@CY4PR18MB0984.namprd18.prod.outlook.com>
 <c9cd0049-54c1-2426-9586-12b689c86076@oracle.com>
 <CY4PR18MB0984383C0E276E84C72E372183F80@CY4PR18MB0984.namprd18.prod.outlook.com>
Message-ID: <2b9ea95a-fbc7-f606-3318-221e37aaf606@oracle.com>

I do not see getRootFrame() returning null . It calls 
getSharedOwnerFrame() which instantiates a shared owner frame. In other 
instances of getRootFrame() invocation also in showInputDialog() , 
showOptionDialog
we have
pane.setComponentOrientation(((parentComponent == null) ?
             getRootFrame() : parentComponent).getComponentOrientation());
where it does not check for getRootFrame() returning null.

Regards
Prasanta
On 5/22/2017 7:32 PM, Jason Mehrens wrote:
> What I mean is getRootFrame() can return null.  Scan the rest of the source and notice the rest of the class handles that.
> ________________________________________
> From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
> Sent: Friday, May 19, 2017 11:35 PM
> To: Jason Mehrens; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
>
> AFAIS, getComponentOrientation() will return
> ComponentOrientation.UNKNOWN and not null so I guess we are covered there.
>
> Regards
> Prasanta
> On 5/20/2017 2:46 AM, Jason Mehrens wrote:
>> Prasanta,
>>
>> Couldn't getRootFrame().getComponentOrientation() thow a null pointer?  The case that always burned me was is showing a dialog from a minimized internal frame.  JInternalFrame is actually two components and when the minimized icon is showing the JInternalFrame doesn't have a parent.
>>
>> Jason
>> ________________________________________
>> From: swing-dev <swing-dev-bounces at openjdk.java.net> on behalf of Semyon Sadetsky <semyon.sadetsky at oracle.com>
>> Sent: Friday, May 19, 2017 8:55 AM
>> To: Prasanta Sadhukhan; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10] RFR JDK-7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException
>>
>> Looks good.
>>
>> --Semyon
>>
>> On 05/18/2017 11:07 PM, Prasanta Sadhukhan wrote:
>>
>> Please find the modified webrev
>>
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.04/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.04/>
>>
>> Regards
>> Prasanta
>> On 5/18/2017 8:44 PM, Semyon Sadetsky wrote:
>>
>> This version of the fix formally corresponds to the spec. (I did not check the spec for validity.)
>>
>>           if (parentComponent == null)
>>               return false;
>>           if (parentComponent instanceof Frame)
>>               return true;
>>           return JOptionPane.checkFrameForComponent(parentComponent.getParent());
>>
>> - "JOptionPane." is not necessary.
>>
>> - Please, add braces to the both if conditions.
>>
>>           if (parentComponent == null || !(checkFrameForComponent(parentComponent))) {
>>
>> - "parentComponent == null" is not necessary now
>>
>> - to avoid extra "not" operation the if statement could be inverted.
>>
>> --Semyon
>>
>> On 05/18/2017 12:01 AM, Prasanta Sadhukhan wrote:
>>
>> Not sure about the exact meaning of that but anyways tried to make the code spec-compliant.
>>
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.03/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.03/>
>>
>> If you think it still does not adhere to spec, please suggest what more needs to be done.
>>
>> Regards
>> Prasanta
>> On 5/17/2017 8:23 PM, Semyon Sadetsky wrote:
>>
>> It seems, !(parentComponent instanceof Frame)) is not what the spec means.
>>
>> --Semyon
>>
>> On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
>> Ok, sorry. Updated code to get the default Frame when component has no Frame and
>> testcase to test that case too.
>> Updated webrev
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.02/>
>>
>> Regards
>> Prasanta
>> On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
>>
>> Yes, sorry. I meant the case I've mentioned in my first comment : when the component has no frame.
>>
>> parentComponent determines the <code>Frame</code>
>> *          in which the dialog is displayed; if <code>null</code>,
>> *          or if the <code>parentComponent</code> has no
>> *          <code>Frame</code>***, a default <code>Frame</code> is used
>>
>> --Semyon
>>
>> On 05/15/2017 10:44 PM, Prasanta Sadhukhan wrote:
>>
>> Not sure which testcase you are running. I do not see this exception when I run my testcase in the webrev.
>>
>> I am using createDialog in the fix for null parentComponent and not createInternalFrame() which throws this exception.
>>
>> Regards
>> Prasanta
>> On 5/15/2017 11:04 PM, Semyon Sadetsky wrote:
>>
>> I don't see how this change fixes the issue.
>>
>> I still got
>>
>> Exception in thread "main" java.lang.RuntimeException: JOptionPane: parentComponent does not have a valid parent
>>
>> after applying it.
>>
>> --Semyon
>>
>> On 05/15/2017 03:14 AM, Prasanta Sadhukhan wrote:
>>
>> Updated webrev to use getRootFrame() via createDialog() to get the default Frame when a frame is not provided.
>>
>> http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.01/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.01/>
>>
>> Regards
>> Prasanta
>> On 5/12/2017 8:08 PM, Semyon Sadetsky wrote:
>>
>> Also the spec says to use the default frame but the fix creates new frame each time.
>>
>> On 05/12/2017 07:32 AM, Semyon Sadetsky wrote:
>>
>> The fix covers the parentComponent=null case.
>>
>> What about the second case when non-null component is provided but it has no frame?
>>
>> --Semyon
>>
>> On 05/12/2017 12:51 AM, Prasanta Sadhukhan wrote:
>>
>> Hi All,
>>
>> Please review a spec violation issue whereby if in JOptionPane.showInternalConfirmDialog(Component parentComponent, Object message)
>> "parentComponent" is null, we are getting RuntimeException "parentComponent does not have a valid parent"
>>
>> but as per spec, https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/JOptionPane.html
>> it says "parentComponent - determines the Frame in which the dialog is displayed; if null, or if the parentComponent has no Frame, a default Frame is used"
>>
>> This violation exists for all overridden showInternalConfirmDialog methods and showInternalOptionDialog.
>>
>> The proposed fix creates a default JFrame and shows the confirm dialog in it, as stated in the spec.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7042497
>> webrev: http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.00/<http://cr.openjdk.java.net/%7Epsadhukhan/7042497/webrev.00/>
>>
>> Regards
>> Prasanta
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>



From prasanta.sadhukhan at oracle.com  Tue May 23 08:52:32 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 23 May 2017 14:22:32 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
Message-ID: <8c702c25-a5f6-93de-b907-7493acbe0d69@oracle.com>

Hi ALl,

Please review a testbug fix for an issue where this regression test is 
failing in linux because
JFileChooser was trying to access C:/temp path which does not exist in 
linux.

Proposed fix is to use java.io.tmpdir instead of hardcoded windows path.

Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/

Regards
Prasanta


From prasanta.sadhukhan at oracle.com  Tue May 23 08:59:16 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 23 May 2017 14:29:16 +0530
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
 classes included with Unix JDKs
In-Reply-To: <21fb6605-e4d3-657c-766c-0a93cd15f721@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
 <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>
 <21fb6605-e4d3-657c-766c-0a93cd15f721@oracle.com>
Message-ID: <2f126747-6659-813a-f006-a6d5433912e2@oracle.com>

I got +1 from build. I need one more +1.

Any further comment/objection on this changeset? else Can I commit this?

Regards
Prasanta
On 5/18/2017 1:31 PM, Prasanta Sadhukhan wrote:
> So far I have looked, it seems jdk.jconsole uses this classes for 
> windows only. These classes are specified in
> JConsole.java where it checks (for non-windows, it will come as 
> GTKLookAndFeel)
>
> String systemLaF = UIManager.getSystemLookAndFeelClassName();
> if (systemLaF.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") ||
> systemLaF.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) {
>
> try {
> UIManager.setLookAndFeel(systemLaF); MaximizableInternalFrame.java 
> where it checks for this classes in windows only if (JConsole.IS_WIN) {
> try {
> Class<?> Part =
> Class.forName("com.sun.java.swing.plaf.windows.TMSchema$Part"); and 
> Utilities.java where it checks LookAndFeel laf = 
> UIManager.getLookAndFeel();
> boolean transparent = laf.getClass().getName().equals(windowsLaF);
>
> Modified webrev
> http://cr.openjdk.java.net/~psadhukhan/6461834/01/
>
> Regards
> Prasanta
>
> On 5/18/2017 12:36 AM, Phil Race wrote:
>> The way to do this is to create a file
>> src/java.desktop/windows/classes/module-info.java.extra
>>
>> and move the opens there.
>>
>> See for example
>> src/java.base/windows/classes/module-info.java.extra
>>
>> But are you sure jdk.jconsole needs these only on Windows ?
>> Better make sure of it.
>>
>> -phil.
>>
>> On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
>>> Yes, actually I am bit unsure of how to proceed with that. It is 
>>> meant to open internal java.desktop classes "only" to jdk.jconsole 
>>> but now afer this fix, these classes will only be available in 
>>> windows platform, so it should be a conditional "open" and I am not 
>>> sure if module-info.java allows conditional open.
>>>
>>> Regards
>>> Prasanta
>>> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>>>> Build changes looks good. However in 
>>>> src/java.desktop/share/classes/module-info.java you are trying to 
>>>> check in commented-out code instead of removing it.
>>>>
>>>> /Magnus
>>>>
>>>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue whereby it is seen that 
>>>>> WindowsLookAndFeel classes are built for non-windows platform,
>>>>> where it is not needed.
>>>>> Proposed fix is to remove building these classes for non-windows 
>>>>> platform.
>>>>>
>>>>> JPRT build is successful. Also, fixed the regression tests which 
>>>>> expects this classes to be available in non-unix platform.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>>>
>>>>> There are some closed regression test which will be taken care 
>>>>> after this in a separate crucible review.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>
>>
>



From sergey.bylokhov at oracle.com  Wed May 24 06:18:57 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 May 2017 23:18:57 -0700
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <8c702c25-a5f6-93de-b907-7493acbe0d69@oracle.com>
References: <8c702c25-a5f6-93de-b907-7493acbe0d69@oracle.com>
Message-ID: <55427F1B-F076-4F12-A047-D438B7C62877@oracle.com>

Hi, Prasanta.
Please confirm that the updated test fails before JDK-6738668 was fixed.

> 
> Hi ALl,
> 
> Please review a testbug fix for an issue where this regression test is failing in linux because
> JFileChooser was trying to access C:/temp path which does not exist in linux.
> 
> Proposed fix is to use java.io.tmpdir instead of hardcoded windows path.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
> webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
> 
> Regards
> Prasanta



From prasanta.sadhukhan at oracle.com  Wed May 24 06:30:17 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 24 May 2017 12:00:17 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <55427F1B-F076-4F12-A047-D438B7C62877@oracle.com>
References: <8c702c25-a5f6-93de-b907-7493acbe0d69@oracle.com>
 <55427F1B-F076-4F12-A047-D438B7C62877@oracle.com>
Message-ID: <78e450b6-88a6-7b7d-375c-78656c34da96@oracle.com>

Hi Sergey,

No, it is passing. Actually, the original test is also passing with 
1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no 
SecurityException

jdk1.7.0/bin/java -Djava.security.policy=security.policy bug6738668
Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
Test passed for LookAndFeel com.sun.java.swing.plaf.motif.MotifLookAndFeel
Test passed for LookAndFeel 
com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Test passed for LookAndFeel 
com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel

jdk1.7.0/bin/java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)

Regards
Prasanta
On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Please confirm that the updated test fails before JDK-6738668 was fixed.
>
>> Hi ALl,
>>
>> Please review a testbug fix for an issue where this regression test is failing in linux because
>> JFileChooser was trying to access C:/temp path which does not exist in linux.
>>
>> Proposed fix is to use java.io.tmpdir instead of hardcoded windows path.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>> webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>
>> Regards
>> Prasanta



From prasanta.sadhukhan at oracle.com  Wed May 24 09:59:22 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 24 May 2017 15:29:22 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case failed
 as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <ccbc0872-b251-24d8-34fa-7bde640dac59@oracle.com>

Hi All,

Please review a fix for an issue where long Tab titiles are not clipped 
with dots at end for NimbusLookAndFeel L&F.
Other L&Fs works ok.

Issue was in SynthTabbedPaneUI#paintTab(), the title is not clipped but 
passed to paintText() as it is received.
Other L&F such as Metal, Motif, Windows which uses 
BasicTabbedPaneUI#paintTab(), the title is clipped
http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
before it is passed to paintText().

Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().

Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
webrev: http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/

Regards
Prasanta


From sergey.bylokhov at oracle.com  Wed May 24 21:00:36 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 24 May 2017 14:00:36 -0700 (PDT)
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
Message-ID: <df0c6e06-6547-4bf0-9dc7-89978397c0a9@default>

I am not sure but according to the comments of JDK-6738668 it was a regression in 7b20.
So I suggest to check a few build between b20 and b54

----- prasanta.sadhukhan at oracle.com wrote:

> Hi Sergey,
> 
> No, it is passing. Actually, the original test is also passing with 
> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no 
> SecurityException
> 
> jdk1.7.0/bin/java -Djava.security.policy=security.policy bug6738668
> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
> Test passed for LookAndFeel
> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Test passed for LookAndFeel 
> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test passed for LookAndFeel 
> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> 
> jdk1.7.0/bin/java -version
> java version "1.7.0-ea"
> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)
> 
> Regards
> Prasanta
> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
> > Hi, Prasanta.
> > Please confirm that the updated test fails before JDK-6738668 was
> fixed.
> >
> >> Hi ALl,
> >>
> >> Please review a testbug fix for an issue where this regression test
> is failing in linux because
> >> JFileChooser was trying to access C:/temp path which does not exist
> in linux.
> >>
> >> Proposed fix is to use java.io.tmpdir instead of hardcoded windows
> path.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
> >> webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
> >>
> >> Regards
> >> Prasanta


From sergey.bylokhov at oracle.com  Wed May 24 21:41:32 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 24 May 2017 14:41:32 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <816ffee8-8c20-4bf0-9ad3-e219434c5150@default>

Hi, Prasanta.
Please take a look to my comments at:
http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html

The two methods paintText() and paintIcon() are contradict the spec and draw the text and icons outside of the tab.  

----- prasanta.sadhukhan at oracle.com wrote:

> Hi All,
> 
> Please review a fix for an issue where long Tab titiles are not
> clipped 
> with dots at end for NimbusLookAndFeel L&F.
> Other L&Fs works ok.
> 
> Issue was in SynthTabbedPaneUI#paintTab(), the title is not clipped
> but 
> passed to paintText() as it is received.
> Other L&F such as Metal, Motif, Windows which uses 
> BasicTabbedPaneUI#paintTab(), the title is clipped
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
> before it is passed to paintText().
> 
> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
> webrev: http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
> 
> Regards
> Prasanta


From prasanta.sadhukhan at oracle.com  Thu May 25 05:54:19 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 25 May 2017 11:24:19 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <df0c6e06-6547-4bf0-9dc7-89978397c0a9@default>
References: <df0c6e06-6547-4bf0-9dc7-89978397c0a9@default>
Message-ID: <fc0286c3-64a2-858d-6148-bc187f7db9d0@oracle.com>

Hi Sergey,

I do not see any comment mention about failure in 7b20 but anyways, I 
tried with 7b20,7b30,7b40,7b50 and all of them passed with original and 
updated test in windows.

Regards
Prasanta
On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
> I am not sure but according to the comments of JDK-6738668 it was a regression in 7b20.
> So I suggest to check a few build between b20 and b54
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi Sergey,
>>
>> No, it is passing. Actually, the original test is also passing with
>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>> SecurityException
>>
>> jdk1.7.0/bin/java -Djava.security.policy=security.policy bug6738668
>> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>
>> jdk1.7.0/bin/java -version
>> java version "1.7.0-ea"
>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)
>>
>> Regards
>> Prasanta
>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Please confirm that the updated test fails before JDK-6738668 was
>> fixed.
>>>> Hi ALl,
>>>>
>>>> Please review a testbug fix for an issue where this regression test
>> is failing in linux because
>>>> JFileChooser was trying to access C:/temp path which does not exist
>> in linux.
>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded windows
>> path.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Thu May 25 08:20:54 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 25 May 2017 13:50:54 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <816ffee8-8c20-4bf0-9ad3-e219434c5150@default>
References: <816ffee8-8c20-4bf0-9ad3-e219434c5150@default>
Message-ID: <8595518e-d250-6bcf-1bc2-66c80a30e653@oracle.com>

Hi Sergey,

I could get your concern for paintText() but could not find paintIcon() 
in SynthGraphicsUtils() so not sure how icon drawing contradicts spec.
Modified webrev:
http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/

Also, if we are not calling SwingUtilities2.clipStringIfNecessary() then 
we are not going to get "..." at the end which this test expects. But I 
could not find anything in spec, that mandates ending with "..." for 
long tab outside
tab bounds. If source change is ok, I guess we then need to modify the 
html file modifying the expected result for NimbusL&F.

Regards
Prasanta
On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Please take a look to my comments at:
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>
> The two methods paintText() and paintIcon() are contradict the spec and draw the text and icons outside of the tab.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi All,
>>
>> Please review a fix for an issue where long Tab titiles are not
>> clipped
>> with dots at end for NimbusLookAndFeel L&F.
>> Other L&Fs works ok.
>>
>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not clipped
>> but
>> passed to paintText() as it is received.
>> Other L&F such as Metal, Motif, Windows which uses
>> BasicTabbedPaneUI#paintTab(), the title is clipped
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>> before it is passed to paintText().
>>
>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>
>> Regards
>> Prasanta



From sergey.bylokhov at oracle.com  Fri May 26 01:04:55 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 25 May 2017 18:04:55 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <fca7b6ed-e3f6-4808-a72d-adfa324b95ea@default>

I suggest to check how in this case works the Nimbus on the Solaris 11(This is not a Swing L&F, but a GTK l&f). Does it have a dots at the end of tab?

----- prasanta.sadhukhan at oracle.com wrote:

> Hi Sergey,
> 
> I could get your concern for paintText() but could not find
> paintIcon() 
> in SynthGraphicsUtils() so not sure how icon drawing contradicts
> spec.
> Modified webrev:
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
> 
> Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
> then 
> we are not going to get "..." at the end which this test expects. But
> I 
> could not find anything in spec, that mandates ending with "..." for 
> long tab outside
> tab bounds. If source change is ok, I guess we then need to modify the
> 
> html file modifying the expected result for NimbusL&F.
> 
> Regards
> Prasanta
> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
> > Hi, Prasanta.
> > Please take a look to my comments at:
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
> >
> > The two methods paintText() and paintIcon() are contradict the spec
> and draw the text and icons outside of the tab.
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> Hi All,
> >>
> >> Please review a fix for an issue where long Tab titiles are not
> >> clipped
> >> with dots at end for NimbusLookAndFeel L&F.
> >> Other L&Fs works ok.
> >>
> >> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
> clipped
> >> but
> >> passed to paintText() as it is received.
> >> Other L&F such as Metal, Motif, Windows which uses
> >> BasicTabbedPaneUI#paintTab(), the title is clipped
> >>
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
> >> before it is passed to paintText().
> >>
> >> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
> >>
> >> Regards
> >> Prasanta


From prasanta.sadhukhan at oracle.com  Fri May 26 04:21:38 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 26 May 2017 09:51:38 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <fca7b6ed-e3f6-4808-a72d-adfa324b95ea@default>
References: <fca7b6ed-e3f6-4808-a72d-adfa324b95ea@default>
Message-ID: <241db9f9-1121-e5df-8de0-c35d6c6b6abd@oracle.com>

Solaris 11.3 with gtk l&f has same problem as Nimbus, the text is not 
clipped.  Screenshot: 
http://cr.openjdk.java.net/~psadhukhan/8075918/solaris-gtk.png

Regards
Prasanta

On 5/26/2017 6:34 AM, Sergey Bylokhov wrote:

> I suggest to check how in this case works the Nimbus on the Solaris 11(This is not a Swing L&F, but a GTK l&f). Does it have a dots at the end of tab?
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi Sergey,
>>
>> I could get your concern for paintText() but could not find
>> paintIcon()
>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>> spec.
>> Modified webrev:
>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>
>> Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
>> then
>> we are not going to get "..." at the end which this test expects. But
>> I
>> could not find anything in spec, that mandates ending with "..." for
>> long tab outside
>> tab bounds. If source change is ok, I guess we then need to modify the
>>
>> html file modifying the expected result for NimbusL&F.
>>
>> Regards
>> Prasanta
>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Please take a look to my comments at:
>>>
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>> The two methods paintText() and paintIcon() are contradict the spec
>> and draw the text and icons outside of the tab.
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where long Tab titiles are not
>>>> clipped
>>>> with dots at end for NimbusLookAndFeel L&F.
>>>> Other L&Fs works ok.
>>>>
>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>> clipped
>>>> but
>>>> passed to paintText() as it is received.
>>>> Other L&F such as Metal, Motif, Windows which uses
>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>> before it is passed to paintText().
>>>>
>>>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Fri May 26 04:52:43 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 26 May 2017 10:22:43 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <fc0286c3-64a2-858d-6148-bc187f7db9d0@oracle.com>
References: <df0c6e06-6547-4bf0-9dc7-89978397c0a9@default>
 <fc0286c3-64a2-858d-6148-bc187f7db9d0@oracle.com>
Message-ID: <d39922e1-467c-80e9-3c69-d530c1c4cfe8@oracle.com>

What we should do with this test fix in linux?

Regards
Prasanta
On 5/25/2017 11:24 AM, Prasanta Sadhukhan wrote:
> Hi Sergey,
>
> I do not see any comment mention about failure in 7b20 but anyways, I 
> tried with 7b20,7b30,7b40,7b50 and all of them passed with original 
> and updated test in windows.
>
> Regards
> Prasanta
> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>> I am not sure but according to the comments of JDK-6738668 it was a 
>> regression in 7b20.
>> So I suggest to check a few build between b20 and b54
>>
>> ----- prasanta.sadhukhan at oracle.com wrote:
>>
>>> Hi Sergey,
>>>
>>> No, it is passing. Actually, the original test is also passing with
>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>> SecurityException
>>>
>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy bug6738668
>>> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
>>> Test passed for LookAndFeel
>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>> Test passed for LookAndFeel
>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>> Test passed for LookAndFeel
>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>
>>> jdk1.7.0/bin/java -version
>>> java version "1.7.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)
>>>
>>> Regards
>>> Prasanta
>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Please confirm that the updated test fails before JDK-6738668 was
>>> fixed.
>>>>> Hi ALl,
>>>>>
>>>>> Please review a testbug fix for an issue where this regression test
>>> is failing in linux because
>>>>> JFileChooser was trying to access C:/temp path which does not exist
>>> in linux.
>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded windows
>>> path.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>



From prasanta.sadhukhan at oracle.com  Fri May 26 04:54:54 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 26 May 2017 10:24:54 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <d39922e1-467c-80e9-3c69-d530c1c4cfe8@oracle.com>
References: <df0c6e06-6547-4bf0-9dc7-89978397c0a9@default>
 <fc0286c3-64a2-858d-6148-bc187f7db9d0@oracle.com>
 <d39922e1-467c-80e9-3c69-d530c1c4cfe8@oracle.com>
Message-ID: <24800945-facf-e09f-f35a-dc72f5d7b09d@oracle.com>

There is no changeset in JBS for  6738668 (probably because it was 
before mercurial era) which could have told us what was the fix.

On 5/26/2017 10:22 AM, Prasanta Sadhukhan wrote:
> What we should do with this test fix in linux?
>
> Regards
> Prasanta
> On 5/25/2017 11:24 AM, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> I do not see any comment mention about failure in 7b20 but anyways, I 
>> tried with 7b20,7b30,7b40,7b50 and all of them passed with original 
>> and updated test in windows.
>>
>> Regards
>> Prasanta
>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>>> I am not sure but according to the comments of JDK-6738668 it was a 
>>> regression in 7b20.
>>> So I suggest to check a few build between b20 and b54
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> No, it is passing. Actually, the original test is also passing with
>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>>> SecurityException
>>>>
>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy bug6738668
>>>> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>
>>>> jdk1.7.0/bin/java -version
>>>> java version "1.7.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Please confirm that the updated test fails before JDK-6738668 was
>>>> fixed.
>>>>>> Hi ALl,
>>>>>>
>>>>>> Please review a testbug fix for an issue where this regression test
>>>> is failing in linux because
>>>>>> JFileChooser was trying to access C:/temp path which does not exist
>>>> in linux.
>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded windows
>>>> path.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>
>



From avik.niyogi at oracle.com  Fri May 26 06:15:53 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Fri, 26 May 2017 11:45:53 +0530
Subject: <Swing Dev> [10] RFR JDK-6461834: Minimize WindowsLookAndFeel
	classes included with Unix JDKs
In-Reply-To: <mailman.17489.1495620049.26058.swing-dev@openjdk.java.net>
References: <mailman.17489.1495620049.26058.swing-dev@openjdk.java.net>
Message-ID: <F7DC77F1-9C07-4AF1-9FF8-A04373440D2A@oracle.com>

+1

> On 24-May-2017, at 3:30 pm, swing-dev-request at openjdk.java.net wrote:
> 
> Date: Tue, 23 May 2017 14:29:16 +0530
> From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>
> To: Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>, Magnus Ihse Bursie
> 	<magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>, build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>,
> 	"swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>" <swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>>
> Subject: Re: <Swing Dev> [10] RFR JDK-6461834: Minimize
> 	WindowsLookAndFeel classes included with Unix JDKs
> Message-ID: <2f126747-6659-813a-f006-a6d5433912e2 at oracle.com <mailto:2f126747-6659-813a-f006-a6d5433912e2 at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> I got +1 from build. I need one more +1.
> 
> Any further comment/objection on this changeset? else Can I commit this?
> 
> Regards
> Prasanta
> On 5/18/2017 1:31 PM, Prasanta Sadhukhan wrote:
>> So far I have looked, it seems jdk.jconsole uses this classes for 
>> windows only. These classes are specified in
>> JConsole.java where it checks (for non-windows, it will come as 
>> GTKLookAndFeel)
>> 
>> String systemLaF = UIManager.getSystemLookAndFeelClassName();
>> if (systemLaF.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") ||
>> systemLaF.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) {
>> 
>> try {
>> UIManager.setLookAndFeel(systemLaF); MaximizableInternalFrame.java 
>> where it checks for this classes in windows only if (JConsole.IS_WIN) {
>> try {
>> Class<?> Part =
>> Class.forName("com.sun.java.swing.plaf.windows.TMSchema$Part"); and 
>> Utilities.java where it checks LookAndFeel laf = 
>> UIManager.getLookAndFeel();
>> boolean transparent = laf.getClass().getName().equals(windowsLaF);
>> 
>> Modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/6461834/01/ <http://cr.openjdk.java.net/~psadhukhan/6461834/01/>
>> 
>> Regards
>> Prasanta
>> 
>> On 5/18/2017 12:36 AM, Phil Race wrote:
>>> The way to do this is to create a file
>>> src/java.desktop/windows/classes/module-info.java.extra
>>> 
>>> and move the opens there.
>>> 
>>> See for example
>>> src/java.base/windows/classes/module-info.java.extra
>>> 
>>> But are you sure jdk.jconsole needs these only on Windows ?
>>> Better make sure of it.
>>> 
>>> -phil.
>>> 
>>> On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
>>>> Yes, actually I am bit unsure of how to proceed with that. It is 
>>>> meant to open internal java.desktop classes "only" to jdk.jconsole 
>>>> but now afer this fix, these classes will only be available in 
>>>> windows platform, so it should be a conditional "open" and I am not 
>>>> sure if module-info.java allows conditional open.
>>>> 
>>>> Regards
>>>> Prasanta
>>>> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>>>>> Build changes looks good. However in 
>>>>> src/java.desktop/share/classes/module-info.java you are trying to 
>>>>> check in commented-out code instead of removing it.
>>>>> 
>>>>> /Magnus
>>>>> 
>>>>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Please review a fix for an issue whereby it is seen that 
>>>>>> WindowsLookAndFeel classes are built for non-windows platform,
>>>>>> where it is not needed.
>>>>>> Proposed fix is to remove building these classes for non-windows 
>>>>>> platform.
>>>>>> 
>>>>>> JPRT build is successful. Also, fixed the regression tests which 
>>>>>> expects this classes to be available in non-unix platform.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834 <https://bugs.openjdk.java.net/browse/JDK-6461834>
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/ <http://cr.openjdk.java.net/~psadhukhan/6461834/00/>
>>>>>> 
>>>>>> There are some closed regression test which will be taken care 
>>>>>> after this in a separate crucible review.
>>>>>> 
>>>>>> Regards
>>>>>> Prasanta
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170526/6eeca291/attachment.html>

From sergey.bylokhov at oracle.com  Fri May 26 18:48:28 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 26 May 2017 11:48:28 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <8a8741aa-7d57-4b34-8a47-b6e8eea887f5@default>

No, I meant the native applications on Solaris 11, not a java.
By default Solaris 11 uses Nimbus as a look and feel(or Theme) for its gtk applications(as an example take a look to the terminal window).

----- prasanta.sadhukhan at oracle.com wrote:

> Solaris 11.3 with gtk l&f has same problem as Nimbus, the text is not
> 
> clipped. Attached is the screenshot.
> 
> Regards
> Prasanta
> On 5/26/2017 6:34 AM, Sergey Bylokhov wrote:
> > I suggest to check how in this case works the Nimbus on the Solaris
> 11(This is not a Swing L&F, but a GTK l&f). Does it have a dots at the
> end of tab?
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> Hi Sergey,
> >>
> >> I could get your concern for paintText() but could not find
> >> paintIcon()
> >> in SynthGraphicsUtils() so not sure how icon drawing contradicts
> >> spec.
> >> Modified webrev:
> >> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
> >>
> >> Also, if we are not calling
> SwingUtilities2.clipStringIfNecessary()
> >> then
> >> we are not going to get "..." at the end which this test expects.
> But
> >> I
> >> could not find anything in spec, that mandates ending with "..."
> for
> >> long tab outside
> >> tab bounds. If source change is ok, I guess we then need to modify
> the
> >>
> >> html file modifying the expected result for NimbusL&F.
> >>
> >> Regards
> >> Prasanta
> >> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
> >>> Hi, Prasanta.
> >>> Please take a look to my comments at:
> >>>
> >>
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
> >>
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
> >>> The two methods paintText() and paintIcon() are contradict the
> spec
> >> and draw the text and icons outside of the tab.
> >>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> Please review a fix for an issue where long Tab titiles are not
> >>>> clipped
> >>>> with dots at end for NimbusLookAndFeel L&F.
> >>>> Other L&Fs works ok.
> >>>>
> >>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
> >> clipped
> >>>> but
> >>>> passed to paintText() as it is received.
> >>>> Other L&F such as Metal, Motif, Windows which uses
> >>>> BasicTabbedPaneUI#paintTab(), the title is clipped
> >>>>
> >>
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
> >>>> before it is passed to paintText().
> >>>>
> >>>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
> >>>> webrev:
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
> >>>>
> >>>> Regards
> >>>> Prasanta


From prasanta.sadhukhan at oracle.com  Sat May 27 07:37:51 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 27 May 2017 13:07:51 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <8a8741aa-7d57-4b34-8a47-b6e8eea887f5@default>
References: <8a8741aa-7d57-4b34-8a47-b6e8eea887f5@default>
Message-ID: <9d4911cc-0130-1d9b-e7fa-55b2319b9eba@oracle.com>

Ok. Solaris Terminal window title has ... at end for long tab. 
Screenshot : 
http://cr.openjdk.java.net/~psadhukhan/8075918/solaris-gtk-title.png

Modified webrev to be consistent with native app

http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.02/

Regards
Prasanta
On 5/27/2017 12:18 AM, Sergey Bylokhov wrote:
> No, I meant the native applications on Solaris 11, not a java.
> By default Solaris 11 uses Nimbus as a look and feel(or Theme) for its gtk applications(as an example take a look to the terminal window).
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Solaris 11.3 with gtk l&f has same problem as Nimbus, the text is not
>>
>> clipped. Attached is the screenshot.
>>
>> Regards
>> Prasanta
>> On 5/26/2017 6:34 AM, Sergey Bylokhov wrote:
>>> I suggest to check how in this case works the Nimbus on the Solaris
>> 11(This is not a Swing L&F, but a GTK l&f). Does it have a dots at the
>> end of tab?
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> I could get your concern for paintText() but could not find
>>>> paintIcon()
>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>> spec.
>>>> Modified webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>
>>>> Also, if we are not calling
>> SwingUtilities2.clipStringIfNecessary()
>>>> then
>>>> we are not going to get "..." at the end which this test expects.
>> But
>>>> I
>>>> could not find anything in spec, that mandates ending with "..."
>> for
>>>> long tab outside
>>>> tab bounds. If source change is ok, I guess we then need to modify
>> the
>>>> html file modifying the expected result for NimbusL&F.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Please take a look to my comments at:
>>>>>
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>> The two methods paintText() and paintIcon() are contradict the
>> spec
>>>> and draw the text and icons outside of the tab.
>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>> clipped
>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>> Other L&Fs works ok.
>>>>>>
>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>> clipped
>>>>>> but
>>>>>> passed to paintText() as it is received.
>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>> before it is passed to paintText().
>>>>>>
>>>>>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>> webrev:
>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>> Regards
>>>>>> Prasanta



From sergey.bylokhov at oracle.com  Sat May 27 22:40:37 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 27 May 2017 15:40:37 -0700 (PDT)
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
Message-ID: <61562b8a-ac72-49a0-af75-cd685c649373@default>

There is a comment that JDK-6738668 a regression of JDK-6484091 which was pushed to b20.
I just checked the test from the command line on b40 and it fails, but passed on b55.
Can you please check why it was passed in your case.

----- prasanta.sadhukhan at oracle.com wrote:

> Hi Sergey,
> 
> I do not see any comment mention about failure in 7b20 but anyways, I
> 
> tried with 7b20,7b30,7b40,7b50 and all of them passed with original
> and 
> updated test in windows.
> 
> Regards
> Prasanta
> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
> > I am not sure but according to the comments of JDK-6738668 it was a
> regression in 7b20.
> > So I suggest to check a few build between b20 and b54
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> Hi Sergey,
> >>
> >> No, it is passing. Actually, the original test is also passing
> with
> >> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
> >> SecurityException
> >>
> >> jdk1.7.0/bin/java -Djava.security.policy=security.policy
> bug6738668
> >> Test passed for LookAndFeel
> javax.swing.plaf.metal.MetalLookAndFeel
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>
> >> jdk1.7.0/bin/java -version
> >> java version "1.7.0-ea"
> >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
> >> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)
> >>
> >> Regards
> >> Prasanta
> >> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
> >>> Hi, Prasanta.
> >>> Please confirm that the updated test fails before JDK-6738668 was
> >> fixed.
> >>>> Hi ALl,
> >>>>
> >>>> Please review a testbug fix for an issue where this regression
> test
> >> is failing in linux because
> >>>> JFileChooser was trying to access C:/temp path which does not
> exist
> >> in linux.
> >>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
> windows
> >> path.
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
> >>>> webrev:
> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
> >>>>
> >>>> Regards
> >>>> Prasanta


From sergey.bylokhov at oracle.com  Sun May 28 00:33:01 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 27 May 2017 17:33:01 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <3aa6692b-2a7d-4830-bd64-24fa5601ab74@default>

Hi, Prasanta.

BasicTabbedPaneUI.paintIcon() as well as SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
 - paintText() at line 681
 - paintIcon() at line 634
Both methods have a rectangle as a parameter, but it is ignored.

----- prasanta.sadhukhan at oracle.com wrote:

> Hi Sergey,
> 
> I could get your concern for paintText() but could not find
> paintIcon() 
> in SynthGraphicsUtils() so not sure how icon drawing contradicts
> spec.
> Modified webrev:
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
> 
> Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
> then 
> we are not going to get "..." at the end which this test expects. But
> I 
> could not find anything in spec, that mandates ending with "..." for 
> long tab outside
> tab bounds. If source change is ok, I guess we then need to modify the
> 
> html file modifying the expected result for NimbusL&F.
> 
> Regards
> Prasanta
> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
> > Hi, Prasanta.
> > Please take a look to my comments at:
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
> >
> > The two methods paintText() and paintIcon() are contradict the spec
> and draw the text and icons outside of the tab.
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> Hi All,
> >>
> >> Please review a fix for an issue where long Tab titiles are not
> >> clipped
> >> with dots at end for NimbusLookAndFeel L&F.
> >> Other L&Fs works ok.
> >>
> >> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
> clipped
> >> but
> >> passed to paintText() as it is received.
> >> Other L&F such as Metal, Motif, Windows which uses
> >> BasicTabbedPaneUI#paintTab(), the title is clipped
> >>
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
> >> before it is passed to paintText().
> >>
> >> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
> >>
> >> Regards
> >> Prasanta


From sergey.bylokhov at oracle.com  Sun May 28 02:31:31 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 27 May 2017 19:31:31 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <a918bed7-2751-460c-8960-f55dc075e3f3@default>

Note that you shouldn't replace the clip, but should apply the new clip on top of the old. This is necessary if the old clip is smaller than new.

----- sergey.bylokhov at oracle.com wrote:

> Hi, Prasanta.
> 
> BasicTabbedPaneUI.paintIcon() as well as
> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>  - paintText() at line 681
>  - paintIcon() at line 634
> Both methods have a rectangle as a parameter, but it is ignored.
> 
> ----- prasanta.sadhukhan at oracle.com wrote:
> 
> > Hi Sergey,
> > 
> > I could get your concern for paintText() but could not find
> > paintIcon() 
> > in SynthGraphicsUtils() so not sure how icon drawing contradicts
> > spec.
> > Modified webrev:
> > http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
> > 
> > Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
> > then 
> > we are not going to get "..." at the end which this test expects.
> But
> > I 
> > could not find anything in spec, that mandates ending with "..." for
> 
> > long tab outside
> > tab bounds. If source change is ok, I guess we then need to modify
> the
> > 
> > html file modifying the expected result for NimbusL&F.
> > 
> > Regards
> > Prasanta
> > On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
> > > Hi, Prasanta.
> > > Please take a look to my comments at:
> > >
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
> > >
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
> > >
> > > The two methods paintText() and paintIcon() are contradict the
> spec
> > and draw the text and icons outside of the tab.
> > >
> > > ----- prasanta.sadhukhan at oracle.com wrote:
> > >
> > >> Hi All,
> > >>
> > >> Please review a fix for an issue where long Tab titiles are not
> > >> clipped
> > >> with dots at end for NimbusLookAndFeel L&F.
> > >> Other L&Fs works ok.
> > >>
> > >> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
> > clipped
> > >> but
> > >> passed to paintText() as it is received.
> > >> Other L&F such as Metal, Motif, Windows which uses
> > >> BasicTabbedPaneUI#paintTab(), the title is clipped
> > >>
> >
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
> > >> before it is passed to paintText().
> > >>
> > >> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
> > >>
> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
> > >> webrev:
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
> > >>
> > >> Regards
> > >> Prasanta


From prasanta.sadhukhan at oracle.com  Mon May 29 05:31:36 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 29 May 2017 11:01:36 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <61562b8a-ac72-49a0-af75-cd685c649373@default>
References: <61562b8a-ac72-49a0-af75-cd685c649373@default>
Message-ID: <2a9da078-c2d9-7b50-5f42-342cc3c0a8c2@oracle.com>

I am not sure why it is passing in my case. I thought it might be taking 
in some other security policy so I renamed and use a different named 
policy but it still passed in my windows 7.

$ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java 
-Djava.security.policy=my.policy bug6738668
Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
Test passed for LookAndFeel com.sun.java.swing.plaf.motif.MotifLookAndFeel
Test passed for LookAndFeel 
com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Test passed for LookAndFeel 
com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel

PRSADHUK-IN+prsadhuk at PRSADHUK-IN 
/cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
$ cat my.policy
grant {
     permission java.io.FilePermission "C:\\temp\\*", "read";
     permission java.io.FilePermission "C:\\temp", "read";
     permission java.util.PropertyPermission "*", "read";
};

PRSADHUK-IN+prsadhuk at PRSADHUK-IN 
/cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
$ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java -version
java version "1.7.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug, mixed mode)

BTW, does my updated test fail in your environment with b40?

Regards
Prasanta
On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
> There is a comment that JDK-6738668 a regression of JDK-6484091 which was pushed to b20.
> I just checked the test from the command line on b40 and it fails, but passed on b55.
> Can you please check why it was passed in your case.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi Sergey,
>>
>> I do not see any comment mention about failure in 7b20 but anyways, I
>>
>> tried with 7b20,7b30,7b40,7b50 and all of them passed with original
>> and
>> updated test in windows.
>>
>> Regards
>> Prasanta
>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>>> I am not sure but according to the comments of JDK-6738668 it was a
>> regression in 7b20.
>>> So I suggest to check a few build between b20 and b54
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> No, it is passing. Actually, the original test is also passing
>> with
>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>>> SecurityException
>>>>
>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
>> bug6738668
>>>> Test passed for LookAndFeel
>> javax.swing.plaf.metal.MetalLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>
>>>> jdk1.7.0/bin/java -version
>>>> java version "1.7.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed mode)
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Please confirm that the updated test fails before JDK-6738668 was
>>>> fixed.
>>>>>> Hi ALl,
>>>>>>
>>>>>> Please review a testbug fix for an issue where this regression
>> test
>>>> is failing in linux because
>>>>>> JFileChooser was trying to access C:/temp path which does not
>> exist
>>>> in linux.
>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
>> windows
>>>> path.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>>> webrev:
>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>> Regards
>>>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Mon May 29 06:19:45 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 29 May 2017 11:49:45 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <a918bed7-2751-460c-8960-f55dc075e3f3@default>
References: <a918bed7-2751-460c-8960-f55dc075e3f3@default>
Message-ID: <e298e783-8cfe-df17-9223-bbecd4b736d0@oracle.com>

I tried to incorporate your comments. Please find modified webrev

http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/

Regards
Prasanta
On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
> Note that you shouldn't replace the clip, but should apply the new clip on top of the old. This is necessary if the old clip is smaller than new.
>
> ----- sergey.bylokhov at oracle.com wrote:
>
>> Hi, Prasanta.
>>
>> BasicTabbedPaneUI.paintIcon() as well as
>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>   - paintText() at line 681
>>   - paintIcon() at line 634
>> Both methods have a rectangle as a parameter, but it is ignored.
>>
>> ----- prasanta.sadhukhan at oracle.com wrote:
>>
>>> Hi Sergey,
>>>
>>> I could get your concern for paintText() but could not find
>>> paintIcon()
>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>> spec.
>>> Modified webrev:
>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>
>>> Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
>>> then
>>> we are not going to get "..." at the end which this test expects.
>> But
>>> I
>>> could not find anything in spec, that mandates ending with "..." for
>>> long tab outside
>>> tab bounds. If source change is ok, I guess we then need to modify
>> the
>>> html file modifying the expected result for NimbusL&F.
>>>
>>> Regards
>>> Prasanta
>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Please take a look to my comments at:
>>>>
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>> The two methods paintText() and paintIcon() are contradict the
>> spec
>>> and draw the text and icons outside of the tab.
>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>> clipped
>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>> Other L&Fs works ok.
>>>>>
>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>> clipped
>>>>> but
>>>>> passed to paintText() as it is received.
>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>> before it is passed to paintText().
>>>>>
>>>>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>> webrev:
>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>> Regards
>>>>> Prasanta



From sergey.bylokhov at oracle.com  Mon May 29 21:29:27 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 29 May 2017 14:29:27 -0700 (PDT)
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
Message-ID: <82b5266f-f738-4968-b21c-4c55ebf704b9@default>

I guess you will need to set security manager which will use your policy file:
https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html

----- prasanta.sadhukhan at oracle.com wrote:

> I am not sure why it is passing in my case. I thought it might be
> taking 
> in some other security policy so I renamed and use a different named 
> policy but it still passed in my windows 7.
> 
> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java 
> -Djava.security.policy=my.policy bug6738668
> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
> Test passed for LookAndFeel
> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Test passed for LookAndFeel 
> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test passed for LookAndFeel 
> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> 
> PRSADHUK-IN+prsadhuk at PRSADHUK-IN 
> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
> $ cat my.policy
> grant {
>      permission java.io.FilePermission "C:\\temp\\*", "read";
>      permission java.io.FilePermission "C:\\temp", "read";
>      permission java.util.PropertyPermission "*", "read";
> };
> 
> PRSADHUK-IN+prsadhuk at PRSADHUK-IN 
> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
> -version
> java version "1.7.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug, mixed
> mode)
> 
> BTW, does my updated test fail in your environment with b40?
> 
> Regards
> Prasanta
> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
> > There is a comment that JDK-6738668 a regression of JDK-6484091
> which was pushed to b20.
> > I just checked the test from the command line on b40 and it fails,
> but passed on b55.
> > Can you please check why it was passed in your case.
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> Hi Sergey,
> >>
> >> I do not see any comment mention about failure in 7b20 but anyways,
> I
> >>
> >> tried with 7b20,7b30,7b40,7b50 and all of them passed with
> original
> >> and
> >> updated test in windows.
> >>
> >> Regards
> >> Prasanta
> >> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
> >>> I am not sure but according to the comments of JDK-6738668 it was
> a
> >> regression in 7b20.
> >>> So I suggest to check a few build between b20 and b54
> >>>
> >>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>
> >>>> Hi Sergey,
> >>>>
> >>>> No, it is passing. Actually, the original test is also passing
> >> with
> >>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
> >>>> SecurityException
> >>>>
> >>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
> >> bug6738668
> >>>> Test passed for LookAndFeel
> >> javax.swing.plaf.metal.MetalLookAndFeel
> >>>> Test passed for LookAndFeel
> >>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >>>> Test passed for LookAndFeel
> >>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >>>> Test passed for LookAndFeel
> >>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>>>
> >>>> jdk1.7.0/bin/java -version
> >>>> java version "1.7.0-ea"
> >>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
> >>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
> mode)
> >>>>
> >>>> Regards
> >>>> Prasanta
> >>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
> >>>>> Hi, Prasanta.
> >>>>> Please confirm that the updated test fails before JDK-6738668
> was
> >>>> fixed.
> >>>>>> Hi ALl,
> >>>>>>
> >>>>>> Please review a testbug fix for an issue where this regression
> >> test
> >>>> is failing in linux because
> >>>>>> JFileChooser was trying to access C:/temp path which does not
> >> exist
> >>>> in linux.
> >>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
> >> windows
> >>>> path.
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
> >>>>>> webrev:
> >> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
> >>>>>> Regards
> >>>>>> Prasanta


From prasanta.sadhukhan at oracle.com  Tue May 30 06:16:21 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 30 May 2017 11:46:21 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <82b5266f-f738-4968-b21c-4c55ebf704b9@default>
References: <82b5266f-f738-4968-b21c-4c55ebf704b9@default>
Message-ID: <e73280cd-ad22-266d-0899-be3bcab2330b@oracle.com>

OK. With revised command line, it fails with new updated test in 7b40 
and passed in 9b170

/cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java 
-Djava.security.manager -Djava.security.policy=security.policy bug6738668
tmp dir C:\cygwin64\tmp\
Exception in thread "main" java.security.AccessControlException: access 
denied (java.io.FilePermission 
C:\Users\prsadhuk\AppData\Roaming\Microsoft\Windows\Recent read)
         at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
         at 
java.security.AccessController.checkPermission(AccessController.java:555)
         at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
         at java.lang.SecurityManager.checkRead(SecurityManager.java:888)

/cygdrive/d/Vbox_Shared/JDK/jdk9-b170/fastdebug/bin/java 
-Djava.security.manager -Djava.security.policy=security.policy bug6738668
tmp dir C:\cygwin64\tmp\
Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
tmp dir C:\cygwin64\tmp\
Test passed for LookAndFeel javax.swing.plaf.nimbus.NimbusLookAndFeel
tmp dir C:\cygwin64\tmp\
Test passed for LookAndFeel com.sun.java.swing.plaf.motif.MotifLookAndFeel
tmp dir C:\cygwin64\tmp\
Test passed for LookAndFeel 
com.sun.java.swing.plaf.windows.WindowsLookAndFeel
tmp dir C:\cygwin64\tmp\
Test passed for LookAndFeel 
com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel

Regards
Prasanta
On 5/30/2017 2:59 AM, Sergey Bylokhov wrote:
> I guess you will need to set security manager which will use your policy file:
> https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> I am not sure why it is passing in my case. I thought it might be
>> taking
>> in some other security policy so I renamed and use a different named
>> policy but it still passed in my windows 7.
>>
>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>> -Djava.security.policy=my.policy bug6738668
>> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>
>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>> $ cat my.policy
>> grant {
>>       permission java.io.FilePermission "C:\\temp\\*", "read";
>>       permission java.io.FilePermission "C:\\temp", "read";
>>       permission java.util.PropertyPermission "*", "read";
>> };
>>
>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>> -version
>> java version "1.7.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
>> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug, mixed
>> mode)
>>
>> BTW, does my updated test fail in your environment with b40?
>>
>> Regards
>> Prasanta
>> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
>>> There is a comment that JDK-6738668 a regression of JDK-6484091
>> which was pushed to b20.
>>> I just checked the test from the command line on b40 and it fails,
>> but passed on b55.
>>> Can you please check why it was passed in your case.
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> I do not see any comment mention about failure in 7b20 but anyways,
>> I
>>>> tried with 7b20,7b30,7b40,7b50 and all of them passed with
>> original
>>>> and
>>>> updated test in windows.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>>>>> I am not sure but according to the comments of JDK-6738668 it was
>> a
>>>> regression in 7b20.
>>>>> So I suggest to check a few build between b20 and b54
>>>>>
>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> No, it is passing. Actually, the original test is also passing
>>>> with
>>>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>>>>> SecurityException
>>>>>>
>>>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
>>>> bug6738668
>>>>>> Test passed for LookAndFeel
>>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>>> Test passed for LookAndFeel
>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>>> Test passed for LookAndFeel
>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>>> Test passed for LookAndFeel
>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>>>
>>>>>> jdk1.7.0/bin/java -version
>>>>>> java version "1.7.0-ea"
>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
>> mode)
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>> Please confirm that the updated test fails before JDK-6738668
>> was
>>>>>> fixed.
>>>>>>>> Hi ALl,
>>>>>>>>
>>>>>>>> Please review a testbug fix for an issue where this regression
>>>> test
>>>>>> is failing in linux because
>>>>>>>> JFileChooser was trying to access C:/temp path which does not
>>>> exist
>>>>>> in linux.
>>>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
>>>> windows
>>>>>> path.
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>>>>> webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>>>> Regards
>>>>>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Tue May 30 11:25:30 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 30 May 2017 16:55:30 +0530
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting Nimbus.Overrides
 property affects custom keymap installation
Message-ID: <0d97c156-8e6f-9a05-b422-39b8a0dcdd84@oracle.com>

Hi All,

Please review a bug fix for Nimbus L&F where if app sets custom keymap 
and then sets Nimbus.Overrides property,
then the custom keymap is not honoured.
For example, if testapp sets a new action for "space" key press and sets 
sets Nimbus.Overrides property,
  it will not be honoured and default action ie. inserting a "space" 
character will be done.

Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true for 
Nimbus.Override property which causes SynthEditorPaneUI#updateStyle() to 
be called which
uninstall set keyboard actions and sets up default keyboard action.

Proposed fix is to check if a keymap is already set (a propertyChange 
event will be fired for when app calls setKeyMap()) then do not reset to 
default keymap.

Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/

Regards
Prasanta



From sergey.bylokhov at oracle.com  Tue May 30 16:58:56 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 May 2017 09:58:56 -0700 (PDT)
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
Message-ID: <9d784fcb-21f1-4249-af2a-295836b63451@default>

The new version fails even if run via jtreg?

----- prasanta.sadhukhan at oracle.com wrote:

> OK. With revised command line, it fails with new updated test in 7b40
> 
> and passed in 9b170
> 
> /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java 
> -Djava.security.manager -Djava.security.policy=security.policy
> bug6738668
> tmp dir C:\cygwin64\tmp\
> Exception in thread "main" java.security.AccessControlException:
> access 
> denied (java.io.FilePermission 
> C:\Users\prsadhuk\AppData\Roaming\Microsoft\Windows\Recent read)
>          at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
>          at 
> java.security.AccessController.checkPermission(AccessController.java:555)
>          at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>          at
> java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> 
> /cygdrive/d/Vbox_Shared/JDK/jdk9-b170/fastdebug/bin/java 
> -Djava.security.manager -Djava.security.policy=security.policy
> bug6738668
> tmp dir C:\cygwin64\tmp\
> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
> tmp dir C:\cygwin64\tmp\
> Test passed for LookAndFeel javax.swing.plaf.nimbus.NimbusLookAndFeel
> tmp dir C:\cygwin64\tmp\
> Test passed for LookAndFeel
> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> tmp dir C:\cygwin64\tmp\
> Test passed for LookAndFeel 
> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> tmp dir C:\cygwin64\tmp\
> Test passed for LookAndFeel 
> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> 
> Regards
> Prasanta
> On 5/30/2017 2:59 AM, Sergey Bylokhov wrote:
> > I guess you will need to set security manager which will use your
> policy file:
> >
> https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> I am not sure why it is passing in my case. I thought it might be
> >> taking
> >> in some other security policy so I renamed and use a different
> named
> >> policy but it still passed in my windows 7.
> >>
> >> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
> >> -Djava.security.policy=my.policy bug6738668
> >> Test passed for LookAndFeel
> javax.swing.plaf.metal.MetalLookAndFeel
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>
> >> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
> >> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
> >> $ cat my.policy
> >> grant {
> >>       permission java.io.FilePermission "C:\\temp\\*", "read";
> >>       permission java.io.FilePermission "C:\\temp", "read";
> >>       permission java.util.PropertyPermission "*", "read";
> >> };
> >>
> >> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
> >> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
> >> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
> >> -version
> >> java version "1.7.0-ea-fastdebug"
> >> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
> >> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug, mixed
> >> mode)
> >>
> >> BTW, does my updated test fail in your environment with b40?
> >>
> >> Regards
> >> Prasanta
> >> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
> >>> There is a comment that JDK-6738668 a regression of JDK-6484091
> >> which was pushed to b20.
> >>> I just checked the test from the command line on b40 and it
> fails,
> >> but passed on b55.
> >>> Can you please check why it was passed in your case.
> >>>
> >>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>
> >>>> Hi Sergey,
> >>>>
> >>>> I do not see any comment mention about failure in 7b20 but
> anyways,
> >> I
> >>>> tried with 7b20,7b30,7b40,7b50 and all of them passed with
> >> original
> >>>> and
> >>>> updated test in windows.
> >>>>
> >>>> Regards
> >>>> Prasanta
> >>>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
> >>>>> I am not sure but according to the comments of JDK-6738668 it
> was
> >> a
> >>>> regression in 7b20.
> >>>>> So I suggest to check a few build between b20 and b54
> >>>>>
> >>>>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>>>
> >>>>>> Hi Sergey,
> >>>>>>
> >>>>>> No, it is passing. Actually, the original test is also passing
> >>>> with
> >>>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
> >>>>>> SecurityException
> >>>>>>
> >>>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
> >>>> bug6738668
> >>>>>> Test passed for LookAndFeel
> >>>> javax.swing.plaf.metal.MetalLookAndFeel
> >>>>>> Test passed for LookAndFeel
> >>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >>>>>> Test passed for LookAndFeel
> >>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >>>>>> Test passed for LookAndFeel
> >>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>>>>>
> >>>>>> jdk1.7.0/bin/java -version
> >>>>>> java version "1.7.0-ea"
> >>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
> >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
> >> mode)
> >>>>>> Regards
> >>>>>> Prasanta
> >>>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
> >>>>>>> Hi, Prasanta.
> >>>>>>> Please confirm that the updated test fails before JDK-6738668
> >> was
> >>>>>> fixed.
> >>>>>>>> Hi ALl,
> >>>>>>>>
> >>>>>>>> Please review a testbug fix for an issue where this
> regression
> >>>> test
> >>>>>> is failing in linux because
> >>>>>>>> JFileChooser was trying to access C:/temp path which does
> not
> >>>> exist
> >>>>>> in linux.
> >>>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
> >>>> windows
> >>>>>> path.
> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
> >>>>>>>> webrev:
> >>>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
> >>>>>>>> Regards
> >>>>>>>> Prasanta


From avik.niyogi at oracle.com  Wed May 31 05:53:49 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 31 May 2017 11:23:49 +0530
Subject: <Swing Dev> swing-dev Digest, Vol 121, Issue 19
In-Reply-To: <mailman.18933.1496163626.26058.swing-dev@openjdk.java.net>
References: <mailman.18933.1496163626.26058.swing-dev@openjdk.java.net>
Message-ID: <EA3D7344-F2CB-4239-9AFA-D7C7F94C5464@oracle.com>

+1
 With Regards,
Avik Niyogi

> On 30-May-2017, at 10:30 pm, swing-dev-request at openjdk.java.net wrote:
> 
> Date: Mon, 29 May 2017 11:49:45 +0530
> From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>>
> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing
> 	case failed as the long Tab titles are not clipped with dots at the
> 	end with NimbusLookAndFeel
> Message-ID: <e298e783-8cfe-df17-9223-bbecd4b736d0 at oracle.com <mailto:e298e783-8cfe-df17-9223-bbecd4b736d0 at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> I tried to incorporate your comments. Please find modified webrev
> 
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/ <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/>
> 
> Regards
> Prasanta
> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>> Note that you shouldn't replace the clip, but should apply the new clip on top of the old. This is necessary if the old clip is smaller than new.
>> 
>> ----- sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com> wrote:
>> 
>>> Hi, Prasanta.
>>> 
>>> BasicTabbedPaneUI.paintIcon() as well as
>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>  - paintText() at line 681
>>>  - paintIcon() at line 634
>>> Both methods have a rectangle as a parameter, but it is ignored.
>>> 
>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>> 
>>>> Hi Sergey,
>>>> 
>>>> I could get your concern for paintText() but could not find
>>>> paintIcon()
>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>> spec.
>>>> Modified webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/ <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/>
>>>> 
>>>> Also, if we are not calling SwingUtilities2.clipStringIfNecessary()
>>>> then
>>>> we are not going to get "..." at the end which this test expects.
>>> But
>>>> I
>>>> could not find anything in spec, that mandates ending with "..." for
>>>> long tab outside
>>>> tab bounds. If source change is ok, I guess we then need to modify
>>> the
>>>> html file modifying the expected result for NimbusL&F.
>>>> 
>>>> Regards
>>>> Prasanta
>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Please take a look to my comments at:
>>>>> 
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html>
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html>
>>>>> The two methods paintText() and paintIcon() are contradict the
>>> spec
>>>> and draw the text and icons outside of the tab.
>>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>> clipped
>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>> Other L&Fs works ok.
>>>>>> 
>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>> clipped
>>>>>> but
>>>>>> passed to paintText() as it is received.
>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>> 
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950 <http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950>
>>>>>> before it is passed to paintText().
>>>>>> 
>>>>>> Proposed fix is to do the same for SynthTabbedPaneUI#paintTab().
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918 <https://bugs.openjdk.java.net/browse/JDK-8075918>
>>>>>> webrev:
>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/ <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/>
>>>>>> Regards
>>>>>> Prasanta
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170531/913c79d6/attachment.html>