From sanjayacl at gmail.com  Wed Aug  1 09:33:11 2012
From: sanjayacl at gmail.com (Sanjaya Liyanage)
Date: Wed, 1 Aug 2012 15:03:11 +0530
Subject: <Swing Dev> Adding a label on top of a button
Message-ID: <CAK94idupjTG+U=1Jrwp0hf=cgkU_9yw-yO=Hh7x=SP+BvJZGMg@mail.gmail.com>

Hi all,
  I want to add a label(D3) on right top corner of a button as below,Can
anyone help please?


[image: Inline image 1]


Thanks
Sanjaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120801/7ae3e4cc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3936 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120801/7ae3e4cc/image.png>

From pavel.porvatov at oracle.com  Wed Aug  1 15:03:41 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 01 Aug 2012 19:03:41 +0400
Subject: <Swing Dev> Adding a label on top of a button
In-Reply-To: <CAK94idupjTG+U=1Jrwp0hf=cgkU_9yw-yO=Hh7x=SP+BvJZGMg@mail.gmail.com>
References: <CAK94idupjTG+U=1Jrwp0hf=cgkU_9yw-yO=Hh7x=SP+BvJZGMg@mail.gmail.com>
Message-ID: <5019454D.1020709@oracle.com>

Hi Sanjaya,
> Hi all,
>   I want to add a label(D3) on right top corner of a button as 
> below,Can anyone help please?
>
>
> Inline image 1
>
There are many ways to do that. For example you can override the 
JButton#paintComponent method. Or you can use JLayer, see below:

import javax.swing.*;
import java.awt.*;

public class JLayerSample {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                JFrame frame = new JFrame();

                JButton button = new JButton("Some button");

                JLayer<JButton> layer = new JLayer<>(button);

                JPanel glassPane = new JPanel(new GridBagLayout());

                glassPane.add(new JLabel("D3"), new 
GridBagConstraints(0, 0, 1, 1, 1, 1,
                        GridBagConstraints.NORTHEAST, 
GridBagConstraints.NONE, new Insets(0, 0, 0, 0),
                        0, 0));

                layer.setGlassPane(glassPane);
                glassPane.setOpaque(false);
                glassPane.setVisible(true);

                frame.add(layer);

                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.setSize(600, 400);
                frame.setVisible(true);

            }
        });
    }
}

See more about JLayer here: 
http://docs.oracle.com/javase/tutorial/uiswing/misc/jlayer.html

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120801/c8aa0369/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3936 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120801/c8aa0369/attachment.png>

From dingxmin at linux.vnet.ibm.com  Thu Aug  2 06:58:07 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Thu, 02 Aug 2012 14:58:07 +0800
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do not
 stick to AccessibleComponent.getLocationOnScreen api
Message-ID: <501A24FF.5020508@linux.vnet.ibm.com>

Hi guys
   According to javadoc of AccessibleComponent.getLocationOnScreen, it 
returns null instead of throwing IllegalComponentStateException when the 
corresponding GUI object is not visible.
   However, two accessibility inner classes of JTable, 
JTable$AccessibleJTable$AccessibleJTableCell and 
Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
AccessibleComponent throw IllegalComponentStateException when the 
corresponding JTable is not visible.  This behavior conflicts with the spec.
   I have submitted a bug in sunbug system reporting the issue, and 
received two acknowledgement emails (bug id 7188613 and 7188612, don't 
know why there are two?).  I created a patch to fix the issue with a 
jtreg test case.  Both the patch and the test are uploaded into the 
following space.

http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/

   Would anyone help to review the patch?

Best regards,
Frank





From dingxmin at linux.vnet.ibm.com  Mon Aug  6 07:11:42 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Mon, 06 Aug 2012 15:11:42 +0800
Subject: <Swing Dev> DefaultButtonModel instance keeps stale listeners of
 JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls
Message-ID: <501F6E2E.1020608@linux.vnet.ibm.com>

Hi guys,
   There is a bug in FormView class which can be best illustrated by the 
following test case.

   1. First create a JEditorPane that has a "submit" input type in the 
"FORM" tag,
   JEditorPane html = new JEditorPane("text/html", "<html><body><FORM 
ACTION=\"examplescript.cgi\"><INPUT type=\"submit\" 
value=\"Submit\"></FORM></BODY></HTML>");
   2. And call SwingUtilities.updateComponentTreeUI(html).
   3. Now a NPE is thrown when the "submit" button is clicked, which is 
apparently a bug.

   I filed a sun bug 7189299 to track the bug.  A complete runnable Java 
test throwing NPE is available in that sun bug.  The root cause is that 
SwingUtilities.updateComponentTreeUI() triggers FormView instance to 
call its member method createInputComponent(AttributeSet attr, Object 
model) that instantializes JButton instance.  Then, immediately after 
the new JButton instance is created, a DefaultButtonModel instance that 
is kept in AttributeSet is used to replace innate button model by 
calling button.setModel((ButtonModel)model).  Tracing into setModel 
method, several listeners linking to the new JButton instance are 
registered on the shared button model.  However, there are no 
un-registration calls to remove any previously registered listeners 
pertaining to stale JButton instance.

   The bug applies to "submit", "reset", "image", "checkbox", "radio" 
html types because they call AbstractButton.setModel eventually. But 
seems easy to manifest the bug in observable way with only "submit" 
type, for example, the NPE above.  I wrote another java test in webrev 
that asserts number of listeners, which can be applied to all affected 
html types.

   Please take a look at its patch and test @
   http://cr.openjdk.java.net/~youdwei/ojdk-138/webrev.00/

   Your comment and effort are highly appreciated.

Best regards,
Frank




From pavel.porvatov at oracle.com  Mon Aug  6 13:54:47 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 06 Aug 2012 17:54:47 +0400
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <501A24FF.5020508@linux.vnet.ibm.com>
References: <501A24FF.5020508@linux.vnet.ibm.com>
Message-ID: <501FCCA7.7050304@oracle.com>

Hi Frank,

The fix looks good but I have several comments for the test:
1. The Swing components should be created and accessed only from EDT 
thread. Therefore the assertGetLocation method should be on EDT as well

2. I'd remove lines 59-61

3. The lines
  79         // Display the window.
  80         frame.setVisible(true);
  81         // make the frame invisible to test getLocationOnScreen() of
  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
  83         // and JTable$AccessibleJTable$AccessibleJTableCell
  84         frame.setVisible(false);
don't guaranty that the frame becomes visible for awhile. You should use 
SunToolkit.realsync for that (take a look at other tests). Is it really 
necessary for the test to show and hide the frame?

4. Why don't you cast getAccessibleContext into AccessibleTable in one 
line, but wrote six lines for that:
  88         AccessibleContext context = (AccessibleContext) table
  89                 .getAccessibleContext();
  90         // To get 
JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
  91         // we need to first
  92         // convert the context var to type AccessibleTable
  93         AccessibleTable accessibleTable = (AccessibleTable) context;

5. Could you please remove useless comments like:
  79         // Display the window.
  80         frame.setVisible(true);

  90         // To get 
JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
  91         // we need to first
  92         // convert the context var to type AccessibleTable

  94         // and then get JTable$AccessibleJTable$AccessibleTableHeader

etc.

Only comments like
  81         // make the frame invisible to test getLocationOnScreen() of
  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
  83         // and JTable$AccessibleJTable$AccessibleJTableCell

 100         // getLocation() must be null according to its javadoc and 
no exception
 101         // is thrown
looks reasonable for me in the provided test

Regards, Pavel


> Hi guys
>   According to javadoc of AccessibleComponent.getLocationOnScreen, it 
> returns null instead of throwing IllegalComponentStateException when 
> the corresponding GUI object is not visible.
>   However, two accessibility inner classes of JTable, 
> JTable$AccessibleJTable$AccessibleJTableCell and 
> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
> AccessibleComponent throw IllegalComponentStateException when the 
> corresponding JTable is not visible.  This behavior conflicts with the 
> spec.
>   I have submitted a bug in sunbug system reporting the issue, and 
> received two acknowledgement emails (bug id 7188613 and 7188612, don't 
> know why there are two?).  I created a patch to fix the issue with a 
> jtreg test case.  Both the patch and the test are uploaded into the 
> following space.
>
> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>
>   Would anyone help to review the patch?
>
> Best regards,
> Frank
>
>
>



From pavel.porvatov at oracle.com  Mon Aug  6 14:30:05 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 06 Aug 2012 18:30:05 +0400
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <501F6E2E.1020608@linux.vnet.ibm.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com>
Message-ID: <501FD4ED.9050201@oracle.com>

Hi Frank,
> Hi guys,
>   There is a bug in FormView class which can be best illustrated by 
> the following test case.
>
>   1. First create a JEditorPane that has a "submit" input type in the 
> "FORM" tag,
>   JEditorPane html = new JEditorPane("text/html", "<html><body><FORM 
> ACTION=\"examplescript.cgi\"><INPUT type=\"submit\" 
> value=\"Submit\"></FORM></BODY></HTML>");
>   2. And call SwingUtilities.updateComponentTreeUI(html).
>   3. Now a NPE is thrown when the "submit" button is clicked, which is 
> apparently a bug.
>
>   I filed a sun bug 7189299 to track the bug.  A complete runnable 
> Java test throwing NPE is available in that sun bug.  The root cause 
> is that SwingUtilities.updateComponentTreeUI() triggers FormView 
> instance to call its member method createInputComponent(AttributeSet 
> attr, Object model) that instantializes JButton instance.  Then, 
> immediately after the new JButton instance is created, a 
> DefaultButtonModel instance that is kept in AttributeSet is used to 
> replace innate button model by calling 
> button.setModel((ButtonModel)model).  Tracing into setModel method, 
> several listeners linking to the new JButton instance are registered 
> on the shared button model.  However, there are no un-registration 
> calls to remove any previously registered listeners pertaining to 
> stale JButton instance.
>
>   The bug applies to "submit", "reset", "image", "checkbox", "radio" 
> html types because they call AbstractButton.setModel eventually. But 
> seems easy to manifest the bug in observable way with only "submit" 
> type, for example, the NPE above.  I wrote another java test in webrev 
> that asserts number of listeners, which can be applied to all affected 
> html types.
>
>   Please take a look at its patch and test @
>   http://cr.openjdk.java.net/~youdwei/ojdk-138/webrev.00/
>
>   Your comment and effort are highly appreciated.
I've accepted the bug. I see that you marked bug as a regression. Did 
you investigated in which release the problem appeared and which fix 
introduced the regression?

I didn't reviewed you fix, but I have two comments:
1. What is the reason to name the test FormImageTestV3? Why FormImage? 
What is th V3?
2. Could you please put webrevs into folders with the bugID, but not 
into ojdk-138?

Regards, Pavel


From WLaan at costengineering.eu  Wed Aug  1 09:45:27 2012
From: WLaan at costengineering.eu (Walter Laan)
Date: Wed, 1 Aug 2012 09:45:27 +0000
Subject: <Swing Dev> Adding a label on top of a button
In-Reply-To: <CAK94idupjTG+U=1Jrwp0hf=cgkU_9yw-yO=Hh7x=SP+BvJZGMg@mail.gmail.com>
References: <CAK94idupjTG+U=1Jrwp0hf=cgkU_9yw-yO=Hh7x=SP+BvJZGMg@mail.gmail.com>
Message-ID: <59CA7531B79CD24C9220F8C952EF389E13DE4A28@EXCH2010.ce.local>

>  I want to add a label(D3) on right top corner of a button as below,Can anyone help please?

See http://docs.oracle.com/javase/tutorial/uiswing/misc/jlayer.html

Note that this mailing list is for development of the Swing library itself, not how to use Swing.

For the latter you could use (for example):
StackOverflow: http://stackoverflow.com/questions/tagged/swing
Oracle Swing forum: https://forums.oracle.com/forums/forum.jspa?forumID=950
You favourite search engine including keywords: java swing tutorial <subject>

HTH,
Walter



From pavel.porvatov at oracle.com  Tue Aug  7 17:17:57 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 07 Aug 2012 21:17:57 +0400
Subject: <Swing Dev> [7] Review request for 7123767 Wrong tooltip
 location in Multi-Monitor configurations
In-Reply-To: <5016903D.8010104@oracle.com>
References: <5016903D.8010104@oracle.com>
Message-ID: <50214DC5.4080907@oracle.com>

Hi Vladislav,
> Hello,
>
> please review the fix for 7123767: Wrong tooltip location in 
> Multi-Monitor configurations
>
> jdk7 webrev: http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.00/
> test source: http://cr.openjdk.java.net/~vkarnauk/7123767/test/
> bug description: 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123767
>
> This is also a customer escalated issue in jdk6.
>
> On multi-monitor configurations Component.getLocationOnScreen() may 
> return negative values. Additionally, ToolTipManager.showTipWindow() 
> method calculates tip window location from Component' 
> getLocationOnScreen() return data and draws tip window using the same 
> GraphicsConfiguration instance as component's top-left corner, which 
> again can be of negative value. When component is stretched across 
> multiple screen devices, this may lead to a situation when it's 
> tooltip is drawn on wrong monitor.
>
> To fix this we should count all GraphicsConfiguration instances and 
> determine correct screen device to draw on. We should also take into 
> account that:
> 1) tip window preferred location could be set
> 2) preferred location could be greater than total virtual bounds of 
> all monitors. To make tip window visible in such case we move it to 
> the corresponding corner of total virtual bounds
> 3) exact order of monitors (left-to-right and top-to-bottom) is unknown
>
> I run jtreg against ToolTipManager tests and all tests passed (I run 
> it several times with different monitor configurations). I also tested 
> the fix with custom test program (please see the link provided) with 4 
> possible monitor configurations (left-to-right, right-to-left, 
> top-to-bottom and bottom-to-top) and saw no issues.
>
> I added no new automated test(s) because this at least would require 
> multiple monitors to run.
I think you should write an automatic test, especially you are going to 
backport the fix. May be some testers have several monitors, or, e.g. I 
have two monitors and can't check the fix automatically. Moreover your 
manual test doesn't have any description about right behavior, so 
everybody have to spend a lot of time to understand which behavior is 
expected. BTW your test should work for single monitor, so the test will 
be useful for single-monitors environment as well.

Regards, Pavel


From zhouyx at linux.vnet.ibm.com  Thu Aug  9 07:29:46 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 9 Aug 2012 15:29:46 +0800
Subject: <Swing Dev> Add keyboard accessibility to JColorChooser swatch
Message-ID: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>

Hi all,

    This is a patch to add keyboard accessibility to JColorChooser swatch,
so when using TAB, the focus can move to SwatchPanel, choose color with
arrow keys and select color with space bar.

In current implementation, it is not able to move the focus to SwatchPanel
with TAB, this can be seen in SwingSet2 demo.
Steps:
1. run SwingSet2 demo
2. click on JColorChooser demo
3. click Background button and Swatches panel appears.
4. Press Tab key     =>   focus moves to OK button as shown in this image
http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png

With this patch, in step4, focus moves to SwatchPanel, as shown here
http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png
Then, arrow keys can be used to choose color and select color by space bar.

The webrev is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/  .

Please take a look.


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120809/354df605/attachment.html>

From dingxmin at linux.vnet.ibm.com  Fri Aug 10 07:13:11 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Fri, 10 Aug 2012 15:13:11 +0800
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <501FCCA7.7050304@oracle.com>
References: <501A24FF.5020508@linux.vnet.ibm.com> <501FCCA7.7050304@oracle.com>
Message-ID: <5024B487.9090308@linux.vnet.ibm.com>

Hi Pavel,
   Thanks for your comments from which I learned a lot.  A new review 
patch is created by incorporating your comments @

   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/

   Could you please review it again?

Best regards,
Frank

On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
> Hi Frank,
>
> The fix looks good but I have several comments for the test:
> 1. The Swing components should be created and accessed only from EDT 
> thread. Therefore the assertGetLocation method should be on EDT as well
>
> 2. I'd remove lines 59-61
>
> 3. The lines
>  79         // Display the window.
>  80         frame.setVisible(true);
>  81         // make the frame invisible to test getLocationOnScreen() of
>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>  84         frame.setVisible(false);
> don't guaranty that the frame becomes visible for awhile. You should 
> use SunToolkit.realsync for that (take a look at other tests). Is it 
> really necessary for the test to show and hide the frame?
>
> 4. Why don't you cast getAccessibleContext into AccessibleTable in one 
> line, but wrote six lines for that:
>  88         AccessibleContext context = (AccessibleContext) table
>  89                 .getAccessibleContext();
>  90         // To get 
> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>  91         // we need to first
>  92         // convert the context var to type AccessibleTable
>  93         AccessibleTable accessibleTable = (AccessibleTable) context;
>
> 5. Could you please remove useless comments like:
>  79         // Display the window.
>  80         frame.setVisible(true);
>
>  90         // To get 
> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>  91         // we need to first
>  92         // convert the context var to type AccessibleTable
>
>  94         // and then get JTable$AccessibleJTable$AccessibleTableHeader
>
> etc.
>
> Only comments like
>  81         // make the frame invisible to test getLocationOnScreen() of
>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>
> 100         // getLocation() must be null according to its javadoc and 
> no exception
> 101         // is thrown
> looks reasonable for me in the provided test
>
> Regards, Pavel
>
>
>> Hi guys
>>   According to javadoc of AccessibleComponent.getLocationOnScreen, it 
>> returns null instead of throwing IllegalComponentStateException when 
>> the corresponding GUI object is not visible.
>>   However, two accessibility inner classes of JTable, 
>> JTable$AccessibleJTable$AccessibleJTableCell and 
>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>> AccessibleComponent throw IllegalComponentStateException when the 
>> corresponding JTable is not visible.  This behavior conflicts with 
>> the spec.
>>   I have submitted a bug in sunbug system reporting the issue, and 
>> received two acknowledgement emails (bug id 7188613 and 7188612, 
>> don't know why there are two?).  I created a patch to fix the issue 
>> with a jtreg test case.  Both the patch and the test are uploaded 
>> into the following space.
>>
>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>
>>   Would anyone help to review the patch?
>>
>> Best regards,
>> Frank
>>
>>
>>
>



From zhouyx at linux.vnet.ibm.com  Fri Aug 10 07:57:09 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Fri, 10 Aug 2012 15:57:09 +0800
Subject: <Swing Dev> Fwd: Add keyboard accessibility to JColorChooser swatch
In-Reply-To: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>
References: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>
Message-ID: <CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>

Updated the repository used in webrev from jdk8-tl to
http://hg.openjdk.java.net/jdk8/awt/jdk  .

new webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.01/


---------- Forwarded message ----------
From: Sean Chou <zhouyx at linux.vnet.ibm.com>
Date: Thu, Aug 9, 2012 at 3:29 PM
Subject: <Swing Dev> Add keyboard accessibility to JColorChooser swatch
To: swing-dev at openjdk.java.net


Hi all,

    This is a patch to add keyboard accessibility to JColorChooser swatch,
so when using TAB, the focus can move to SwatchPanel, choose color with
arrow keys and select color with space bar.

In current implementation, it is not able to move the focus to SwatchPanel
with TAB, this can be seen in SwingSet2 demo.
Steps:
1. run SwingSet2 demo
2. click on JColorChooser demo
3. click Background button and Swatches panel appears.
4. Press Tab key     =>   focus moves to OK button as shown in this image
http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png

With this patch, in step4, focus moves to SwatchPanel, as shown here
http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png
Then, arrow keys can be used to choose color and select color by space bar.

The webrev is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/  .

Please take a look.


-- 
Best Regards,
Sean Chou




-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120810/58cd79ed/attachment.html>

From dingxmin at linux.vnet.ibm.com  Tue Aug 14 03:06:08 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Tue, 14 Aug 2012 11:06:08 +0800
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <501FD4ED.9050201@oracle.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com>
Message-ID: <5029C0A0.2030903@linux.vnet.ibm.com>

On 8/6/2012 10:30 PM, Pavel Porvatov wrote:
> Hi Frank,
>> Hi guys,
>>   There is a bug in FormView class which can be best illustrated by 
>> the following test case.
>>
>>   1. First create a JEditorPane that has a "submit" input type in the 
>> "FORM" tag,
>>   JEditorPane html = new JEditorPane("text/html", "<html><body><FORM 
>> ACTION=\"examplescript.cgi\"><INPUT type=\"submit\" 
>> value=\"Submit\"></FORM></BODY></HTML>");
>>   2. And call SwingUtilities.updateComponentTreeUI(html).
>>   3. Now a NPE is thrown when the "submit" button is clicked, which 
>> is apparently a bug.
>>
>>   I filed a sun bug 7189299 to track the bug.  A complete runnable 
>> Java test throwing NPE is available in that sun bug. The root cause 
>> is that SwingUtilities.updateComponentTreeUI() triggers FormView 
>> instance to call its member method createInputComponent(AttributeSet 
>> attr, Object model) that instantializes JButton instance.  Then, 
>> immediately after the new JButton instance is created, a 
>> DefaultButtonModel instance that is kept in AttributeSet is used to 
>> replace innate button model by calling 
>> button.setModel((ButtonModel)model).  Tracing into setModel method, 
>> several listeners linking to the new JButton instance are registered 
>> on the shared button model. However, there are no un-registration 
>> calls to remove any previously registered listeners pertaining to 
>> stale JButton instance.
>>
>>   The bug applies to "submit", "reset", "image", "checkbox", "radio" 
>> html types because they call AbstractButton.setModel eventually. But 
>> seems easy to manifest the bug in observable way with only "submit" 
>> type, for example, the NPE above.  I wrote another java test in 
>> webrev that asserts number of listeners, which can be applied to all 
>> affected html types.
>>
>>   Please take a look at its patch and test @
>>   http://cr.openjdk.java.net/~youdwei/ojdk-138/webrev.00/
>>
>>   Your comment and effort are highly appreciated.
> I've accepted the bug. I see that you marked bug as a regression. Did 
> you investigated in which release the problem appeared and which fix 
> introduced the regression?
>
> I didn't reviewed you fix, but I have two comments:
> 1. What is the reason to name the test FormImageTestV3? Why FormImage? 
> What is th V3?
> 2. Could you please put webrevs into folders with the bugID, but not 
> into ojdk-138?
>
> Regards, Pavel
>
Hi Pavel,
   Thanks for your comments.  I have revised the test and uploaded the 
webrev review package to the following folder.  Now the test name and 
folder name have been corrected according to your comments.  The 
regression mark was a mistake.  If possible, could you clear regression 
status?

http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/

   Please review the new one.  Thanks

Best regards,
Frank



From pavel.porvatov at oracle.com  Wed Aug 15 16:19:31 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 15 Aug 2012 20:19:31 +0400
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <5029C0A0.2030903@linux.vnet.ibm.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com> <501FD4ED.9050201@oracle.com>
	<5029C0A0.2030903@linux.vnet.ibm.com>
Message-ID: <502BCC13.4000808@oracle.com>

Hi Frank,

See comments below...
> On 8/6/2012 10:30 PM, Pavel Porvatov wrote:
>> Hi Frank,
>>> Hi guys,
>>>   There is a bug in FormView class which can be best illustrated by 
>>> the following test case.
>>>
>>>   1. First create a JEditorPane that has a "submit" input type in 
>>> the "FORM" tag,
>>>   JEditorPane html = new JEditorPane("text/html", "<html><body><FORM 
>>> ACTION=\"examplescript.cgi\"><INPUT type=\"submit\" 
>>> value=\"Submit\"></FORM></BODY></HTML>");
>>>   2. And call SwingUtilities.updateComponentTreeUI(html).
>>>   3. Now a NPE is thrown when the "submit" button is clicked, which 
>>> is apparently a bug.
>>>
>>>   I filed a sun bug 7189299 to track the bug.  A complete runnable 
>>> Java test throwing NPE is available in that sun bug. The root cause 
>>> is that SwingUtilities.updateComponentTreeUI() triggers FormView 
>>> instance to call its member method createInputComponent(AttributeSet 
>>> attr, Object model) that instantializes JButton instance.  Then, 
>>> immediately after the new JButton instance is created, a 
>>> DefaultButtonModel instance that is kept in AttributeSet is used to 
>>> replace innate button model by calling 
>>> button.setModel((ButtonModel)model).  Tracing into setModel method, 
>>> several listeners linking to the new JButton instance are registered 
>>> on the shared button model. However, there are no un-registration 
>>> calls to remove any previously registered listeners pertaining to 
>>> stale JButton instance.
>>>
>>>   The bug applies to "submit", "reset", "image", "checkbox", "radio" 
>>> html types because they call AbstractButton.setModel eventually. But 
>>> seems easy to manifest the bug in observable way with only "submit" 
>>> type, for example, the NPE above.  I wrote another java test in 
>>> webrev that asserts number of listeners, which can be applied to all 
>>> affected html types.
>>>
>>>   Please take a look at its patch and test @
>>>   http://cr.openjdk.java.net/~youdwei/ojdk-138/webrev.00/
>>>
>>>   Your comment and effort are highly appreciated.
>> I've accepted the bug. I see that you marked bug as a regression. Did 
>> you investigated in which release the problem appeared and which fix 
>> introduced the regression?
>>
>> I didn't reviewed you fix, but I have two comments:
>> 1. What is the reason to name the test FormImageTestV3? Why 
>> FormImage? What is th V3?
>> 2. Could you please put webrevs into folders with the bugID, but not 
>> into ojdk-138?
>>
>> Regards, Pavel
>>
> Hi Pavel,
>   Thanks for your comments.  I have revised the test and uploaded the 
> webrev review package to the following folder.  Now the test name and 
> folder name have been corrected according to your comments.  
1. Could you name the test from lower case? There is no strict rules for 
that, but most tests starts from "bug..."
2. You should use the SunToolkit.realSync method to be sure that frame 
became visible. Take a look in other test, e.g. 
test/javax/swing/JPopupMenu/7156657
3. You can reduce code and put try/finally block into single 
SwingUtilities.invokeAndWait
4. About the fix: you are removing ALL listeners from public model. That 
can lead to regressions and this behavior is not expected from users.
> The regression mark was a mistake.  If possible, could you clear 
> regression status?
Ok, I removed the regression keyword
>
> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/
>
>   Please review the new one.  Thanks
>
> Best regards,
> Frank
>



From pavel.porvatov at oracle.com  Thu Aug 16 14:00:35 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 16 Aug 2012 18:00:35 +0400
Subject: <Swing Dev> Fwd: Add keyboard accessibility to JColorChooser
 swatch
In-Reply-To: <CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>
References: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>
	<CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>
Message-ID: <502CFD03.3050808@oracle.com>

Hi Sean,
>
> Updated the repository used in webrev from jdk8-tl 
> to http://hg.openjdk.java.net/jdk8/awt/jdk  .
>
> new webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/webrev.01/> 
>
I have the following comments about the fix:

1. When right-to-left orientation the Recent swatches inverts right and 
left button.
2. Could you please don't use package visibility when 
fileds/methods/inner classes can be private (e.g. field 
mainSwatchKeyListener)
3. I think you should uninstall the introduced listeners in the 
DefaultSwatchChooserPanel#uninstallChooserPanel method
4. Why new listeners are Serializable?
5. I recommend to use if condition instead of switch/case blocks with 
one branch
6. Could you please rename selrow (and similar variables) into selRow
7. Can we use Component#isFocusOwner instead of supporting new variable 
showcursor?
8. Could you please follow our code guide lines (spaces etc)

Regards, Pavel

>
> ---------- Forwarded message ----------
> From: *Sean Chou* <zhouyx at linux.vnet.ibm.com 
> <mailto:zhouyx at linux.vnet.ibm.com>>
> Date: Thu, Aug 9, 2012 at 3:29 PM
> Subject: <Swing Dev> Add keyboard accessibility to JColorChooser swatch
> To: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>
>
> Hi all,
>
>     This is a patch to add keyboard accessibility to JColorChooser 
> swatch, so when using TAB, the focus can move to SwatchPanel, choose 
> color with arrow keys and select color with space bar. 
>
> In current implementation, it is not able to move the focus 
> to SwatchPanel with TAB, this can be seen in SwingSet2 demo. 
> Steps: 
> 1. run SwingSet2 demo 
> 2. click on JColorChooser demo
> 3. click Background button and Swatches panel appears.
> 4. Press Tab key     =>   focus moves to OK button as shown in this 
> image http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png 
> <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/screenshot_1.png>
>
> With this patch, in step4, focus moves to SwatchPanel, as shown 
> here http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png 
> <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/screenshot_2.png>
> Then, arrow keys can be used to choose color and select color by space 
> bar.
>
> The webrev is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/webrev.00/>  . 
>
> Please take a look.
>
>
> -- 
> Best Regards,
> Sean Chou
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>


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

From pavel.porvatov at oracle.com  Thu Aug 16 15:02:10 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 16 Aug 2012 19:02:10 +0400
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <5024B487.9090308@linux.vnet.ibm.com>
References: <501A24FF.5020508@linux.vnet.ibm.com> <501FCCA7.7050304@oracle.com>
	<5024B487.9090308@linux.vnet.ibm.com>
Message-ID: <502D0B72.5030100@oracle.com>

Hi Frank,
> Hi Pavel,
>   Thanks for your comments from which I learned a lot.  A new review 
> patch is created by incorporating your comments @
>
>   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/
>
>   Could you please review it again?
I have few comments about the last webrev:
1. There is no need to re-throw exceptions via exThrownInEDT. You can 
just throw RuntimeException if the test fails. It's ok to throw 
RuntimeException on the EDT, jtreg will fail in that case
2. Can we join two SwingUtilities.invokeAndWait into one?
3. Comments
96         // cast to interface AccessibleComponent to call 
getLocationOnScreen()
and
109         // cast to interface AccessibleComponent to call 
getLocationOnScreen()
look unnecessary

Other code looks good for me

Regards, Pavel
>
> Best regards,
> Frank
>
> On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
>> Hi Frank,
>>
>> The fix looks good but I have several comments for the test:
>> 1. The Swing components should be created and accessed only from EDT 
>> thread. Therefore the assertGetLocation method should be on EDT as well
>>
>> 2. I'd remove lines 59-61
>>
>> 3. The lines
>>  79         // Display the window.
>>  80         frame.setVisible(true);
>>  81         // make the frame invisible to test getLocationOnScreen() of
>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>  84         frame.setVisible(false);
>> don't guaranty that the frame becomes visible for awhile. You should 
>> use SunToolkit.realsync for that (take a look at other tests). Is it 
>> really necessary for the test to show and hide the frame?
>>
>> 4. Why don't you cast getAccessibleContext into AccessibleTable in 
>> one line, but wrote six lines for that:
>>  88         AccessibleContext context = (AccessibleContext) table
>>  89                 .getAccessibleContext();
>>  90         // To get 
>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>  91         // we need to first
>>  92         // convert the context var to type AccessibleTable
>>  93         AccessibleTable accessibleTable = (AccessibleTable) context;
>>
>> 5. Could you please remove useless comments like:
>>  79         // Display the window.
>>  80         frame.setVisible(true);
>>
>>  90         // To get 
>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>  91         // we need to first
>>  92         // convert the context var to type AccessibleTable
>>
>>  94         // and then get 
>> JTable$AccessibleJTable$AccessibleTableHeader
>>
>> etc.
>>
>> Only comments like
>>  81         // make the frame invisible to test getLocationOnScreen() of
>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>
>> 100         // getLocation() must be null according to its javadoc 
>> and no exception
>> 101         // is thrown
>> looks reasonable for me in the provided test
>>
>> Regards, Pavel
>>
>>
>>> Hi guys
>>>   According to javadoc of AccessibleComponent.getLocationOnScreen, 
>>> it returns null instead of throwing IllegalComponentStateException 
>>> when the corresponding GUI object is not visible.
>>>   However, two accessibility inner classes of JTable, 
>>> JTable$AccessibleJTable$AccessibleJTableCell and 
>>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>>> AccessibleComponent throw IllegalComponentStateException when the 
>>> corresponding JTable is not visible.  This behavior conflicts with 
>>> the spec.
>>>   I have submitted a bug in sunbug system reporting the issue, and 
>>> received two acknowledgement emails (bug id 7188613 and 7188612, 
>>> don't know why there are two?).  I created a patch to fix the issue 
>>> with a jtreg test case.  Both the patch and the test are uploaded 
>>> into the following space.
>>>
>>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>>
>>>   Would anyone help to review the patch?
>>>
>>> Best regards,
>>> Frank
>>>
>>>
>>>
>>
>



From dingxmin at linux.vnet.ibm.com  Fri Aug 17 07:45:52 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Fri, 17 Aug 2012 15:45:52 +0800
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <502D0B72.5030100@oracle.com>
References: <501A24FF.5020508@linux.vnet.ibm.com> <501FCCA7.7050304@oracle.com>
	<5024B487.9090308@linux.vnet.ibm.com> <502D0B72.5030100@oracle.com>
Message-ID: <502DF6B0.10103@linux.vnet.ibm.com>

Hi Pavel,
   Thanks for your review again.  Another review package incorporating 
your comments is @ http://cr.openjdk.java.net/~dingxmin/7188612/webrev.01
   Could you please take a look at it ?

Thanks,
Frank

On 8/16/2012 11:02 PM, Pavel Porvatov wrote:
> Hi Frank,
>> Hi Pavel,
>>   Thanks for your comments from which I learned a lot.  A new review 
>> patch is created by incorporating your comments @
>>
>>   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/
>>
>>   Could you please review it again?
> I have few comments about the last webrev:
> 1. There is no need to re-throw exceptions via exThrownInEDT. You can 
> just throw RuntimeException if the test fails. It's ok to throw 
> RuntimeException on the EDT, jtreg will fail in that case
> 2. Can we join two SwingUtilities.invokeAndWait into one?
> 3. Comments
> 96         // cast to interface AccessibleComponent to call 
> getLocationOnScreen()
> and
> 109         // cast to interface AccessibleComponent to call 
> getLocationOnScreen()
> look unnecessary
>
> Other code looks good for me
>
> Regards, Pavel
>>
>> Best regards,
>> Frank
>>
>> On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
>>> Hi Frank,
>>>
>>> The fix looks good but I have several comments for the test:
>>> 1. The Swing components should be created and accessed only from EDT 
>>> thread. Therefore the assertGetLocation method should be on EDT as well
>>>
>>> 2. I'd remove lines 59-61
>>>
>>> 3. The lines
>>>  79         // Display the window.
>>>  80         frame.setVisible(true);
>>>  81         // make the frame invisible to test 
>>> getLocationOnScreen() of
>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>  84         frame.setVisible(false);
>>> don't guaranty that the frame becomes visible for awhile. You should 
>>> use SunToolkit.realsync for that (take a look at other tests). Is it 
>>> really necessary for the test to show and hide the frame?
>>>
>>> 4. Why don't you cast getAccessibleContext into AccessibleTable in 
>>> one line, but wrote six lines for that:
>>>  88         AccessibleContext context = (AccessibleContext) table
>>>  89                 .getAccessibleContext();
>>>  90         // To get 
>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>  91         // we need to first
>>>  92         // convert the context var to type AccessibleTable
>>>  93         AccessibleTable accessibleTable = (AccessibleTable) 
>>> context;
>>>
>>> 5. Could you please remove useless comments like:
>>>  79         // Display the window.
>>>  80         frame.setVisible(true);
>>>
>>>  90         // To get 
>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>  91         // we need to first
>>>  92         // convert the context var to type AccessibleTable
>>>
>>>  94         // and then get 
>>> JTable$AccessibleJTable$AccessibleTableHeader
>>>
>>> etc.
>>>
>>> Only comments like
>>>  81         // make the frame invisible to test 
>>> getLocationOnScreen() of
>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>
>>> 100         // getLocation() must be null according to its javadoc 
>>> and no exception
>>> 101         // is thrown
>>> looks reasonable for me in the provided test
>>>
>>> Regards, Pavel
>>>
>>>
>>>> Hi guys
>>>>   According to javadoc of AccessibleComponent.getLocationOnScreen, 
>>>> it returns null instead of throwing IllegalComponentStateException 
>>>> when the corresponding GUI object is not visible.
>>>>   However, two accessibility inner classes of JTable, 
>>>> JTable$AccessibleJTable$AccessibleJTableCell and 
>>>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>>>> AccessibleComponent throw IllegalComponentStateException when the 
>>>> corresponding JTable is not visible.  This behavior conflicts with 
>>>> the spec.
>>>>   I have submitted a bug in sunbug system reporting the issue, and 
>>>> received two acknowledgement emails (bug id 7188613 and 7188612, 
>>>> don't know why there are two?).  I created a patch to fix the issue 
>>>> with a jtreg test case. Both the patch and the test are uploaded 
>>>> into the following space.
>>>>
>>>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>>>
>>>>   Would anyone help to review the patch?
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>>
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Fri Aug 17 11:13:27 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 17 Aug 2012 15:13:27 +0400
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <502DF6B0.10103@linux.vnet.ibm.com>
References: <501A24FF.5020508@linux.vnet.ibm.com> <501FCCA7.7050304@oracle.com>
	<5024B487.9090308@linux.vnet.ibm.com> <502D0B72.5030100@oracle.com>
	<502DF6B0.10103@linux.vnet.ibm.com>
Message-ID: <502E2757.9060907@oracle.com>

Hi Frank,
> Hi Pavel,
>   Thanks for your review again.  Another review package incorporating 
> your comments is @ http://cr.openjdk.java.net/~dingxmin/7188612/webrev.01
>   Could you please take a look at it ?
The fix looks good for me.

Regards, Pavel
>
> Thanks,
> Frank
>
> On 8/16/2012 11:02 PM, Pavel Porvatov wrote:
>> Hi Frank,
>>> Hi Pavel,
>>>   Thanks for your comments from which I learned a lot.  A new review 
>>> patch is created by incorporating your comments @
>>>
>>>   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/
>>>
>>>   Could you please review it again?
>> I have few comments about the last webrev:
>> 1. There is no need to re-throw exceptions via exThrownInEDT. You can 
>> just throw RuntimeException if the test fails. It's ok to throw 
>> RuntimeException on the EDT, jtreg will fail in that case
>> 2. Can we join two SwingUtilities.invokeAndWait into one?
>> 3. Comments
>> 96         // cast to interface AccessibleComponent to call 
>> getLocationOnScreen()
>> and
>> 109         // cast to interface AccessibleComponent to call 
>> getLocationOnScreen()
>> look unnecessary
>>
>> Other code looks good for me
>>
>> Regards, Pavel
>>>
>>> Best regards,
>>> Frank
>>>
>>> On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
>>>> Hi Frank,
>>>>
>>>> The fix looks good but I have several comments for the test:
>>>> 1. The Swing components should be created and accessed only from 
>>>> EDT thread. Therefore the assertGetLocation method should be on EDT 
>>>> as well
>>>>
>>>> 2. I'd remove lines 59-61
>>>>
>>>> 3. The lines
>>>>  79         // Display the window.
>>>>  80         frame.setVisible(true);
>>>>  81         // make the frame invisible to test 
>>>> getLocationOnScreen() of
>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>  84         frame.setVisible(false);
>>>> don't guaranty that the frame becomes visible for awhile. You 
>>>> should use SunToolkit.realsync for that (take a look at other 
>>>> tests). Is it really necessary for the test to show and hide the 
>>>> frame?
>>>>
>>>> 4. Why don't you cast getAccessibleContext into AccessibleTable in 
>>>> one line, but wrote six lines for that:
>>>>  88         AccessibleContext context = (AccessibleContext) table
>>>>  89                 .getAccessibleContext();
>>>>  90         // To get 
>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>  91         // we need to first
>>>>  92         // convert the context var to type AccessibleTable
>>>>  93         AccessibleTable accessibleTable = (AccessibleTable) 
>>>> context;
>>>>
>>>> 5. Could you please remove useless comments like:
>>>>  79         // Display the window.
>>>>  80         frame.setVisible(true);
>>>>
>>>>  90         // To get 
>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>  91         // we need to first
>>>>  92         // convert the context var to type AccessibleTable
>>>>
>>>>  94         // and then get 
>>>> JTable$AccessibleJTable$AccessibleTableHeader
>>>>
>>>> etc.
>>>>
>>>> Only comments like
>>>>  81         // make the frame invisible to test 
>>>> getLocationOnScreen() of
>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>
>>>> 100         // getLocation() must be null according to its javadoc 
>>>> and no exception
>>>> 101         // is thrown
>>>> looks reasonable for me in the provided test
>>>>
>>>> Regards, Pavel
>>>>
>>>>
>>>>> Hi guys
>>>>>   According to javadoc of AccessibleComponent.getLocationOnScreen, 
>>>>> it returns null instead of throwing IllegalComponentStateException 
>>>>> when the corresponding GUI object is not visible.
>>>>>   However, two accessibility inner classes of JTable, 
>>>>> JTable$AccessibleJTable$AccessibleJTableCell and 
>>>>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>>>>> AccessibleComponent throw IllegalComponentStateException when the 
>>>>> corresponding JTable is not visible.  This behavior conflicts with 
>>>>> the spec.
>>>>>   I have submitted a bug in sunbug system reporting the issue, and 
>>>>> received two acknowledgement emails (bug id 7188613 and 7188612, 
>>>>> don't know why there are two?).  I created a patch to fix the 
>>>>> issue with a jtreg test case. Both the patch and the test are 
>>>>> uploaded into the following space.
>>>>>
>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>>>>
>>>>>   Would anyone help to review the patch?
>>>>>
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Fri Aug 17 17:10:25 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 17 Aug 2012 21:10:25 +0400
Subject: <Swing Dev> [7] Review request for 7123767 Wrong tooltip
 location in Multi-Monitor configurations
In-Reply-To: <5016903D.8010104@oracle.com>
References: <5016903D.8010104@oracle.com>
Message-ID: <502E7B01.1050801@oracle.com>

Hi Vladislav,

I have several comments about the fix:

1. javax.swing.ToolTipManager#showTipWindow: I think toFind variable 
should be initialized in if(preferredLocation != null) { ....} else 
{...} block. It looks more logical and code will be more compact 
(adjustedPreferredLocation can be removed at all, I think)

2. Could you please explain why you are using union of all rectangles in 
the getDrawingRect method? In case two monitors are aligned on a 
diagonal totalRect will contain areas that are not covered by screen 
devices and popups can be placed incorrectly.

Regards, Pavel

> Hello,
>
> please review the fix for 7123767: Wrong tooltip location in 
> Multi-Monitor configurations
>
> jdk7 webrev: http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.00/
> test source: http://cr.openjdk.java.net/~vkarnauk/7123767/test/
> bug description: 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123767
>
> This is also a customer escalated issue in jdk6.
>
> On multi-monitor configurations Component.getLocationOnScreen() may 
> return negative values. Additionally, ToolTipManager.showTipWindow() 
> method calculates tip window location from Component' 
> getLocationOnScreen() return data and draws tip window using the same 
> GraphicsConfiguration instance as component's top-left corner, which 
> again can be of negative value. When component is stretched across 
> multiple screen devices, this may lead to a situation when it's 
> tooltip is drawn on wrong monitor.
>
> To fix this we should count all GraphicsConfiguration instances and 
> determine correct screen device to draw on. We should also take into 
> account that:
> 1) tip window preferred location could be set
> 2) preferred location could be greater than total virtual bounds of 
> all monitors. To make tip window visible in such case we move it to 
> the corresponding corner of total virtual bounds
> 3) exact order of monitors (left-to-right and top-to-bottom) is unknown
>
> I run jtreg against ToolTipManager tests and all tests passed (I run 
> it several times with different monitor configurations). I also tested 
> the fix with custom test program (please see the link provided) with 4 
> possible monitor configurations (left-to-right, right-to-left, 
> top-to-bottom and bottom-to-top) and saw no issues.
>
> I added no new automated test(s) because this at least would require 
> multiple monitors to run.
>
> Regards,
> - Vlad



From luchsh at linux.vnet.ibm.com  Mon Aug 20 05:20:32 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 20 Aug 2012 13:20:32 +0800
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <502E2757.9060907@oracle.com>
References: <501A24FF.5020508@linux.vnet.ibm.com>
	<501FCCA7.7050304@oracle.com>	<5024B487.9090308@linux.vnet.ibm.com>
	<502D0B72.5030100@oracle.com>	<502DF6B0.10103@linux.vnet.ibm.com>
	<502E2757.9060907@oracle.com>
Message-ID: <5031C920.9010901@linux.vnet.ibm.com>

Hi Pavel,

Thanks for review, the change has been pushed to
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2fe9c1f0b16b

changeset:   5692:2fe9c1f0b16b
tag:         tip
user:        dingxmin
date:        Mon Aug 20 13:16:18 2012 +0800
files:       src/share/classes/javax/swing/JTable.java 
test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java
description:
7188612: JTable's AccessibleJTable throws IllegalComponentStateException 
instead of null
Reviewed-by: rupashka

And to Frank, could you pls verify it?

Thanks
Jonathan

On 08/17/2012 07:13 PM, Pavel Porvatov wrote:
> Hi Frank,
>> Hi Pavel,
>>   Thanks for your review again.  Another review package incorporating 
>> your comments is @ 
>> http://cr.openjdk.java.net/~dingxmin/7188612/webrev.01
>>   Could you please take a look at it ?
> The fix looks good for me.
>
> Regards, Pavel
>>
>> Thanks,
>> Frank
>>
>> On 8/16/2012 11:02 PM, Pavel Porvatov wrote:
>>> Hi Frank,
>>>> Hi Pavel,
>>>>   Thanks for your comments from which I learned a lot.  A new 
>>>> review patch is created by incorporating your comments @
>>>>
>>>>   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/
>>>>
>>>>   Could you please review it again?
>>> I have few comments about the last webrev:
>>> 1. There is no need to re-throw exceptions via exThrownInEDT. You 
>>> can just throw RuntimeException if the test fails. It's ok to throw 
>>> RuntimeException on the EDT, jtreg will fail in that case
>>> 2. Can we join two SwingUtilities.invokeAndWait into one?
>>> 3. Comments
>>> 96         // cast to interface AccessibleComponent to call 
>>> getLocationOnScreen()
>>> and
>>> 109         // cast to interface AccessibleComponent to call 
>>> getLocationOnScreen()
>>> look unnecessary
>>>
>>> Other code looks good for me
>>>
>>> Regards, Pavel
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
>>>>> Hi Frank,
>>>>>
>>>>> The fix looks good but I have several comments for the test:
>>>>> 1. The Swing components should be created and accessed only from 
>>>>> EDT thread. Therefore the assertGetLocation method should be on 
>>>>> EDT as well
>>>>>
>>>>> 2. I'd remove lines 59-61
>>>>>
>>>>> 3. The lines
>>>>>  79         // Display the window.
>>>>>  80         frame.setVisible(true);
>>>>>  81         // make the frame invisible to test 
>>>>> getLocationOnScreen() of
>>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>>  84         frame.setVisible(false);
>>>>> don't guaranty that the frame becomes visible for awhile. You 
>>>>> should use SunToolkit.realsync for that (take a look at other 
>>>>> tests). Is it really necessary for the test to show and hide the 
>>>>> frame?
>>>>>
>>>>> 4. Why don't you cast getAccessibleContext into AccessibleTable in 
>>>>> one line, but wrote six lines for that:
>>>>>  88         AccessibleContext context = (AccessibleContext) table
>>>>>  89                 .getAccessibleContext();
>>>>>  90         // To get 
>>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>>  91         // we need to first
>>>>>  92         // convert the context var to type AccessibleTable
>>>>>  93         AccessibleTable accessibleTable = (AccessibleTable) 
>>>>> context;
>>>>>
>>>>> 5. Could you please remove useless comments like:
>>>>>  79         // Display the window.
>>>>>  80         frame.setVisible(true);
>>>>>
>>>>>  90         // To get 
>>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>>  91         // we need to first
>>>>>  92         // convert the context var to type AccessibleTable
>>>>>
>>>>>  94         // and then get 
>>>>> JTable$AccessibleJTable$AccessibleTableHeader
>>>>>
>>>>> etc.
>>>>>
>>>>> Only comments like
>>>>>  81         // make the frame invisible to test 
>>>>> getLocationOnScreen() of
>>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>>
>>>>> 100         // getLocation() must be null according to its javadoc 
>>>>> and no exception
>>>>> 101         // is thrown
>>>>> looks reasonable for me in the provided test
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>>
>>>>>> Hi guys
>>>>>>   According to javadoc of 
>>>>>> AccessibleComponent.getLocationOnScreen, it returns null instead 
>>>>>> of throwing IllegalComponentStateException when the corresponding 
>>>>>> GUI object is not visible.
>>>>>>   However, two accessibility inner classes of JTable, 
>>>>>> JTable$AccessibleJTable$AccessibleJTableCell and 
>>>>>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>>>>>> AccessibleComponent throw IllegalComponentStateException when the 
>>>>>> corresponding JTable is not visible.  This behavior conflicts 
>>>>>> with the spec.
>>>>>>   I have submitted a bug in sunbug system reporting the issue, 
>>>>>> and received two acknowledgement emails (bug id 7188613 and 
>>>>>> 7188612, don't know why there are two?).  I created a patch to 
>>>>>> fix the issue with a jtreg test case. Both the patch and the test 
>>>>>> are uploaded into the following space.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>>>>>
>>>>>>   Would anyone help to review the patch?
>>>>>>
>>>>>> Best regards,
>>>>>> Frank
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From dingxmin at linux.vnet.ibm.com  Mon Aug 20 06:22:14 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Mon, 20 Aug 2012 14:22:14 +0800
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <5031C920.9010901@linux.vnet.ibm.com>
References: <501A24FF.5020508@linux.vnet.ibm.com>
	<501FCCA7.7050304@oracle.com>	<5024B487.9090308@linux.vnet.ibm.com>
	<502D0B72.5030100@oracle.com>	<502DF6B0.10103@linux.vnet.ibm.com>
	<502E2757.9060907@oracle.com> <5031C920.9010901@linux.vnet.ibm.com>
Message-ID: <5031D796.5010405@linux.vnet.ibm.com>

Hi Pavel
   Thanks for review.
To Jonathan,
   Thanks for committing.  It looks good.

Best regards,
Frank

On 8/20/2012 1:20 PM, Jonathan Lu wrote:
> Hi Pavel,
>
> Thanks for review, the change has been pushed to
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2fe9c1f0b16b
>
> changeset:   5692:2fe9c1f0b16b
> tag:         tip
> user:        dingxmin
> date:        Mon Aug 20 13:16:18 2012 +0800
> files:       src/share/classes/javax/swing/JTable.java 
> test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java
> description:
> 7188612: JTable's AccessibleJTable throws 
> IllegalComponentStateException instead of null
> Reviewed-by: rupashka
>
> And to Frank, could you pls verify it?
>
> Thanks
> Jonathan
>
> On 08/17/2012 07:13 PM, Pavel Porvatov wrote:
>> Hi Frank,
>>> Hi Pavel,
>>>   Thanks for your review again.  Another review package 
>>> incorporating your comments is @ 
>>> http://cr.openjdk.java.net/~dingxmin/7188612/webrev.01
>>>   Could you please take a look at it ?
>> The fix looks good for me.
>>
>> Regards, Pavel
>>>
>>> Thanks,
>>> Frank
>>>
>>> On 8/16/2012 11:02 PM, Pavel Porvatov wrote:
>>>> Hi Frank,
>>>>> Hi Pavel,
>>>>>   Thanks for your comments from which I learned a lot.  A new 
>>>>> review patch is created by incorporating your comments @
>>>>>
>>>>>   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/
>>>>>
>>>>>   Could you please review it again?
>>>> I have few comments about the last webrev:
>>>> 1. There is no need to re-throw exceptions via exThrownInEDT. You 
>>>> can just throw RuntimeException if the test fails. It's ok to throw 
>>>> RuntimeException on the EDT, jtreg will fail in that case
>>>> 2. Can we join two SwingUtilities.invokeAndWait into one?
>>>> 3. Comments
>>>> 96         // cast to interface AccessibleComponent to call 
>>>> getLocationOnScreen()
>>>> and
>>>> 109         // cast to interface AccessibleComponent to call 
>>>> getLocationOnScreen()
>>>> look unnecessary
>>>>
>>>> Other code looks good for me
>>>>
>>>> Regards, Pavel
>>>>>
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>> On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
>>>>>> Hi Frank,
>>>>>>
>>>>>> The fix looks good but I have several comments for the test:
>>>>>> 1. The Swing components should be created and accessed only from 
>>>>>> EDT thread. Therefore the assertGetLocation method should be on 
>>>>>> EDT as well
>>>>>>
>>>>>> 2. I'd remove lines 59-61
>>>>>>
>>>>>> 3. The lines
>>>>>>  79         // Display the window.
>>>>>>  80         frame.setVisible(true);
>>>>>>  81         // make the frame invisible to test 
>>>>>> getLocationOnScreen() of
>>>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>>>  84         frame.setVisible(false);
>>>>>> don't guaranty that the frame becomes visible for awhile. You 
>>>>>> should use SunToolkit.realsync for that (take a look at other 
>>>>>> tests). Is it really necessary for the test to show and hide the 
>>>>>> frame?
>>>>>>
>>>>>> 4. Why don't you cast getAccessibleContext into AccessibleTable 
>>>>>> in one line, but wrote six lines for that:
>>>>>>  88         AccessibleContext context = (AccessibleContext) table
>>>>>>  89                 .getAccessibleContext();
>>>>>>  90         // To get 
>>>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>>>  91         // we need to first
>>>>>>  92         // convert the context var to type AccessibleTable
>>>>>>  93         AccessibleTable accessibleTable = (AccessibleTable) 
>>>>>> context;
>>>>>>
>>>>>> 5. Could you please remove useless comments like:
>>>>>>  79         // Display the window.
>>>>>>  80         frame.setVisible(true);
>>>>>>
>>>>>>  90         // To get 
>>>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>>>  91         // we need to first
>>>>>>  92         // convert the context var to type AccessibleTable
>>>>>>
>>>>>>  94         // and then get 
>>>>>> JTable$AccessibleJTable$AccessibleTableHeader
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> Only comments like
>>>>>>  81         // make the frame invisible to test 
>>>>>> getLocationOnScreen() of
>>>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>>>
>>>>>> 100         // getLocation() must be null according to its 
>>>>>> javadoc and no exception
>>>>>> 101         // is thrown
>>>>>> looks reasonable for me in the provided test
>>>>>>
>>>>>> Regards, Pavel
>>>>>>
>>>>>>
>>>>>>> Hi guys
>>>>>>>   According to javadoc of 
>>>>>>> AccessibleComponent.getLocationOnScreen, it returns null instead 
>>>>>>> of throwing IllegalComponentStateException when the 
>>>>>>> corresponding GUI object is not visible.
>>>>>>>   However, two accessibility inner classes of JTable, 
>>>>>>> JTable$AccessibleJTable$AccessibleJTableCell and 
>>>>>>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>>>>>>> AccessibleComponent throw IllegalComponentStateException when 
>>>>>>> the corresponding JTable is not visible.  This behavior 
>>>>>>> conflicts with the spec.
>>>>>>>   I have submitted a bug in sunbug system reporting the issue, 
>>>>>>> and received two acknowledgement emails (bug id 7188613 and 
>>>>>>> 7188612, don't know why there are two?).  I created a patch to 
>>>>>>> fix the issue with a jtreg test case. Both the patch and the 
>>>>>>> test are uploaded into the following space.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>>>>>>
>>>>>>>   Would anyone help to review the patch?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Frank
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Mon Aug 20 08:17:37 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 20 Aug 2012 12:17:37 +0400
Subject: <Swing Dev> Accessibility inner classes in AccessibleJTable do
 not stick to AccessibleComponent.getLocationOnScreen api
In-Reply-To: <5031C920.9010901@linux.vnet.ibm.com>
References: <501A24FF.5020508@linux.vnet.ibm.com>
	<501FCCA7.7050304@oracle.com>	<5024B487.9090308@linux.vnet.ibm.com>
	<502D0B72.5030100@oracle.com>	<502DF6B0.10103@linux.vnet.ibm.com>
	<502E2757.9060907@oracle.com> <5031C920.9010901@linux.vnet.ibm.com>
Message-ID: <5031F2A1.3030306@oracle.com>

Hi Jonathan,

Thanks! I marked the bug as Fix Available.

Regards, Pavel
> Hi Pavel,
>
> Thanks for review, the change has been pushed to
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2fe9c1f0b16b
>
> changeset:   5692:2fe9c1f0b16b
> tag:         tip
> user:        dingxmin
> date:        Mon Aug 20 13:16:18 2012 +0800
> files:       src/share/classes/javax/swing/JTable.java 
> test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java
> description:
> 7188612: JTable's AccessibleJTable throws 
> IllegalComponentStateException instead of null
> Reviewed-by: rupashka
>
> And to Frank, could you pls verify it?
>
> Thanks
> Jonathan
>
> On 08/17/2012 07:13 PM, Pavel Porvatov wrote:
>> Hi Frank,
>>> Hi Pavel,
>>>   Thanks for your review again.  Another review package 
>>> incorporating your comments is @ 
>>> http://cr.openjdk.java.net/~dingxmin/7188612/webrev.01
>>>   Could you please take a look at it ?
>> The fix looks good for me.
>>
>> Regards, Pavel
>>>
>>> Thanks,
>>> Frank
>>>
>>> On 8/16/2012 11:02 PM, Pavel Porvatov wrote:
>>>> Hi Frank,
>>>>> Hi Pavel,
>>>>>   Thanks for your comments from which I learned a lot.  A new 
>>>>> review patch is created by incorporating your comments @
>>>>>
>>>>>   http://cr.openjdk.java.net/~dingxmin/7188612/webrev.00/
>>>>>
>>>>>   Could you please review it again?
>>>> I have few comments about the last webrev:
>>>> 1. There is no need to re-throw exceptions via exThrownInEDT. You 
>>>> can just throw RuntimeException if the test fails. It's ok to throw 
>>>> RuntimeException on the EDT, jtreg will fail in that case
>>>> 2. Can we join two SwingUtilities.invokeAndWait into one?
>>>> 3. Comments
>>>> 96         // cast to interface AccessibleComponent to call 
>>>> getLocationOnScreen()
>>>> and
>>>> 109         // cast to interface AccessibleComponent to call 
>>>> getLocationOnScreen()
>>>> look unnecessary
>>>>
>>>> Other code looks good for me
>>>>
>>>> Regards, Pavel
>>>>>
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>> On 8/6/2012 9:54 PM, Pavel Porvatov wrote:
>>>>>> Hi Frank,
>>>>>>
>>>>>> The fix looks good but I have several comments for the test:
>>>>>> 1. The Swing components should be created and accessed only from 
>>>>>> EDT thread. Therefore the assertGetLocation method should be on 
>>>>>> EDT as well
>>>>>>
>>>>>> 2. I'd remove lines 59-61
>>>>>>
>>>>>> 3. The lines
>>>>>>  79         // Display the window.
>>>>>>  80         frame.setVisible(true);
>>>>>>  81         // make the frame invisible to test 
>>>>>> getLocationOnScreen() of
>>>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>>>  84         frame.setVisible(false);
>>>>>> don't guaranty that the frame becomes visible for awhile. You 
>>>>>> should use SunToolkit.realsync for that (take a look at other 
>>>>>> tests). Is it really necessary for the test to show and hide the 
>>>>>> frame?
>>>>>>
>>>>>> 4. Why don't you cast getAccessibleContext into AccessibleTable 
>>>>>> in one line, but wrote six lines for that:
>>>>>>  88         AccessibleContext context = (AccessibleContext) table
>>>>>>  89                 .getAccessibleContext();
>>>>>>  90         // To get 
>>>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>>>  91         // we need to first
>>>>>>  92         // convert the context var to type AccessibleTable
>>>>>>  93         AccessibleTable accessibleTable = (AccessibleTable) 
>>>>>> context;
>>>>>>
>>>>>> 5. Could you please remove useless comments like:
>>>>>>  79         // Display the window.
>>>>>>  80         frame.setVisible(true);
>>>>>>
>>>>>>  90         // To get 
>>>>>> JTable$AccessibleJTable$AccessibleJTableHeaderCell instance,
>>>>>>  91         // we need to first
>>>>>>  92         // convert the context var to type AccessibleTable
>>>>>>
>>>>>>  94         // and then get 
>>>>>> JTable$AccessibleJTable$AccessibleTableHeader
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> Only comments like
>>>>>>  81         // make the frame invisible to test 
>>>>>> getLocationOnScreen() of
>>>>>>  82         // JTable$AccessibleJTable$AccessibleJTableHeaderCell
>>>>>>  83         // and JTable$AccessibleJTable$AccessibleJTableCell
>>>>>>
>>>>>> 100         // getLocation() must be null according to its 
>>>>>> javadoc and no exception
>>>>>> 101         // is thrown
>>>>>> looks reasonable for me in the provided test
>>>>>>
>>>>>> Regards, Pavel
>>>>>>
>>>>>>
>>>>>>> Hi guys
>>>>>>>   According to javadoc of 
>>>>>>> AccessibleComponent.getLocationOnScreen, it returns null instead 
>>>>>>> of throwing IllegalComponentStateException when the 
>>>>>>> corresponding GUI object is not visible.
>>>>>>>   However, two accessibility inner classes of JTable, 
>>>>>>> JTable$AccessibleJTable$AccessibleJTableCell and 
>>>>>>> Table$AccessibleJTable$AccessibleJTableHeaderCell implementing 
>>>>>>> AccessibleComponent throw IllegalComponentStateException when 
>>>>>>> the corresponding JTable is not visible.  This behavior 
>>>>>>> conflicts with the spec.
>>>>>>>   I have submitted a bug in sunbug system reporting the issue, 
>>>>>>> and received two acknowledgement emails (bug id 7188613 and 
>>>>>>> 7188612, don't know why there are two?).  I created a patch to 
>>>>>>> fix the issue with a jtreg test case. Both the patch and the 
>>>>>>> test are uploaded into the following space.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-491/webrev.02/
>>>>>>>
>>>>>>>   Would anyone help to review the patch?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Frank
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Mon Aug 20 12:22:07 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 20 Aug 2012 16:22:07 +0400
Subject: <Swing Dev>  [8] Review request for <CR> <description>
Message-ID: <50322BEF.6010006@oracle.com>

Hello,

Please review a fix for the following issue:
   bug 6866747 J2SE_Swing_Reg:can not see any HSB tab
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6866747

The webrev is here: http://cr.openjdk.java.net/~rupashka/6866747/ 
<http://cr.openjdk.java.net/%7Erupashka/6866747/>

Evaluation: The test checks fields with RGB values on HSB tab. Now HSB 
is renamed into HSV and there are no RGB fields on the new tab. So the 
test is outdated and should be removed at all.

Regards,
Pavel.



From alexandr.scherbatiy at oracle.com  Mon Aug 20 13:20:44 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 20 Aug 2012 17:20:44 +0400
Subject: <Swing Dev> [8] Review request for <CR> <description>
In-Reply-To: <50322BEF.6010006@oracle.com>
References: <50322BEF.6010006@oracle.com>
Message-ID: <503239AC.2070209@oracle.com>


   The fix looks good for me.

On 8/20/2012 4:22 PM, Pavel Porvatov wrote:
> Hello,
>
> Please review a fix for the following issue:
>   bug 6866747 J2SE_Swing_Reg:can not see any HSB tab
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6866747
>
> The webrev is here: http://cr.openjdk.java.net/~rupashka/6866747/ 
> <http://cr.openjdk.java.net/%7Erupashka/6866747/>
>
> Evaluation: The test checks fields with RGB values on HSB tab. Now HSB 
> is renamed into HSV and there are no RGB fields on the new tab. So the 
> test is outdated and should be removed at all.
>
> Regards,
> Pavel.
>



From zhouyx at linux.vnet.ibm.com  Tue Aug 21 08:37:27 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 21 Aug 2012 16:37:27 +0800
Subject: <Swing Dev> Fwd: Add keyboard accessibility to JColorChooser
	swatch
In-Reply-To: <502CFD03.3050808@oracle.com>
References: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>
	<CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>
	<502CFD03.3050808@oracle.com>
Message-ID: <CAOo=rxW7=e2FadEFHE1QMNF7OJ31fSw5XBnSODa0eGKB8i-Caw@mail.gmail.com>

Hi Pavel,

     I updated the patch according to your comments except No.1 and No.4,
it is now at:  http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.03/  .

     About comment No.1 ( When right-to-left orientation the Recent
swatches inverts right and left button ), I tried to set the locale to
ar_AE, but didn't get a visual result about what I should do, please look
at http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_3.png  .  Can
anyone give a little help on how to produce a right-to-left orientation in
demo SwingSet2 or others?

     About comment No.4(Why new listeners are Serializable ), the original
MouseListeners in this class are Serializable  and I see javadoc for
Component class says "Developers will need, as always, to consider the
implications of making an object serializable" .

     Please take a look again, thanks.

On Thu, Aug 16, 2012 at 10:00 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

> **
> Hi Sean,
>
>
>  Updated the repository used in webrev from jdk8-tl to
> http://hg.openjdk.java.net/jdk8/awt/jdk  .
>
>  new webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.01/
>
>  I have the following comments about the fix:
>
> 1. When right-to-left orientation the Recent swatches inverts right and
> left button.
> 2. Could you please don't use package visibility when fileds/methods/inner
> classes can be private (e.g. field mainSwatchKeyListener)
> 3. I think you should uninstall the introduced listeners in the
> DefaultSwatchChooserPanel#uninstallChooserPanel method
> 4. Why new listeners are Serializable?
> 5. I recommend to use if condition instead of switch/case blocks with one
> branch
> 6. Could you please rename selrow (and similar variables) into selRow
> 7. Can we use Component#isFocusOwner instead of supporting new variable
> showcursor?
> 8. Could you please follow our code guide lines (spaces etc)
>
> Regards, Pavel
>
>
>
> ---------- Forwarded message ----------
> From: Sean Chou <zhouyx at linux.vnet.ibm.com>
> Date: Thu, Aug 9, 2012 at 3:29 PM
> Subject: <Swing Dev> Add keyboard accessibility to JColorChooser swatch
> To: swing-dev at openjdk.java.net
>
>
> Hi all,
>
>      This is a patch to add keyboard accessibility to JColorChooser
> swatch, so when using TAB, the focus can move to SwatchPanel, choose color
> with arrow keys and select color with space bar.
>
>  In current implementation, it is not able to move the focus
> to SwatchPanel with TAB, this can be seen in SwingSet2 demo.
> Steps:
> 1. run SwingSet2 demo
> 2. click on JColorChooser demo
> 3. click Background button and Swatches panel appears.
> 4. Press Tab key     =>   focus moves to OK button as shown in this image
> http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png
>
>  With this patch, in step4, focus moves to SwatchPanel, as shown here
> http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png
>  Then, arrow keys can be used to choose color and select color by space
> bar.
>
>  The webrev is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/  .
>
>  Please take a look.
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120821/127b7087/attachment.html>

From ankit.gupta2801 at gmail.com  Tue Aug 21 22:34:37 2012
From: ankit.gupta2801 at gmail.com (Ankit Gupta)
Date: Tue, 21 Aug 2012 15:34:37 -0700
Subject: <Swing Dev> Implementing a Text component to hold other components
Message-ID: <CAE3noLrg5fGVd6qrr7wgzNsD93db=-T_TJUNQVJtfbmCPaPz8w@mail.gmail.com>

I am trying to implement a text component that can hold other components.
To be concrete, lets say I want to have a text field that can have parts of
text being clickable while the document still remaining editable as normal.

Now, when I click that part of text that is clickable, I should be able to
handle the events like a JButton.

What I already tried?
I tried using JEditorPane with HTMLEditorKit to include a button using this
html code for the text of the pane:

<object classid='javax.swing.JButton' label='Click Me!' ></object>

However, the button rendered does not blend very well with the look and
feel of the document itself. Additionally, when the pane is editable it
gets really hard to edit text around the button.

As far as my understanding, there does not exist, anything like the one
that I am looking for. So, I am willing to implement such a component.
Hence, I would like you, if possible to advice me on how implement a
component that fits well with the Swing architecture and any caveats that I
might need to address while implementing this. (Basically, I am up for all
sorts of suggestions!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120821/a0df9619/attachment.html>

From Vladislav.Karnaukhov at oracle.com  Wed Aug 22 10:21:40 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 22 Aug 2012 14:21:40 +0400
Subject: <Swing Dev> <SwingDev> [7] Review request for 7167780: Hang
	javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
Message-ID: <5034B2B4.4010109@oracle.com>

Hello,

please review a fix for CR 7167780: Hang 
javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests

bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167780
webrev: http://cr.openjdk.java.net/~vkarnauk/7167780/webrev.00/

This is a backport from JDK8. This is also a customer escalated issue.

Regards,
- Vlad


From alexandr.scherbatiy at oracle.com  Wed Aug 22 12:21:49 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 22 Aug 2012 16:21:49 +0400
Subject: <Swing Dev> <SwingDev> [7] Review request for 7167780: Hang
	javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
In-Reply-To: <5034B2B4.4010109@oracle.com>
References: <5034B2B4.4010109@oracle.com>
Message-ID: <5034CEDD.2080108@oracle.com>


   The fix looks good for me.

   Thanks,
   Alexandr.

On 8/22/2012 2:21 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> please review a fix for CR 7167780: Hang 
> javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
>
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167780
> webrev: http://cr.openjdk.java.net/~vkarnauk/7167780/webrev.00/
>
> This is a backport from JDK8. This is also a customer escalated issue.
>
> Regards,
> - Vlad



From pavel.porvatov at oracle.com  Wed Aug 22 13:16:08 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 22 Aug 2012 17:16:08 +0400
Subject: <Swing Dev> Fwd: Add keyboard accessibility to JColorChooser
 swatch
In-Reply-To: <CAOo=rxW7=e2FadEFHE1QMNF7OJ31fSw5XBnSODa0eGKB8i-Caw@mail.gmail.com>
References: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>	<CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>	<502CFD03.3050808@oracle.com>
	<CAOo=rxW7=e2FadEFHE1QMNF7OJ31fSw5XBnSODa0eGKB8i-Caw@mail.gmail.com>
Message-ID: <5034DB98.60204@oracle.com>

Hi Sean,
> Hi Pavel,
>
>      I updated the patch according to your comments except No.1 and 
> No.4, it is now at: 
>  http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.03/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/webrev.03/>  .  
>
>      About comment No.1 ( When right-to-left orientation the Recent 
> swatches inverts right and left button ), I tried to set the locale to 
> ar_AE, but didn't get a visual result about what I should do, please 
> look at http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_3.png 
> <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/screenshot_3.png>  . 
>  Can anyone give a little help on how to produce a right-to-left 
> orientation in demo SwingSet2 or others?
I attached the test. It will be useful to add some tests to your change 
(e.g. show JColorChooser with right-to-left orientation, pressing some 
keys by awt Robot and checking the result)
>
>      About comment No.4(Why new listeners are Serializable ), the 
> original MouseListeners in this class are Serializable  and I see 
> javadoc for Component class says "Developers will need, as always, to 
> consider the implications of making an object serializable" .
You are absolutely right about serialization. But if you take a look at 
components serialization/deserialization you will see that BEFORE 
serialization javax.swing.plaf.ComponentUI#uninstallUI is invoked and 
AFTER deserialization javax.swing.plaf.ComponentUI#installUI is invoked. 
So serialization is not broken when new listeners added and removed 
correctly with instalUI/uninstallUI methods.

>
>      Please take a look again, thanks.
Some additional comments below:
1. You should assign null to mainSwatchKeyListener and 
recentSwatchKeyListener in the uninstallChooserPanel method
2. Do we have bug in bugs database for your fix? If no, could you please 
file a bug with correspondent description. Use that bug number as a 
folder name for the webrev, please
3. The code can be a little bit optimized. There is no need to call 
repaint every time in code like this:
+                        if (selRow > 0) {
+                            selRow--;
+                        }
+                        repaint();

I'd prefer
+                        if (selRow > 0) {
+                            selRow--;
+                            repaint();
+                        }
In case KeyEvent.VK_HOME and KeyEvent.VK_END such optimization doesn't 
look reasonable for me...
4. Could you please follow our code guide lines (spaces etc).
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html
5. I have some concerns about selection mark in paintComponent:
a. On light swatches (e.g. on white) the mark looks like it shifted on 1 
pixel
b. The color selection looks tricky. Does the following code from 
DiagramComponent#paintComponent works
            g.setXORMode(Color.WHITE);
            g.setColor(Color.BLACK);
?

Regards, Pavel
> On Thu, Aug 16, 2012 at 10:00 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>>
>>     Updated the repository used in webrev from jdk8-tl
>>     to http://hg.openjdk.java.net/jdk8/awt/jdk  .
>>
>>     new webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.01/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/webrev.01/> 
>>
>     I have the following comments about the fix:
>
>     1. When right-to-left orientation the Recent swatches inverts
>     right and left button.
>     2. Could you please don't use package visibility when
>     fileds/methods/inner classes can be private (e.g. field
>     mainSwatchKeyListener)
>     3. I think you should uninstall the introduced listeners in the
>     DefaultSwatchChooserPanel#uninstallChooserPanel method
>     4. Why new listeners are Serializable?
>     5. I recommend to use if condition instead of switch/case blocks
>     with one branch
>     6. Could you please rename selrow (and similar variables) into selRow
>     7. Can we use Component#isFocusOwner instead of supporting new
>     variable showcursor?
>     8. Could you please follow our code guide lines (spaces etc)
>
>     Regards, Pavel
>
>
>>
>>     ---------- Forwarded message ----------
>>     From: *Sean Chou* <zhouyx at linux.vnet.ibm.com
>>     <mailto:zhouyx at linux.vnet.ibm.com>>
>>     Date: Thu, Aug 9, 2012 at 3:29 PM
>>     Subject: <Swing Dev> Add keyboard accessibility to JColorChooser
>>     swatch
>>     To: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>
>>
>>     Hi all,
>>
>>         This is a patch to add keyboard accessibility to
>>     JColorChooser swatch, so when using TAB, the focus can move
>>     to SwatchPanel, choose color with arrow keys and select color
>>     with space bar. 
>>
>>     In current implementation, it is not able to move the focus
>>     to SwatchPanel with TAB, this can be seen in SwingSet2 demo. 
>>     Steps: 
>>     1. run SwingSet2 demo 
>>     2. click on JColorChooser demo
>>     3. click Background button and Swatches panel appears.
>>     4. Press Tab key     =>   focus moves to OK button as shown in
>>     this
>>     image http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png
>>     <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/screenshot_1.png>
>>
>>     With this patch, in step4, focus moves to SwatchPanel, as shown
>>     here http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png
>>     <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/screenshot_2.png>
>>     Then, arrow keys can be used to choose color and select color by
>>     space bar.
>>
>>     The webrev
>>     is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/OJDK-61/webrev.00/>  . 
>>
>>     Please take a look.
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>>
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120822/6a3b0f5f/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JColorChooserTest.java
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120822/6a3b0f5f/JColorChooserTest.java>

From jeff at reportmill.com  Thu Aug 23 20:55:59 2012
From: jeff at reportmill.com (Jeff Martin)
Date: Thu, 23 Aug 2012 15:55:59 -0500
Subject: <Swing Dev> How to search for a JRE 7 Mac Bug?
Message-ID: <BE5EF4CA-0F3C-4A46-A59B-0F7F479CA54B@reportmill.com>

How do I search for known JRE 7 Swing bugs (or file one)?

I find that in JRE7 for Mac, if you have a JProgressBar set to Indeterminate that is hanging around off screen, it sends constant timer events.

jeff



From Sergey.Bylokhov at oracle.com  Thu Aug 23 22:11:14 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 24 Aug 2012 02:11:14 +0400
Subject: <Swing Dev> How to search for a JRE 7 Mac Bug?
In-Reply-To: <BE5EF4CA-0F3C-4A46-A59B-0F7F479CA54B@reportmill.com>
References: <BE5EF4CA-0F3C-4A46-A59B-0F7F479CA54B@reportmill.com>
Message-ID: <5036AA82.3000207@oracle.com>

Hi, Jeff.
You can try to use:
http://bugs.sun.com/bugdatabase/

Probably some related issues:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168926
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124525

24.08.2012 00:55, Jeff Martin wrote:
> How do I search for known JRE 7 Swing bugs (or file one)?
>
> I find that in JRE7 for Mac, if you have a JProgressBar set to Indeterminate that is hanging around off screen, it sends constant timer events.
>
> jeff
>


-- 
Best regards, Sergey.



From jeff at reportmill.com  Thu Aug 23 23:45:15 2012
From: jeff at reportmill.com (Jeff Martin)
Date: Thu, 23 Aug 2012 18:45:15 -0500
Subject: <Swing Dev> How to search for a JRE 7 Mac Bug?
In-Reply-To: <5036AA82.3000207@oracle.com>
References: <BE5EF4CA-0F3C-4A46-A59B-0F7F479CA54B@reportmill.com>
	<5036AA82.3000207@oracle.com>
Message-ID: <8C86FAAB-D4F3-4E4F-8407-E741F3F4A365@reportmill.com>

Thanks! I filed the bug but it isn't available quite yet: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193703

My situation is probably unique because my JProgressBar sometimes doesn't get shown onscreen. I found a work around though, which is to call updateUI() on it after setIndeterminate(true) - this stops the timer plus InvocationEvents. I've attached my sample code below.

jeff


On Aug 23, 2012, at 5:11 PM, Sergey Bylokhov wrote:

> Hi, Jeff.
> You can try to use:
> http://bugs.sun.com/bugdatabase/
> 
> Probably some related issues:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168926
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124525
> 
> 24.08.2012 00:55, Jeff Martin wrote:
>> How do I search for known JRE 7 Swing bugs (or file one)?
>> 
>> I find that in JRE7 for Mac, if you have a JProgressBar set to Indeterminate that is hanging around off screen, it sends constant timer events.
>> 
>> jeff

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import javax.swing.SwingUtilities;

/**
 * A class to show JProgressBar bug on Mac OS.
 */
public class ProgressBarBug extends EventQueue {

    static JProgressBar _pb = new JProgressBar();
    
public static void main(final String args[])
{
    if(!SwingUtilities.isEventDispatchThread()) {
        SwingUtilities.invokeLater(new Runnable() { public void run() { main(args); }}); return; }

    // Create a ProgressBar offscreen, setIndeterminate (turn it off) and hold on to ProgressBar
    _pb = new JProgressBar(); _pb.setIndeterminate(true); // This starts timer, even though offscreen or turned off
    _pb.setIndeterminate(false); //_pb.updateUI(); <- This stops the timer

    // Register EventQueue to print non-stop timer InvocationEvents
    try { Toolkit.getDefaultToolkit().getSystemEventQueue().push(new ProgressBarBug()); }
    catch(Exception e) { throw new RuntimeException(e); }

    // Create and show window to keep app around
    new JFrame("Test Frame").setVisible(true);
}

// This method shows all the non-stop timer InvocationEvents
public void dispatchEvent(AWTEvent anEvent)
{
    if(anEvent instanceof InvocationEvent) System.out.println(anEvent);
    super.dispatchEvent(anEvent);
}

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

From zhouyx at linux.vnet.ibm.com  Mon Aug 27 06:53:21 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 27 Aug 2012 14:53:21 +0800
Subject: <Swing Dev> Fwd: Add keyboard accessibility to JColorChooser
	swatch
In-Reply-To: <5034DB98.60204@oracle.com>
References: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>
	<CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>
	<502CFD03.3050808@oracle.com>
	<CAOo=rxW7=e2FadEFHE1QMNF7OJ31fSw5XBnSODa0eGKB8i-Caw@mail.gmail.com>
	<5034DB98.60204@oracle.com>
Message-ID: <CAOo=rxW0qP6E+D5oC3ZhNL-pottYNym9wnXKA-1YSrJGn_tVVQ@mail.gmail.com>

Hi Pavel,

     Modifications except the auto testcase are done, I'm still working on
the testcase.
Please take a look at http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.04/ .

About code convention, I modified spaces beside +/- operations in paint
method(it was not added because the code above doesn't have spaces).

I tried the " g.setXORMode(Color.WHITE); g.setColor(Color.BLACK); " (it is
only commented out in the patch, I'll remove it in later versions with
testcase), the mark is not obvious for light blue-pink area and dark green
area, as this image:
http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_4.png . And it will
also delete the right and bottom line. So, the current color for mark looks
better.


On Wed, Aug 22, 2012 at 9:16 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

> **
> Hi Sean,
>
> Hi Pavel,
>
>       I updated the patch according to your comments except No.1 and
> No.4, it is now at:  http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.03/ .
>
>       About comment No.1 ( When right-to-left orientation the Recent
> swatches inverts right and left button ), I tried to set the locale to
> ar_AE, but didn't get a visual result about what I should do, please look
> at http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_3.png  .  Can
> anyone give a little help on how to produce a right-to-left orientation in
> demo SwingSet2 or others?
>
> I attached the test. It will be useful to add some tests to your change
> (e.g. show JColorChooser with right-to-left orientation, pressing some keys
> by awt Robot and checking the result)
>
>
>       About comment No.4(Why new listeners are Serializable ), the
> original MouseListeners in this class are Serializable  and I see javadoc
> for Component class says "Developers will need, as always, to consider the
> implications of making an object serializable" .
>
> You are absolutely right about serialization. But if you take a look at
> components serialization/deserialization you will see that BEFORE
> serialization javax.swing.plaf.ComponentUI#uninstallUI is invoked and AFTER
> deserialization javax.swing.plaf.ComponentUI#installUI is invoked. So
> serialization is not broken when new listeners added and removed correctly
> with instalUI/uninstallUI methods.
>
>
>
>       Please take a look again, thanks.
>
> Some additional comments below:
> 1. You should assign null to mainSwatchKeyListener and
> recentSwatchKeyListener in the uninstallChooserPanel method
> 2. Do we have bug in bugs database for your fix? If no, could you please
> file a bug with correspondent description. Use that bug number as a folder
> name for the webrev, please
> 3. The code can be a little bit optimized. There is no need to call
> repaint every time in code like this:
> +                        if (selRow > 0) {
> +                            selRow--;
> +                        }
> +                        repaint();
>
> I'd prefer
> +                        if (selRow > 0) {
> +                            selRow--;
> +                            repaint();
> +                        }
> In case KeyEvent.VK_HOME and KeyEvent.VK_END such optimization doesn't
> look reasonable for me...
> 4. Could you please follow our code guide lines (spaces etc).
>
> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html
> 5. I have some concerns about selection mark in paintComponent:
> a. On light swatches (e.g. on white) the mark looks like it shifted on 1
> pixel
> b. The color selection looks tricky. Does the following code from
> DiagramComponent#paintComponent works
>             g.setXORMode(Color.WHITE);
>             g.setColor(Color.BLACK);
> ?
>
> Regards, Pavel
>
>  On Thu, Aug 16, 2012 at 10:00 PM, Pavel Porvatov <
> pavel.porvatov at oracle.com> wrote:
>
>>  Hi Sean,
>>
>>
>>  Updated the repository used in webrev from jdk8-tl to
>> http://hg.openjdk.java.net/jdk8/awt/jdk  .
>>
>>  new webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.01/
>>
>>  I have the following comments about the fix:
>>
>> 1. When right-to-left orientation the Recent swatches inverts right and
>> left button.
>> 2. Could you please don't use package visibility when
>> fileds/methods/inner classes can be private (e.g. field
>> mainSwatchKeyListener)
>> 3. I think you should uninstall the introduced listeners in the
>> DefaultSwatchChooserPanel#uninstallChooserPanel method
>> 4. Why new listeners are Serializable?
>> 5. I recommend to use if condition instead of switch/case blocks with one
>> branch
>> 6. Could you please rename selrow (and similar variables) into selRow
>> 7. Can we use Component#isFocusOwner instead of supporting new variable
>> showcursor?
>> 8. Could you please follow our code guide lines (spaces etc)
>>
>> Regards, Pavel
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Sean Chou <zhouyx at linux.vnet.ibm.com>
>> Date: Thu, Aug 9, 2012 at 3:29 PM
>> Subject: <Swing Dev> Add keyboard accessibility to JColorChooser swatch
>> To: swing-dev at openjdk.java.net
>>
>>
>> Hi all,
>>
>>      This is a patch to add keyboard accessibility to JColorChooser
>> swatch, so when using TAB, the focus can move to SwatchPanel, choose color
>> with arrow keys and select color with space bar.
>>
>>  In current implementation, it is not able to move the focus
>> to SwatchPanel with TAB, this can be seen in SwingSet2 demo.
>> Steps:
>> 1. run SwingSet2 demo
>> 2. click on JColorChooser demo
>> 3. click Background button and Swatches panel appears.
>> 4. Press Tab key     =>   focus moves to OK button as shown in this image
>> http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png
>>
>>  With this patch, in step4, focus moves to SwatchPanel, as shown here
>> http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png
>>  Then, arrow keys can be used to choose color and select color by space
>> bar.
>>
>>  The webrev is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/  .
>>
>>  Please take a look.
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>
> import javax.swing.*;
> import java.awt.*;
>
> public class JColorChooserTest {
>     public static void main(String[] args) {
>         SwingUtilities.invokeLater(new Runnable() {
>             @Override
>             public void run() {
>                 JFrame frame = new JFrame();
>
>                 JColorChooser chooser = new JColorChooser();
>
> chooser.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
>                 frame.add(chooser);
>
>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>                 frame.setSize(600, 400);
>                 frame.setVisible(true);
>             }
>         });
>     }
> }
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120827/285b3287/attachment.html>

From Vladislav.Karnaukhov at oracle.com  Mon Aug 27 12:59:17 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 27 Aug 2012 16:59:17 +0400
Subject: <Swing Dev> [7] Review request for 7123767 Wrong tooltip
 location in Multi-Monitor configurations
In-Reply-To: <502E7B01.1050801@oracle.com>
References: <5016903D.8010104@oracle.com> <502E7B01.1050801@oracle.com>
Message-ID: <503B6F25.9030009@oracle.com>

Hi Pavel, all,

please find new webrev here: 
http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.02/
Please see my comments inline.

Regards,
- Vlad

On 8/17/2012 9:10 PM, Pavel Porvatov wrote:
> Hi Vladislav,
>
> I have several comments about the fix:
>
> 1. javax.swing.ToolTipManager#showTipWindow: I think toFind variable 
> should be initialized in if(preferredLocation != null) { ....} else 
> {...} block. It looks more logical and code will be more compact 
> (adjustedPreferredLocation can be removed at all, I think)
Agreed. I've re-worked this piece.

>
> 2. Could you please explain why you are using union of all rectangles 
> in the getDrawingRect method? In case two monitors are aligned on a 
> diagonal totalRect will contain areas that are not covered by screen 
> devices and popups can be placed incorrectly.
Agreed again. I've re-designed getDrawingRect() function and placed 
additional condition into showTipWindow() function; now every situation 
should be handled correctly.

Automated test was added, please see the webrev.

Regards,
- Vlad

>
> Regards, Pavel
>
>> Hello,
>>
>> please review the fix for 7123767: Wrong tooltip location in 
>> Multi-Monitor configurations
>>
>> jdk7 webrev: http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.00/
>> test source: http://cr.openjdk.java.net/~vkarnauk/7123767/test/
>> bug description: 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123767
>>
>> This is also a customer escalated issue in jdk6.
>>
>> On multi-monitor configurations Component.getLocationOnScreen() may 
>> return negative values. Additionally, ToolTipManager.showTipWindow() 
>> method calculates tip window location from Component' 
>> getLocationOnScreen() return data and draws tip window using the same 
>> GraphicsConfiguration instance as component's top-left corner, which 
>> again can be of negative value. When component is stretched across 
>> multiple screen devices, this may lead to a situation when it's 
>> tooltip is drawn on wrong monitor.
>>
>> To fix this we should count all GraphicsConfiguration instances and 
>> determine correct screen device to draw on. We should also take into 
>> account that:
>> 1) tip window preferred location could be set
>> 2) preferred location could be greater than total virtual bounds of 
>> all monitors. To make tip window visible in such case we move it to 
>> the corresponding corner of total virtual bounds
>> 3) exact order of monitors (left-to-right and top-to-bottom) is unknown
>>
>> I run jtreg against ToolTipManager tests and all tests passed (I run 
>> it several times with different monitor configurations). I also 
>> tested the fix with custom test program (please see the link 
>> provided) with 4 possible monitor configurations (left-to-right, 
>> right-to-left, top-to-bottom and bottom-to-top) and saw no issues.
>>
>> I added no new automated test(s) because this at least would require 
>> multiple monitors to run.
>>
>> Regards,
>> - Vlad
>




From Vladislav.Karnaukhov at oracle.com  Mon Aug 27 13:00:20 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 27 Aug 2012 17:00:20 +0400
Subject: <Swing Dev> <SwingDev> [7] Review request for 7167780: Hang
	javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
In-Reply-To: <5034B2B4.4010109@oracle.com>
References: <5034B2B4.4010109@oracle.com>
Message-ID: <503B6F64.4010009@oracle.com>

Hello,

did anyone get a chance to review this?

Regards,
- Vlad

On 8/22/2012 2:21 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> please review a fix for CR 7167780: Hang 
> javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
>
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167780
> webrev: http://cr.openjdk.java.net/~vkarnauk/7167780/webrev.00/
>
> This is a backport from JDK8. This is also a customer escalated issue.
>
> Regards,
> - Vlad




From Vladislav.Karnaukhov at oracle.com  Mon Aug 27 13:24:37 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 27 Aug 2012 17:24:37 +0400
Subject: <Swing Dev> <SwingDev> [7] Review request for 7167780: Hang
	javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
In-Reply-To: <503B6F64.4010009@oracle.com>
References: <5034B2B4.4010109@oracle.com> <503B6F64.4010009@oracle.com>
Message-ID: <503B7515.20607@oracle.com>

Just noticed Alexander's reply... Thanks a lot!

- Vlad

On 8/27/2012 5:00 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> did anyone get a chance to review this?
>
> Regards,
> - Vlad
>
> On 8/22/2012 2:21 PM, Vladislav Karnaukhov wrote:
>> Hello,
>>
>> please review a fix for CR 7167780: Hang 
>> javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
>>
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167780
>> webrev: http://cr.openjdk.java.net/~vkarnauk/7167780/webrev.00/
>>
>> This is a backport from JDK8. This is also a customer escalated issue.
>>
>> Regards,
>> - Vlad
>
>




From pavel.porvatov at oracle.com  Mon Aug 27 13:36:27 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 27 Aug 2012 17:36:27 +0400
Subject: <Swing Dev> <SwingDev> [7] Review request for 7167780: Hang
	javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
In-Reply-To: <503B6F64.4010009@oracle.com>
References: <5034B2B4.4010109@oracle.com> <503B6F64.4010009@oracle.com>
Message-ID: <503B77DB.5060701@oracle.com>

Hi Vladislav,

As I remember Alexandr Scherbatiy has approved your fix. The fix looks 
good for me as well

Regards, Pavel
> Hello,
>
> did anyone get a chance to review this?
>
> Regards,
> - Vlad
>
> On 8/22/2012 2:21 PM, Vladislav Karnaukhov wrote:
>> Hello,
>>
>> please review a fix for CR 7167780: Hang 
>> javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
>>
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167780
>> webrev: http://cr.openjdk.java.net/~vkarnauk/7167780/webrev.00/
>>
>> This is a backport from JDK8. This is also a customer escalated issue.
>>
>> Regards,
>> - Vlad
>
>



From Vladislav.Karnaukhov at oracle.com  Mon Aug 27 14:51:51 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 27 Aug 2012 18:51:51 +0400
Subject: <Swing Dev> <Swind Dev> [7] Review request for 6836089: Swing
 HTML parser can't properly decode codepoints outside the Unicode Plane 0
 into a surrogate pair
In-Reply-To: <4FECD620.8000106@oracle.com>
References: <4FE82651.7050302@oracle.com> <4FE878F6.1000907@oracle.com>
	<4FE966D6.5050504@oracle.com> <4FE9F643.9060001@oracle.com>
	<4FEB4B0F.8080406@oracle.com> <4FEB4D30.5070400@oracle.com>
	<4FEC7124.6060403@oracle.com> <4FECD620.8000106@oracle.com>
Message-ID: <503B8987.3040004@oracle.com>

Hello,

could you please review a new version?
Please find webrev here: 
http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.04/

Regards,
- Vlad

On 6/29/2012 2:09 AM, Phil Race wrote:
> That would work but I think its cleaner to just move it all into 
> mapNumericReference
> as below.
>
> -phil.
>
> diff --git 
> a/src/share/classes/javax/swing/text/html/parser/Parser.java 
> b/src/share/classes/javax/swing/text/html/parser/Parser.java
> --- a/src/share/classes/javax/swing/text/html/parser/Parser.java
> +++ b/src/share/classes/javax/swing/text/html/parser/Parser.java
> @@ -952,7 +952,7 @@
>                          ch = readCh();
>                          break;
>                  }
> -                char data[] = {mapNumericReference((char) n)};
> +                char data[] = mapNumericReference(n);
>                  return data;
>              }
>              addString('#');
> @@ -1021,7 +1021,7 @@
>      }
>
>      /**
> -     * Converts numeric character reference to Unicode character.
> +     * Converts numeric character reference to char array.
>       *
>       * Normally the code in a reference should be always converted
>       * to the Unicode character with the same code, but due to
> @@ -1030,13 +1030,21 @@
>       * to displayable characters with other codes.
>       *
>       * @param c the code of numeric character reference.
> -     * @return the character corresponding to the reference code.
> +     * @return a char array corresponding to the reference code.
>       */
> -    private char mapNumericReference(char c) {
> -        if (c < 130 || c > 159) {
> -            return c;
> +    private char[] mapNumericReference(int c) {
> +        char[] data;
> +        if (c >= 0xffff) { // outside unicode BMP.
> +            try {
> +                data = Character.toChars(c);
> +            } catch (IllegalArgumentException e) {
> +                data = new char[0];
>          }
> -        return cp1252Map[c - 130];
> +        } else {
> +            data = new char[1];
> +            data[0] = (c < 130 || c > 159) ? (char)c : cp1252Map[c - 
> 130];
> +        }
> +        return data;
>      }
>
>
> On 06/28/12 07:58 AM, Vladislav Karnaukhov wrote:
>> Hello Phil, Pavel,
>>
>> thank you for your comments. I've reworked fix and testcase, please 
>> find new webrev here: 
>> http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.03/
>>
>> Regards,
>> - Vlad
>>
>> On 6/27/2012 10:13 PM, Phil Race wrote:
>>> Well its not only unnecessary but is likely wrong .. I don't think
>>> you looked at what mapNumericReference() does.
>>>
>>> -phil.
>>>
>>> On 6/27/2012 11:03 AM, Vladislav Karnaukhov wrote:
>>>> Hello Phil,
>>>>
>>>> I used Character.toChars() in both branches because I wanted to 
>>>> delegate code point conversion to char or surrogate pair entirely 
>>>> to Character class...
>>>>
>>>> Regards,
>>>> - Vlad
>>>>
>>>> On 6/26/2012 9:49 PM, Phil Race wrote:
>>>>> I don't understand why you call Character.toChars() if you've just 
>>>>> determined
>>>>> you don't need to ?
>>>>>
>>>>> ie what was wrong with
>>>>>
>>>>> data = ( n >>> 16 == 0) ? {mapNumericReference((char) n)} : 
>>>>> Character.toChars(n);
>>>>>
>>>>> ?
>>>>>
>>>>> In the case of an invalid supplementary pair, maybe it would be 
>>>>> safer to  return { ' ' } ?
>>>>>
>>>>>
>>>>> One thing I see in the parsing code that is not new or changed 
>>>>> here, that
>>>>> may bear examination, is that there's a loop that keeps on reading 
>>>>> so long
>>>>> so long there are new digits. I am not sure its wise to keep going 
>>>>> once
>>>>> you overflow.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 6/26/2012 12:37 AM, Vladislav Karnaukhov wrote:
>>>>>> Hello Pavel,
>>>>>>
>>>>>> I can provide you with the link to 6u19, but this is direct 
>>>>>> forward-port and no code changes were made.
>>>>>>
>>>>>> I'll make changes as you've pointed out in 1) and 2)
>>>>>>
>>>>>> About 3) - is it a requirement to use "? :" operator? I 
>>>>>> personally prefer single-line if-else, but I don't want to argue 
>>>>>> over code style, and surely I'll follow code design practices.
>>>>>>
>>>>>> Regards,
>>>>>> - Vlad
>>>>>>
>>>>>> On 6/25/2012 6:43 PM, Pavel Porvatov wrote:
>>>>>>> Hi Vladislav,
>>>>>>>
>>>>>>> Do you have a link to the fix for 6u19?
>>>>>>>
>>>>>>> I didn't investigate the fix deeply, but
>>>>>>>
>>>>>>> 1.
>>>>>>>  private final int MAX_BMP_BOUND = 65535;
>>>>>>> should be static (otherwise variable name should be in lower case)
>>>>>>>
>>>>>>> 2. Add a space in single line comments
>>>>>>>
>>>>>>> 3.
>>>>>>> +                    char data[];
>>>>>>> +                    if (n <= MAX_BMP_BOUND) {
>>>>>>> +                        data = 
>>>>>>> Character.toChars(mapNumericReference((char) n));
>>>>>>> +                    } else {
>>>>>>> +                        data = Character.toChars(n);
>>>>>>> +                    }
>>>>>>> +
>>>>>>>                  return data;
>>>>>>>
>>>>>>> can be written in one line via "? :" operator and looks more 
>>>>>>> readable for me
>>>>>>>
>>>>>>> Thanks, Pavel
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> please review the fix for 6836089: Swing HTML parser can't 
>>>>>>>> properly decode codepoints outside the Unicode Plane 0 into a 
>>>>>>>> surrogate pair. This is a forward port from JDK6 (fixed 
>>>>>>>> escalated issue, fix integrated) to JDK7.
>>>>>>>>
>>>>>>>> The issue is a defect in Swing HTML Parser: if the codepoint is 
>>>>>>>> outside BMP (Unicode Plain 0), Parser incorrectly decodes 
>>>>>>>> codepoint into surrogate pair. The fix is to use 
>>>>>>>> Character.toChars() method if codepoint value is greater than 
>>>>>>>> upper bound of BMP.
>>>>>>>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.00/
>>>>>>>> Bug description: 
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6836089
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> - Vlad
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>




From anton.litvinov at oracle.com  Tue Aug 28 16:15:57 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 28 Aug 2012 20:15:57 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
Message-ID: <503CEEBD.8070307@oracle.com>

Hello,

Please review the following fix for a bug.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01

For details on this bug please look at "Evaluation" field on a web page 
of this bug. The provided webrev contains both a fix and a corresponding 
unit-test. Before publishing this webrev all unit-tests from the 
"java.awt" and
"javax.swing" related to serialization were run and no negative changes 
were observed comparing the results of tests' runs on JDK with and 
without patch represented by this webrev.

This is the second version of the fix. The first version was submitted 
to the AWT development group through a review request with the same 
subject and after discussion with engineers and additional investigation 
of the problem it was decided to apply the fix in Swing part of JDK.

Thank you,
Anton


From anthony.petrov at oracle.com  Tue Aug 28 16:42:05 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 28 Aug 2012 20:42:05 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503CEEBD.8070307@oracle.com>
References: <503CEEBD.8070307@oracle.com>
Message-ID: <503CF4DD.8000801@oracle.com>

Hi Anton,

The fix looks good to me.

--
best regards,
Anthony

On 8/28/2012 8:15 PM, Anton Litvinov wrote:
> Hello,
> 
> Please review the following fix for a bug.
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
> 
> For details on this bug please look at "Evaluation" field on a web page 
> of this bug. The provided webrev contains both a fix and a corresponding 
> unit-test. Before publishing this webrev all unit-tests from the 
> "java.awt" and
> "javax.swing" related to serialization were run and no negative changes 
> were observed comparing the results of tests' runs on JDK with and 
> without patch represented by this webrev.
> 
> This is the second version of the fix. The first version was submitted 
> to the AWT development group through a review request with the same 
> subject and after discussion with engineers and additional investigation 
> of the problem it was decided to apply the fix in Swing part of JDK.
> 
> Thank you,
> Anton


From pavel.porvatov at oracle.com  Tue Aug 28 17:45:31 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 28 Aug 2012 21:45:31 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503CEEBD.8070307@oracle.com>
References: <503CEEBD.8070307@oracle.com>
Message-ID: <503D03BB.8080502@oracle.com>

Hi Anton,

The fix looks good but the test should be updated:

1. Is the following line needed for the test:
 63         frame.setVisible(true);
?
If yes then you should use SunToolkit.realSync to wait until frame 
become visible.
The same comment for the line
 85         frame.setVisible(true);

2. Are label and layout and layout needed for the test purpose? If no, 
can you remove unused components?

3. The following code looks strange (two titles?)
  45         JFrame frame = new JFrame("HelloWorldSwing");
...
  47         frame.setTitle("why why why");

4. The test method should be on the EDT

5. There is no need to use the mainPanel field. Logically it should be 
local variable

BTW: can you start with the fix for jdk8 and only then backport it to jdk7?

Regards, Pavel
> Hello,
>
> Please review the following fix for a bug.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>
> For details on this bug please look at "Evaluation" field on a web 
> page of this bug. The provided webrev contains both a fix and a 
> corresponding unit-test. Before publishing this webrev all unit-tests 
> from the "java.awt" and
> "javax.swing" related to serialization were run and no negative 
> changes were observed comparing the results of tests' runs on JDK with 
> and without patch represented by this webrev.
>
> This is the second version of the fix. The first version was submitted 
> to the AWT development group through a review request with the same 
> subject and after discussion with engineers and additional 
> investigation of the problem it was decided to apply the fix in Swing 
> part of JDK.
>
> Thank you,
> Anton



From zhouyx at linux.vnet.ibm.com  Wed Aug 29 07:58:18 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 29 Aug 2012 15:58:18 +0800
Subject: <Swing Dev> Fwd: Add keyboard accessibility to JColorChooser
	swatch
In-Reply-To: <5034DB98.60204@oracle.com>
References: <CAOo=rxXTqb1vv24+E7DDJCJAdNvjp10afJmcwem4EgFbO1+3_Q@mail.gmail.com>
	<CAOo=rxUouD10ugccfWhEEUZ0veuXy0Yq0Bmr3=Pr0924zX+qrw@mail.gmail.com>
	<502CFD03.3050808@oracle.com>
	<CAOo=rxW7=e2FadEFHE1QMNF7OJ31fSw5XBnSODa0eGKB8i-Caw@mail.gmail.com>
	<5034DB98.60204@oracle.com>
Message-ID: <CAOo=rxVRMQ9SU6BPzf47jdX7W8X4iAA4bW4Xs45dOCdSMUA_Ow@mail.gmail.com>

Hi Pavel,

    I uploaded http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.05/  . And
reported http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194184 .

Some details about update:
1. A testcase is added in this webrev, but it checks keyboard accessibility
only. I tried to check right-to-left orientation with the testcase
attached, but it doesn't work well on windows.

2. " g.setXORMode(Color.WHITE);    g.setColor(Color.BLACK); " is not used
because the mark is not obvious for light blue-pink area and dark green
area, as this image:
http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_4.png  .

Please take a look.

On Wed, Aug 22, 2012 at 9:16 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

> **
> Hi Sean,
>
> Hi Pavel,
>
>       I updated the patch according to your comments except No.1 and
> No.4, it is now at:  http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.03/ .
>
>       About comment No.1 ( When right-to-left orientation the Recent
> swatches inverts right and left button ), I tried to set the locale to
> ar_AE, but didn't get a visual result about what I should do, please look
> at http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_3.png  .  Can
> anyone give a little help on how to produce a right-to-left orientation in
> demo SwingSet2 or others?
>
> I attached the test. It will be useful to add some tests to your change
> (e.g. show JColorChooser with right-to-left orientation, pressing some keys
> by awt Robot and checking the result)
>
>
>       About comment No.4(Why new listeners are Serializable ), the
> original MouseListeners in this class are Serializable  and I see javadoc
> for Component class says "Developers will need, as always, to consider the
> implications of making an object serializable" .
>
> You are absolutely right about serialization. But if you take a look at
> components serialization/deserialization you will see that BEFORE
> serialization javax.swing.plaf.ComponentUI#uninstallUI is invoked and AFTER
> deserialization javax.swing.plaf.ComponentUI#installUI is invoked. So
> serialization is not broken when new listeners added and removed correctly
> with instalUI/uninstallUI methods.
>
>
>
>       Please take a look again, thanks.
>
> Some additional comments below:
> 1. You should assign null to mainSwatchKeyListener and
> recentSwatchKeyListener in the uninstallChooserPanel method
> 2. Do we have bug in bugs database for your fix? If no, could you please
> file a bug with correspondent description. Use that bug number as a folder
> name for the webrev, please
> 3. The code can be a little bit optimized. There is no need to call
> repaint every time in code like this:
> +                        if (selRow > 0) {
> +                            selRow--;
> +                        }
> +                        repaint();
>
> I'd prefer
> +                        if (selRow > 0) {
> +                            selRow--;
> +                            repaint();
> +                        }
> In case KeyEvent.VK_HOME and KeyEvent.VK_END such optimization doesn't
> look reasonable for me...
> 4. Could you please follow our code guide lines (spaces etc).
>
> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html
> 5. I have some concerns about selection mark in paintComponent:
> a. On light swatches (e.g. on white) the mark looks like it shifted on 1
> pixel
> b. The color selection looks tricky. Does the following code from
> DiagramComponent#paintComponent works
>             g.setXORMode(Color.WHITE);
>             g.setColor(Color.BLACK);
> ?
>
> Regards, Pavel
>
>  On Thu, Aug 16, 2012 at 10:00 PM, Pavel Porvatov <
> pavel.porvatov at oracle.com> wrote:
>
>>  Hi Sean,
>>
>>
>>  Updated the repository used in webrev from jdk8-tl to
>> http://hg.openjdk.java.net/jdk8/awt/jdk  .
>>
>>  new webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.01/
>>
>>  I have the following comments about the fix:
>>
>> 1. When right-to-left orientation the Recent swatches inverts right and
>> left button.
>> 2. Could you please don't use package visibility when
>> fileds/methods/inner classes can be private (e.g. field
>> mainSwatchKeyListener)
>> 3. I think you should uninstall the introduced listeners in the
>> DefaultSwatchChooserPanel#uninstallChooserPanel method
>> 4. Why new listeners are Serializable?
>> 5. I recommend to use if condition instead of switch/case blocks with one
>> branch
>> 6. Could you please rename selrow (and similar variables) into selRow
>> 7. Can we use Component#isFocusOwner instead of supporting new variable
>> showcursor?
>> 8. Could you please follow our code guide lines (spaces etc)
>>
>> Regards, Pavel
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Sean Chou <zhouyx at linux.vnet.ibm.com>
>> Date: Thu, Aug 9, 2012 at 3:29 PM
>> Subject: <Swing Dev> Add keyboard accessibility to JColorChooser swatch
>> To: swing-dev at openjdk.java.net
>>
>>
>> Hi all,
>>
>>      This is a patch to add keyboard accessibility to JColorChooser
>> swatch, so when using TAB, the focus can move to SwatchPanel, choose color
>> with arrow keys and select color with space bar.
>>
>>  In current implementation, it is not able to move the focus
>> to SwatchPanel with TAB, this can be seen in SwingSet2 demo.
>> Steps:
>> 1. run SwingSet2 demo
>> 2. click on JColorChooser demo
>> 3. click Background button and Swatches panel appears.
>> 4. Press Tab key     =>   focus moves to OK button as shown in this image
>> http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_1.png
>>
>>  With this patch, in step4, focus moves to SwatchPanel, as shown here
>> http://cr.openjdk.java.net/~zhouyx/OJDK-61/screenshot_2.png
>>  Then, arrow keys can be used to choose color and select color by space
>> bar.
>>
>>  The webrev is http://cr.openjdk.java.net/~zhouyx/OJDK-61/webrev.00/  .
>>
>>  Please take a look.
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>
> import javax.swing.*;
> import java.awt.*;
>
> public class JColorChooserTest {
>     public static void main(String[] args) {
>         SwingUtilities.invokeLater(new Runnable() {
>             @Override
>             public void run() {
>                 JFrame frame = new JFrame();
>
>                 JColorChooser chooser = new JColorChooser();
>
> chooser.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
>                 frame.add(chooser);
>
>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>                 frame.setSize(600, 400);
>                 frame.setVisible(true);
>             }
>         });
>     }
> }
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120829/9f05d61e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test7194184.java
Type: application/octet-stream
Size: 6639 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120829/9f05d61e/Test7194184.java>

From anton.litvinov at oracle.com  Wed Aug 29 12:15:50 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 29 Aug 2012 16:15:50 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503D03BB.8080502@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
Message-ID: <503E07F6.7050903@oracle.com>

Hello Pavel,

Thank you very much for a positive review of the fix and detailed 
remarks for the test. Could you review a corrected version of the test 
in a new webrev. I would like to clarify that a previous version of the 
test contained some irrelevant components, because I was not sure if I 
could significantly modify the original test case provided with the bug 
itself. URL of a webrev with the test class corrected according to your 
remarks is provided below.

Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02

The modified test was checked using "jtreg" tool on JDK with and without 
this fix, and the test behaved properly. The following changes were made:
1. Setting visibility of frames was removed, because it  does not 
influence reproducibility of the test.
2. All components except JPanel and JComboBox were eliminated from the test.
3. Frames' titles were corrected.
4. Method "test" was renamed and moved into EDT execution block.
5. Method "createAndShowGUI" was renamed.
6. Calls to JFrame's "dispose" method were added.

Thank you,
Anton

On 28.08.2012 21:45, Pavel Porvatov wrote:
> Hi Anton,
>
> The fix looks good but the test should be updated:
>
> 1. Is the following line needed for the test:
> 63         frame.setVisible(true);
> ?
> If yes then you should use SunToolkit.realSync to wait until frame 
> become visible.
> The same comment for the line
> 85         frame.setVisible(true);
>
> 2. Are label and layout and layout needed for the test purpose? If no, 
> can you remove unused components?
>
> 3. The following code looks strange (two titles?)
>  45         JFrame frame = new JFrame("HelloWorldSwing");
> ...
>  47         frame.setTitle("why why why");
>
> 4. The test method should be on the EDT
>
> 5. There is no need to use the mainPanel field. Logically it should be 
> local variable
>
> BTW: can you start with the fix for jdk8 and only then backport it to 
> jdk7?
>
> Regards, Pavel
>> Hello,
>>
>> Please review the following fix for a bug.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>
>> For details on this bug please look at "Evaluation" field on a web 
>> page of this bug. The provided webrev contains both a fix and a 
>> corresponding unit-test. Before publishing this webrev all unit-tests 
>> from the "java.awt" and
>> "javax.swing" related to serialization were run and no negative 
>> changes were observed comparing the results of tests' runs on JDK 
>> with and without patch represented by this webrev.
>>
>> This is the second version of the fix. The first version was 
>> submitted to the AWT development group through a review request with 
>> the same subject and after discussion with engineers and additional 
>> investigation of the problem it was decided to apply the fix in Swing 
>> part of JDK.
>>
>> Thank you,
>> Anton
>


From pavel.porvatov at oracle.com  Wed Aug 29 15:04:22 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 29 Aug 2012 19:04:22 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503E07F6.7050903@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com>
Message-ID: <503E2F76.7050909@oracle.com>

Hi Anton,

Does the test fail without the fix?

All code look good except one thing: could you please replace 
FileStreams by Byte streams? Regression tests should avoid to change 
file system, and if there is such need tests should restore file system 
in initial state
> Hello Pavel,
>
> Thank you very much for a positive review of the fix and detailed 
> remarks for the test. Could you review a corrected version of the test 
> in a new webrev. I would like to clarify that a previous version of 
> the test contained some irrelevant components, because I was not sure 
> if I could significantly modify the original test case provided with 
> the bug itself. URL of a webrev with the test class corrected 
> according to your remarks is provided below.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>
> The modified test was checked using "jtreg" tool on JDK with and 
> without this fix, and the test behaved properly. The following changes 
> were made:
> 1. Setting visibility of frames was removed, because it  does not 
> influence reproducibility of the test.
> 2. All components except JPanel and JComboBox were eliminated from the 
> test.
> 3. Frames' titles were corrected.
> 4. Method "test" was renamed and moved into EDT execution block.
> 5. Method "createAndShowGUI" was renamed.
> 6. Calls to JFrame's "dispose" method were added.
>
> Thank you,
> Anton
>
> On 28.08.2012 21:45, Pavel Porvatov wrote:
>> Hi Anton,
>>
>> The fix looks good but the test should be updated:
>>
>> 1. Is the following line needed for the test:
>> 63         frame.setVisible(true);
>> ?
>> If yes then you should use SunToolkit.realSync to wait until frame 
>> become visible.
>> The same comment for the line
>> 85         frame.setVisible(true);
>>
>> 2. Are label and layout and layout needed for the test purpose? If 
>> no, can you remove unused components?
>>
>> 3. The following code looks strange (two titles?)
>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>> ...
>>  47         frame.setTitle("why why why");
>>
>> 4. The test method should be on the EDT
>>
>> 5. There is no need to use the mainPanel field. Logically it should 
>> be local variable
>>
>> BTW: can you start with the fix for jdk8 and only then backport it to 
>> jdk7?
>>
>> Regards, Pavel
>>> Hello,
>>>
>>> Please review the following fix for a bug.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>
>>> For details on this bug please look at "Evaluation" field on a web 
>>> page of this bug. The provided webrev contains both a fix and a 
>>> corresponding unit-test. Before publishing this webrev all 
>>> unit-tests from the "java.awt" and
>>> "javax.swing" related to serialization were run and no negative 
>>> changes were observed comparing the results of tests' runs on JDK 
>>> with and without patch represented by this webrev.
>>>
>>> This is the second version of the fix. The first version was 
>>> submitted to the AWT development group through a review request with 
>>> the same subject and after discussion with engineers and additional 
>>> investigation of the problem it was decided to apply the fix in 
>>> Swing part of JDK.
>>>
>>> Thank you,
>>> Anton
>>



From Vladislav.Karnaukhov at oracle.com  Wed Aug 29 15:12:11 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 29 Aug 2012 19:12:11 +0400
Subject: <Swing Dev> [7] Review request for 7123767 Wrong tooltip
 location in Multi-Monitor configurations
In-Reply-To: <503B6F25.9030009@oracle.com>
References: <5016903D.8010104@oracle.com> <502E7B01.1050801@oracle.com>
	<503B6F25.9030009@oracle.com>
Message-ID: <503E314B.9030608@oracle.com>

Hello,

has anyone got a chance to review this?

Regards,
- Vlad

On 8/27/2012 4:59 PM, Vladislav Karnaukhov wrote:
> Hi Pavel, all,
>
> please find new webrev here: 
> http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.02/
> Please see my comments inline.
>
> Regards,
> - Vlad
>
> On 8/17/2012 9:10 PM, Pavel Porvatov wrote:
>> Hi Vladislav,
>>
>> I have several comments about the fix:
>>
>> 1. javax.swing.ToolTipManager#showTipWindow: I think toFind variable 
>> should be initialized in if(preferredLocation != null) { ....} else 
>> {...} block. It looks more logical and code will be more compact 
>> (adjustedPreferredLocation can be removed at all, I think)
> Agreed. I've re-worked this piece.
>
>>
>> 2. Could you please explain why you are using union of all rectangles 
>> in the getDrawingRect method? In case two monitors are aligned on a 
>> diagonal totalRect will contain areas that are not covered by screen 
>> devices and popups can be placed incorrectly.
> Agreed again. I've re-designed getDrawingRect() function and placed 
> additional condition into showTipWindow() function; now every 
> situation should be handled correctly.
>
> Automated test was added, please see the webrev.
>
> Regards,
> - Vlad
>
>>
>> Regards, Pavel
>>
>>> Hello,
>>>
>>> please review the fix for 7123767: Wrong tooltip location in 
>>> Multi-Monitor configurations
>>>
>>> jdk7 webrev: http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.00/
>>> test source: http://cr.openjdk.java.net/~vkarnauk/7123767/test/
>>> bug description: 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123767
>>>
>>> This is also a customer escalated issue in jdk6.
>>>
>>> On multi-monitor configurations Component.getLocationOnScreen() may 
>>> return negative values. Additionally, ToolTipManager.showTipWindow() 
>>> method calculates tip window location from Component' 
>>> getLocationOnScreen() return data and draws tip window using the 
>>> same GraphicsConfiguration instance as component's top-left corner, 
>>> which again can be of negative value. When component is stretched 
>>> across multiple screen devices, this may lead to a situation when 
>>> it's tooltip is drawn on wrong monitor.
>>>
>>> To fix this we should count all GraphicsConfiguration instances and 
>>> determine correct screen device to draw on. We should also take into 
>>> account that:
>>> 1) tip window preferred location could be set
>>> 2) preferred location could be greater than total virtual bounds of 
>>> all monitors. To make tip window visible in such case we move it to 
>>> the corresponding corner of total virtual bounds
>>> 3) exact order of monitors (left-to-right and top-to-bottom) is unknown
>>>
>>> I run jtreg against ToolTipManager tests and all tests passed (I run 
>>> it several times with different monitor configurations). I also 
>>> tested the fix with custom test program (please see the link 
>>> provided) with 4 possible monitor configurations (left-to-right, 
>>> right-to-left, top-to-bottom and bottom-to-top) and saw no issues.
>>>
>>> I added no new automated test(s) because this at least would require 
>>> multiple monitors to run.
>>>
>>> Regards,
>>> - Vlad
>>
>
>




From Vladislav.Karnaukhov at oracle.com  Wed Aug 29 15:13:11 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 29 Aug 2012 19:13:11 +0400
Subject: <Swing Dev> <Swind Dev> [7] Review request for 6836089: Swing
 HTML parser can't properly decode codepoints outside the Unicode Plane 0
 into a surrogate pair
In-Reply-To: <503B8987.3040004@oracle.com>
References: <4FE82651.7050302@oracle.com> <4FE878F6.1000907@oracle.com>
	<4FE966D6.5050504@oracle.com> <4FE9F643.9060001@oracle.com>
	<4FEB4B0F.8080406@oracle.com> <4FEB4D30.5070400@oracle.com>
	<4FEC7124.6060403@oracle.com> <4FECD620.8000106@oracle.com>
	<503B8987.3040004@oracle.com>
Message-ID: <503E3187.4020006@oracle.com>

Hello,

has anyone got a chance to review this?

Regards,
- Vlad

On 8/27/2012 6:51 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> could you please review a new version?
> Please find webrev here: 
> http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.04/
>
> Regards,
> - Vlad
>
> On 6/29/2012 2:09 AM, Phil Race wrote:
>> That would work but I think its cleaner to just move it all into 
>> mapNumericReference
>> as below.
>>
>> -phil.
>>
>> diff --git 
>> a/src/share/classes/javax/swing/text/html/parser/Parser.java 
>> b/src/share/classes/javax/swing/text/html/parser/Parser.java
>> --- a/src/share/classes/javax/swing/text/html/parser/Parser.java
>> +++ b/src/share/classes/javax/swing/text/html/parser/Parser.java
>> @@ -952,7 +952,7 @@
>>                          ch = readCh();
>>                          break;
>>                  }
>> -                char data[] = {mapNumericReference((char) n)};
>> +                char data[] = mapNumericReference(n);
>>                  return data;
>>              }
>>              addString('#');
>> @@ -1021,7 +1021,7 @@
>>      }
>>
>>      /**
>> -     * Converts numeric character reference to Unicode character.
>> +     * Converts numeric character reference to char array.
>>       *
>>       * Normally the code in a reference should be always converted
>>       * to the Unicode character with the same code, but due to
>> @@ -1030,13 +1030,21 @@
>>       * to displayable characters with other codes.
>>       *
>>       * @param c the code of numeric character reference.
>> -     * @return the character corresponding to the reference code.
>> +     * @return a char array corresponding to the reference code.
>>       */
>> -    private char mapNumericReference(char c) {
>> -        if (c < 130 || c > 159) {
>> -            return c;
>> +    private char[] mapNumericReference(int c) {
>> +        char[] data;
>> +        if (c >= 0xffff) { // outside unicode BMP.
>> +            try {
>> +                data = Character.toChars(c);
>> +            } catch (IllegalArgumentException e) {
>> +                data = new char[0];
>>          }
>> -        return cp1252Map[c - 130];
>> +        } else {
>> +            data = new char[1];
>> +            data[0] = (c < 130 || c > 159) ? (char)c : cp1252Map[c - 
>> 130];
>> +        }
>> +        return data;
>>      }
>>
>>
>> On 06/28/12 07:58 AM, Vladislav Karnaukhov wrote:
>>> Hello Phil, Pavel,
>>>
>>> thank you for your comments. I've reworked fix and testcase, please 
>>> find new webrev here: 
>>> http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.03/
>>>
>>> Regards,
>>> - Vlad
>>>
>>> On 6/27/2012 10:13 PM, Phil Race wrote:
>>>> Well its not only unnecessary but is likely wrong .. I don't think
>>>> you looked at what mapNumericReference() does.
>>>>
>>>> -phil.
>>>>
>>>> On 6/27/2012 11:03 AM, Vladislav Karnaukhov wrote:
>>>>> Hello Phil,
>>>>>
>>>>> I used Character.toChars() in both branches because I wanted to 
>>>>> delegate code point conversion to char or surrogate pair entirely 
>>>>> to Character class...
>>>>>
>>>>> Regards,
>>>>> - Vlad
>>>>>
>>>>> On 6/26/2012 9:49 PM, Phil Race wrote:
>>>>>> I don't understand why you call Character.toChars() if you've 
>>>>>> just determined
>>>>>> you don't need to ?
>>>>>>
>>>>>> ie what was wrong with
>>>>>>
>>>>>> data = ( n >>> 16 == 0) ? {mapNumericReference((char) n)} : 
>>>>>> Character.toChars(n);
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> In the case of an invalid supplementary pair, maybe it would be 
>>>>>> safer to  return { ' ' } ?
>>>>>>
>>>>>>
>>>>>> One thing I see in the parsing code that is not new or changed 
>>>>>> here, that
>>>>>> may bear examination, is that there's a loop that keeps on 
>>>>>> reading so long
>>>>>> so long there are new digits. I am not sure its wise to keep 
>>>>>> going once
>>>>>> you overflow.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 6/26/2012 12:37 AM, Vladislav Karnaukhov wrote:
>>>>>>> Hello Pavel,
>>>>>>>
>>>>>>> I can provide you with the link to 6u19, but this is direct 
>>>>>>> forward-port and no code changes were made.
>>>>>>>
>>>>>>> I'll make changes as you've pointed out in 1) and 2)
>>>>>>>
>>>>>>> About 3) - is it a requirement to use "? :" operator? I 
>>>>>>> personally prefer single-line if-else, but I don't want to argue 
>>>>>>> over code style, and surely I'll follow code design practices.
>>>>>>>
>>>>>>> Regards,
>>>>>>> - Vlad
>>>>>>>
>>>>>>> On 6/25/2012 6:43 PM, Pavel Porvatov wrote:
>>>>>>>> Hi Vladislav,
>>>>>>>>
>>>>>>>> Do you have a link to the fix for 6u19?
>>>>>>>>
>>>>>>>> I didn't investigate the fix deeply, but
>>>>>>>>
>>>>>>>> 1.
>>>>>>>>  private final int MAX_BMP_BOUND = 65535;
>>>>>>>> should be static (otherwise variable name should be in lower case)
>>>>>>>>
>>>>>>>> 2. Add a space in single line comments
>>>>>>>>
>>>>>>>> 3.
>>>>>>>> +                    char data[];
>>>>>>>> +                    if (n <= MAX_BMP_BOUND) {
>>>>>>>> +                        data = 
>>>>>>>> Character.toChars(mapNumericReference((char) n));
>>>>>>>> +                    } else {
>>>>>>>> +                        data = Character.toChars(n);
>>>>>>>> +                    }
>>>>>>>> +
>>>>>>>>                  return data;
>>>>>>>>
>>>>>>>> can be written in one line via "? :" operator and looks more 
>>>>>>>> readable for me
>>>>>>>>
>>>>>>>> Thanks, Pavel
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> please review the fix for 6836089: Swing HTML parser can't 
>>>>>>>>> properly decode codepoints outside the Unicode Plane 0 into a 
>>>>>>>>> surrogate pair. This is a forward port from JDK6 (fixed 
>>>>>>>>> escalated issue, fix integrated) to JDK7.
>>>>>>>>>
>>>>>>>>> The issue is a defect in Swing HTML Parser: if the codepoint 
>>>>>>>>> is outside BMP (Unicode Plain 0), Parser incorrectly decodes 
>>>>>>>>> codepoint into surrogate pair. The fix is to use 
>>>>>>>>> Character.toChars() method if codepoint value is greater than 
>>>>>>>>> upper bound of BMP.
>>>>>>>>>
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.00/
>>>>>>>>> Bug description: 
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6836089
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> - Vlad
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>




From anton.litvinov at oracle.com  Wed Aug 29 16:54:27 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 29 Aug 2012 20:54:27 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503E2F76.7050909@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
Message-ID: <503E4943.6050202@oracle.com>

Hello Pavel,

Yes, the test fails on JDK 7 without fix and does not fail on JDK 7 with 
fix. Yes, I will definitely prefer to substitute the code writing data 
to files for a code writing data to byte streams.

Thank you,
Anton

On 29.08.2012 19:04, Pavel Porvatov wrote:
> Hi Anton,
>
> Does the test fail without the fix?
>
> All code look good except one thing: could you please replace 
> FileStreams by Byte streams? Regression tests should avoid to change 
> file system, and if there is such need tests should restore file 
> system in initial state
>> Hello Pavel,
>>
>> Thank you very much for a positive review of the fix and detailed 
>> remarks for the test. Could you review a corrected version of the 
>> test in a new webrev. I would like to clarify that a previous version 
>> of the test contained some irrelevant components, because I was not 
>> sure if I could significantly modify the original test case provided 
>> with the bug itself. URL of a webrev with the test class corrected 
>> according to your remarks is provided below.
>>
>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>
>> The modified test was checked using "jtreg" tool on JDK with and 
>> without this fix, and the test behaved properly. The following 
>> changes were made:
>> 1. Setting visibility of frames was removed, because it  does not 
>> influence reproducibility of the test.
>> 2. All components except JPanel and JComboBox were eliminated from 
>> the test.
>> 3. Frames' titles were corrected.
>> 4. Method "test" was renamed and moved into EDT execution block.
>> 5. Method "createAndShowGUI" was renamed.
>> 6. Calls to JFrame's "dispose" method were added.
>>
>> Thank you,
>> Anton
>>
>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>> Hi Anton,
>>>
>>> The fix looks good but the test should be updated:
>>>
>>> 1. Is the following line needed for the test:
>>> 63         frame.setVisible(true);
>>> ?
>>> If yes then you should use SunToolkit.realSync to wait until frame 
>>> become visible.
>>> The same comment for the line
>>> 85         frame.setVisible(true);
>>>
>>> 2. Are label and layout and layout needed for the test purpose? If 
>>> no, can you remove unused components?
>>>
>>> 3. The following code looks strange (two titles?)
>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>> ...
>>>  47         frame.setTitle("why why why");
>>>
>>> 4. The test method should be on the EDT
>>>
>>> 5. There is no need to use the mainPanel field. Logically it should 
>>> be local variable
>>>
>>> BTW: can you start with the fix for jdk8 and only then backport it 
>>> to jdk7?
>>>
>>> Regards, Pavel
>>>> Hello,
>>>>
>>>> Please review the following fix for a bug.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>
>>>> For details on this bug please look at "Evaluation" field on a web 
>>>> page of this bug. The provided webrev contains both a fix and a 
>>>> corresponding unit-test. Before publishing this webrev all 
>>>> unit-tests from the "java.awt" and
>>>> "javax.swing" related to serialization were run and no negative 
>>>> changes were observed comparing the results of tests' runs on JDK 
>>>> with and without patch represented by this webrev.
>>>>
>>>> This is the second version of the fix. The first version was 
>>>> submitted to the AWT development group through a review request 
>>>> with the same subject and after discussion with engineers and 
>>>> additional investigation of the problem it was decided to apply the 
>>>> fix in Swing part of JDK.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>


From anton.litvinov at oracle.com  Thu Aug 30 15:13:37 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 30 Aug 2012 19:13:37 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503E4943.6050202@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com>
Message-ID: <503F8321.1060804@oracle.com>

Hello Pavel,

Could you review a new webrev with code changes reflecting your last 
remark concerning a substitution of File streams for Byte streams in the 
test class. The test was checked using "jtreg". It fails on JDK 7 
without this fix, and passes on JDK 7 with fix. URL of the new webrev is 
the following.

Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03

Thank you,
Anton

On 29.08.2012 20:54, Anton Litvinov wrote:
> Hello Pavel,
>
> Yes, the test fails on JDK 7 without fix and does not fail on JDK 7 
> with fix. Yes, I will definitely prefer to substitute the code writing 
> data to files for a code writing data to byte streams.
>
> Thank you,
> Anton
>
> On 29.08.2012 19:04, Pavel Porvatov wrote:
>> Hi Anton,
>>
>> Does the test fail without the fix?
>>
>> All code look good except one thing: could you please replace 
>> FileStreams by Byte streams? Regression tests should avoid to change 
>> file system, and if there is such need tests should restore file 
>> system in initial state
>>> Hello Pavel,
>>>
>>> Thank you very much for a positive review of the fix and detailed 
>>> remarks for the test. Could you review a corrected version of the 
>>> test in a new webrev. I would like to clarify that a previous 
>>> version of the test contained some irrelevant components, because I 
>>> was not sure if I could significantly modify the original test case 
>>> provided with the bug itself. URL of a webrev with the test class 
>>> corrected according to your remarks is provided below.
>>>
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>
>>> The modified test was checked using "jtreg" tool on JDK with and 
>>> without this fix, and the test behaved properly. The following 
>>> changes were made:
>>> 1. Setting visibility of frames was removed, because it  does not 
>>> influence reproducibility of the test.
>>> 2. All components except JPanel and JComboBox were eliminated from 
>>> the test.
>>> 3. Frames' titles were corrected.
>>> 4. Method "test" was renamed and moved into EDT execution block.
>>> 5. Method "createAndShowGUI" was renamed.
>>> 6. Calls to JFrame's "dispose" method were added.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>> Hi Anton,
>>>>
>>>> The fix looks good but the test should be updated:
>>>>
>>>> 1. Is the following line needed for the test:
>>>> 63         frame.setVisible(true);
>>>> ?
>>>> If yes then you should use SunToolkit.realSync to wait until frame 
>>>> become visible.
>>>> The same comment for the line
>>>> 85         frame.setVisible(true);
>>>>
>>>> 2. Are label and layout and layout needed for the test purpose? If 
>>>> no, can you remove unused components?
>>>>
>>>> 3. The following code looks strange (two titles?)
>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>> ...
>>>>  47         frame.setTitle("why why why");
>>>>
>>>> 4. The test method should be on the EDT
>>>>
>>>> 5. There is no need to use the mainPanel field. Logically it should 
>>>> be local variable
>>>>
>>>> BTW: can you start with the fix for jdk8 and only then backport it 
>>>> to jdk7?
>>>>
>>>> Regards, Pavel
>>>>> Hello,
>>>>>
>>>>> Please review the following fix for a bug.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>
>>>>> For details on this bug please look at "Evaluation" field on a web 
>>>>> page of this bug. The provided webrev contains both a fix and a 
>>>>> corresponding unit-test. Before publishing this webrev all 
>>>>> unit-tests from the "java.awt" and
>>>>> "javax.swing" related to serialization were run and no negative 
>>>>> changes were observed comparing the results of tests' runs on JDK 
>>>>> with and without patch represented by this webrev.
>>>>>
>>>>> This is the second version of the fix. The first version was 
>>>>> submitted to the AWT development group through a review request 
>>>>> with the same subject and after discussion with engineers and 
>>>>> additional investigation of the problem it was decided to apply 
>>>>> the fix in Swing part of JDK.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>
>>


From anton.litvinov at oracle.com  Thu Aug 30 15:15:30 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 30 Aug 2012 19:15:30 +0400
Subject: <Swing Dev> [8] Review request for 7193219: JComboBox serialization
 fails in JDK 1.7
Message-ID: <503F8392.1060107@oracle.com>

Hello,

Please review the following fix for a bug.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03

For details on this bug please look at "Evaluation" field on a web page 
of this bug. The provided webrev contains both a fix and a corresponding 
unit-test. This fix is identical to the fix, which was created for JDK 
7u8 and already sent for a review to this alias. The fix was 
successfully tested manually and using "jtreg" tool on my local build of 
JDK 8 from "swing" repository.

Thank you,
Anton


From Vladislav.Karnaukhov at oracle.com  Thu Aug 30 15:17:27 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 30 Aug 2012 19:17:27 +0400
Subject: <Swing Dev> [7] Review request for 7123767 Wrong tooltip
 location in Multi-Monitor configurations
In-Reply-To: <503B6F25.9030009@oracle.com>
References: <5016903D.8010104@oracle.com> <502E7B01.1050801@oracle.com>
	<503B6F25.9030009@oracle.com>
Message-ID: <503F8407.1030307@oracle.com>

Hello,

can anyone review this please?

- Vlad

On 8/27/2012 4:59 PM, Vladislav Karnaukhov wrote:
> Hi Pavel, all,
>
> please find new webrev here: 
> http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.02/
> Please see my comments inline.
>
> Regards,
> - Vlad
>
> On 8/17/2012 9:10 PM, Pavel Porvatov wrote:
>> Hi Vladislav,
>>
>> I have several comments about the fix:
>>
>> 1. javax.swing.ToolTipManager#showTipWindow: I think toFind variable 
>> should be initialized in if(preferredLocation != null) { ....} else 
>> {...} block. It looks more logical and code will be more compact 
>> (adjustedPreferredLocation can be removed at all, I think)
> Agreed. I've re-worked this piece.
>
>>
>> 2. Could you please explain why you are using union of all rectangles 
>> in the getDrawingRect method? In case two monitors are aligned on a 
>> diagonal totalRect will contain areas that are not covered by screen 
>> devices and popups can be placed incorrectly.
> Agreed again. I've re-designed getDrawingRect() function and placed 
> additional condition into showTipWindow() function; now every 
> situation should be handled correctly.
>
> Automated test was added, please see the webrev.
>
> Regards,
> - Vlad
>
>>
>> Regards, Pavel
>>
>>> Hello,
>>>
>>> please review the fix for 7123767: Wrong tooltip location in 
>>> Multi-Monitor configurations
>>>
>>> jdk7 webrev: http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.00/
>>> test source: http://cr.openjdk.java.net/~vkarnauk/7123767/test/
>>> bug description: 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123767
>>>
>>> This is also a customer escalated issue in jdk6.
>>>
>>> On multi-monitor configurations Component.getLocationOnScreen() may 
>>> return negative values. Additionally, ToolTipManager.showTipWindow() 
>>> method calculates tip window location from Component' 
>>> getLocationOnScreen() return data and draws tip window using the 
>>> same GraphicsConfiguration instance as component's top-left corner, 
>>> which again can be of negative value. When component is stretched 
>>> across multiple screen devices, this may lead to a situation when 
>>> it's tooltip is drawn on wrong monitor.
>>>
>>> To fix this we should count all GraphicsConfiguration instances and 
>>> determine correct screen device to draw on. We should also take into 
>>> account that:
>>> 1) tip window preferred location could be set
>>> 2) preferred location could be greater than total virtual bounds of 
>>> all monitors. To make tip window visible in such case we move it to 
>>> the corresponding corner of total virtual bounds
>>> 3) exact order of monitors (left-to-right and top-to-bottom) is unknown
>>>
>>> I run jtreg against ToolTipManager tests and all tests passed (I run 
>>> it several times with different monitor configurations). I also 
>>> tested the fix with custom test program (please see the link 
>>> provided) with 4 possible monitor configurations (left-to-right, 
>>> right-to-left, top-to-bottom and bottom-to-top) and saw no issues.
>>>
>>> I added no new automated test(s) because this at least would require 
>>> multiple monitors to run.
>>>
>>> Regards,
>>> - Vlad
>>
>
>




From Vladislav.Karnaukhov at oracle.com  Thu Aug 30 15:18:05 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 30 Aug 2012 19:18:05 +0400
Subject: <Swing Dev> <Swind Dev> [7] Review request for 6836089: Swing
 HTML parser can't properly decode codepoints outside the Unicode Plane 0
 into a surrogate pair
In-Reply-To: <503B8987.3040004@oracle.com>
References: <4FE82651.7050302@oracle.com> <4FE878F6.1000907@oracle.com>
	<4FE966D6.5050504@oracle.com> <4FE9F643.9060001@oracle.com>
	<4FEB4B0F.8080406@oracle.com> <4FEB4D30.5070400@oracle.com>
	<4FEC7124.6060403@oracle.com> <4FECD620.8000106@oracle.com>
	<503B8987.3040004@oracle.com>
Message-ID: <503F842D.70900@oracle.com>

Hello,

can anyone review this?

- Vlad

On 8/27/2012 6:51 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> could you please review a new version?
> Please find webrev here: 
> http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.04/
>
> Regards,
> - Vlad
>
> On 6/29/2012 2:09 AM, Phil Race wrote:
>> That would work but I think its cleaner to just move it all into 
>> mapNumericReference
>> as below.
>>
>> -phil.
>>
>> diff --git 
>> a/src/share/classes/javax/swing/text/html/parser/Parser.java 
>> b/src/share/classes/javax/swing/text/html/parser/Parser.java
>> --- a/src/share/classes/javax/swing/text/html/parser/Parser.java
>> +++ b/src/share/classes/javax/swing/text/html/parser/Parser.java
>> @@ -952,7 +952,7 @@
>>                          ch = readCh();
>>                          break;
>>                  }
>> -                char data[] = {mapNumericReference((char) n)};
>> +                char data[] = mapNumericReference(n);
>>                  return data;
>>              }
>>              addString('#');
>> @@ -1021,7 +1021,7 @@
>>      }
>>
>>      /**
>> -     * Converts numeric character reference to Unicode character.
>> +     * Converts numeric character reference to char array.
>>       *
>>       * Normally the code in a reference should be always converted
>>       * to the Unicode character with the same code, but due to
>> @@ -1030,13 +1030,21 @@
>>       * to displayable characters with other codes.
>>       *
>>       * @param c the code of numeric character reference.
>> -     * @return the character corresponding to the reference code.
>> +     * @return a char array corresponding to the reference code.
>>       */
>> -    private char mapNumericReference(char c) {
>> -        if (c < 130 || c > 159) {
>> -            return c;
>> +    private char[] mapNumericReference(int c) {
>> +        char[] data;
>> +        if (c >= 0xffff) { // outside unicode BMP.
>> +            try {
>> +                data = Character.toChars(c);
>> +            } catch (IllegalArgumentException e) {
>> +                data = new char[0];
>>          }
>> -        return cp1252Map[c - 130];
>> +        } else {
>> +            data = new char[1];
>> +            data[0] = (c < 130 || c > 159) ? (char)c : cp1252Map[c - 
>> 130];
>> +        }
>> +        return data;
>>      }
>>
>>
>> On 06/28/12 07:58 AM, Vladislav Karnaukhov wrote:
>>> Hello Phil, Pavel,
>>>
>>> thank you for your comments. I've reworked fix and testcase, please 
>>> find new webrev here: 
>>> http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.03/
>>>
>>> Regards,
>>> - Vlad
>>>
>>> On 6/27/2012 10:13 PM, Phil Race wrote:
>>>> Well its not only unnecessary but is likely wrong .. I don't think
>>>> you looked at what mapNumericReference() does.
>>>>
>>>> -phil.
>>>>
>>>> On 6/27/2012 11:03 AM, Vladislav Karnaukhov wrote:
>>>>> Hello Phil,
>>>>>
>>>>> I used Character.toChars() in both branches because I wanted to 
>>>>> delegate code point conversion to char or surrogate pair entirely 
>>>>> to Character class...
>>>>>
>>>>> Regards,
>>>>> - Vlad
>>>>>
>>>>> On 6/26/2012 9:49 PM, Phil Race wrote:
>>>>>> I don't understand why you call Character.toChars() if you've 
>>>>>> just determined
>>>>>> you don't need to ?
>>>>>>
>>>>>> ie what was wrong with
>>>>>>
>>>>>> data = ( n >>> 16 == 0) ? {mapNumericReference((char) n)} : 
>>>>>> Character.toChars(n);
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> In the case of an invalid supplementary pair, maybe it would be 
>>>>>> safer to  return { ' ' } ?
>>>>>>
>>>>>>
>>>>>> One thing I see in the parsing code that is not new or changed 
>>>>>> here, that
>>>>>> may bear examination, is that there's a loop that keeps on 
>>>>>> reading so long
>>>>>> so long there are new digits. I am not sure its wise to keep 
>>>>>> going once
>>>>>> you overflow.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 6/26/2012 12:37 AM, Vladislav Karnaukhov wrote:
>>>>>>> Hello Pavel,
>>>>>>>
>>>>>>> I can provide you with the link to 6u19, but this is direct 
>>>>>>> forward-port and no code changes were made.
>>>>>>>
>>>>>>> I'll make changes as you've pointed out in 1) and 2)
>>>>>>>
>>>>>>> About 3) - is it a requirement to use "? :" operator? I 
>>>>>>> personally prefer single-line if-else, but I don't want to argue 
>>>>>>> over code style, and surely I'll follow code design practices.
>>>>>>>
>>>>>>> Regards,
>>>>>>> - Vlad
>>>>>>>
>>>>>>> On 6/25/2012 6:43 PM, Pavel Porvatov wrote:
>>>>>>>> Hi Vladislav,
>>>>>>>>
>>>>>>>> Do you have a link to the fix for 6u19?
>>>>>>>>
>>>>>>>> I didn't investigate the fix deeply, but
>>>>>>>>
>>>>>>>> 1.
>>>>>>>>  private final int MAX_BMP_BOUND = 65535;
>>>>>>>> should be static (otherwise variable name should be in lower case)
>>>>>>>>
>>>>>>>> 2. Add a space in single line comments
>>>>>>>>
>>>>>>>> 3.
>>>>>>>> +                    char data[];
>>>>>>>> +                    if (n <= MAX_BMP_BOUND) {
>>>>>>>> +                        data = 
>>>>>>>> Character.toChars(mapNumericReference((char) n));
>>>>>>>> +                    } else {
>>>>>>>> +                        data = Character.toChars(n);
>>>>>>>> +                    }
>>>>>>>> +
>>>>>>>>                  return data;
>>>>>>>>
>>>>>>>> can be written in one line via "? :" operator and looks more 
>>>>>>>> readable for me
>>>>>>>>
>>>>>>>> Thanks, Pavel
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> please review the fix for 6836089: Swing HTML parser can't 
>>>>>>>>> properly decode codepoints outside the Unicode Plane 0 into a 
>>>>>>>>> surrogate pair. This is a forward port from JDK6 (fixed 
>>>>>>>>> escalated issue, fix integrated) to JDK7.
>>>>>>>>>
>>>>>>>>> The issue is a defect in Swing HTML Parser: if the codepoint 
>>>>>>>>> is outside BMP (Unicode Plain 0), Parser incorrectly decodes 
>>>>>>>>> codepoint into surrogate pair. The fix is to use 
>>>>>>>>> Character.toChars() method if codepoint value is greater than 
>>>>>>>>> upper bound of BMP.
>>>>>>>>>
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~vkarnauk/6836089/webrev.00/
>>>>>>>>> Bug description: 
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6836089
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> - Vlad
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>




From pavel.porvatov at oracle.com  Fri Aug 31 10:48:38 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 31 Aug 2012 14:48:38 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <503F8321.1060804@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com> <503F8321.1060804@oracle.com>
Message-ID: <50409686.3090800@oracle.com>

Hi Anton,

I see you added
  57         } catch (RuntimeException re) {
  58             throw re;

in serializeGUI method. Is it necessary? I think lines 72 and 73 can be 
removed as well...  I didn't noticed that code in the previous webrev, 
unfortunately.

Regards, Pavel
> Hello Pavel,
>
> Could you review a new webrev with code changes reflecting your last 
> remark concerning a substitution of File streams for Byte streams in 
> the test class. The test was checked using "jtreg". It fails on JDK 7 
> without this fix, and passes on JDK 7 with fix. URL of the new webrev 
> is the following.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03
>
> Thank you,
> Anton
>
> On 29.08.2012 20:54, Anton Litvinov wrote:
>> Hello Pavel,
>>
>> Yes, the test fails on JDK 7 without fix and does not fail on JDK 7 
>> with fix. Yes, I will definitely prefer to substitute the code 
>> writing data to files for a code writing data to byte streams.
>>
>> Thank you,
>> Anton
>>
>> On 29.08.2012 19:04, Pavel Porvatov wrote:
>>> Hi Anton,
>>>
>>> Does the test fail without the fix?
>>>
>>> All code look good except one thing: could you please replace 
>>> FileStreams by Byte streams? Regression tests should avoid to change 
>>> file system, and if there is such need tests should restore file 
>>> system in initial state
>>>> Hello Pavel,
>>>>
>>>> Thank you very much for a positive review of the fix and detailed 
>>>> remarks for the test. Could you review a corrected version of the 
>>>> test in a new webrev. I would like to clarify that a previous 
>>>> version of the test contained some irrelevant components, because I 
>>>> was not sure if I could significantly modify the original test case 
>>>> provided with the bug itself. URL of a webrev with the test class 
>>>> corrected according to your remarks is provided below.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>>
>>>> The modified test was checked using "jtreg" tool on JDK with and 
>>>> without this fix, and the test behaved properly. The following 
>>>> changes were made:
>>>> 1. Setting visibility of frames was removed, because it  does not 
>>>> influence reproducibility of the test.
>>>> 2. All components except JPanel and JComboBox were eliminated from 
>>>> the test.
>>>> 3. Frames' titles were corrected.
>>>> 4. Method "test" was renamed and moved into EDT execution block.
>>>> 5. Method "createAndShowGUI" was renamed.
>>>> 6. Calls to JFrame's "dispose" method were added.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>>> Hi Anton,
>>>>>
>>>>> The fix looks good but the test should be updated:
>>>>>
>>>>> 1. Is the following line needed for the test:
>>>>> 63         frame.setVisible(true);
>>>>> ?
>>>>> If yes then you should use SunToolkit.realSync to wait until frame 
>>>>> become visible.
>>>>> The same comment for the line
>>>>> 85         frame.setVisible(true);
>>>>>
>>>>> 2. Are label and layout and layout needed for the test purpose? If 
>>>>> no, can you remove unused components?
>>>>>
>>>>> 3. The following code looks strange (two titles?)
>>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>>> ...
>>>>>  47         frame.setTitle("why why why");
>>>>>
>>>>> 4. The test method should be on the EDT
>>>>>
>>>>> 5. There is no need to use the mainPanel field. Logically it 
>>>>> should be local variable
>>>>>
>>>>> BTW: can you start with the fix for jdk8 and only then backport it 
>>>>> to jdk7?
>>>>>
>>>>> Regards, Pavel
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following fix for a bug.
>>>>>>
>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>>
>>>>>> For details on this bug please look at "Evaluation" field on a 
>>>>>> web page of this bug. The provided webrev contains both a fix and 
>>>>>> a corresponding unit-test. Before publishing this webrev all 
>>>>>> unit-tests from the "java.awt" and
>>>>>> "javax.swing" related to serialization were run and no negative 
>>>>>> changes were observed comparing the results of tests' runs on JDK 
>>>>>> with and without patch represented by this webrev.
>>>>>>
>>>>>> This is the second version of the fix. The first version was 
>>>>>> submitted to the AWT development group through a review request 
>>>>>> with the same subject and after discussion with engineers and 
>>>>>> additional investigation of the problem it was decided to apply 
>>>>>> the fix in Swing part of JDK.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>
>>>



From anton.litvinov at oracle.com  Fri Aug 31 11:35:36 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 31 Aug 2012 15:35:36 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <50409686.3090800@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com> <503F8321.1060804@oracle.com>
	<50409686.3090800@oracle.com>
Message-ID: <5040A188.7030302@oracle.com>

Hello Pavel,

Thank you for the response with remarks. Yes, one additional "catch 
(RuntimeException re)" block was added in my previous webrev. I decided 
to add such a block, because of two following reasons:

1. To make an output stack trace shorter, but still containing a stack 
trace of the expected NullPointerException, in case if such exception is 
caught. Otherwise the final stack trace will contain 3 exceptions, where 
only the third one is informational. This change simplifies manual 
testing by diminishing a number of lines necessary for reading.
2. To eliminate extra folding of RuntimeException into a new 
RuntimeException, which did not happen at all.

A similar approach was applied to "try/catch" block in "serializeGUI" 
method for making the whole test consistent in the current webrev.

Thank you,
Anton

On 31.08.2012 14:48, Pavel Porvatov wrote:
> Hi Anton,
>
> I see you added
>  57         } catch (RuntimeException re) {
>  58             throw re;
>
> in serializeGUI method. Is it necessary? I think lines 72 and 73 can 
> be removed as well...  I didn't noticed that code in the previous 
> webrev, unfortunately.
>
> Regards, Pavel
>> Hello Pavel,
>>
>> Could you review a new webrev with code changes reflecting your last 
>> remark concerning a substitution of File streams for Byte streams in 
>> the test class. The test was checked using "jtreg". It fails on JDK 7 
>> without this fix, and passes on JDK 7 with fix. URL of the new webrev 
>> is the following.
>>
>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03
>>
>> Thank you,
>> Anton
>>
>> On 29.08.2012 20:54, Anton Litvinov wrote:
>>> Hello Pavel,
>>>
>>> Yes, the test fails on JDK 7 without fix and does not fail on JDK 7 
>>> with fix. Yes, I will definitely prefer to substitute the code 
>>> writing data to files for a code writing data to byte streams.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 29.08.2012 19:04, Pavel Porvatov wrote:
>>>> Hi Anton,
>>>>
>>>> Does the test fail without the fix?
>>>>
>>>> All code look good except one thing: could you please replace 
>>>> FileStreams by Byte streams? Regression tests should avoid to 
>>>> change file system, and if there is such need tests should restore 
>>>> file system in initial state
>>>>> Hello Pavel,
>>>>>
>>>>> Thank you very much for a positive review of the fix and detailed 
>>>>> remarks for the test. Could you review a corrected version of the 
>>>>> test in a new webrev. I would like to clarify that a previous 
>>>>> version of the test contained some irrelevant components, because 
>>>>> I was not sure if I could significantly modify the original test 
>>>>> case provided with the bug itself. URL of a webrev with the test 
>>>>> class corrected according to your remarks is provided below.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>>>
>>>>> The modified test was checked using "jtreg" tool on JDK with and 
>>>>> without this fix, and the test behaved properly. The following 
>>>>> changes were made:
>>>>> 1. Setting visibility of frames was removed, because it  does not 
>>>>> influence reproducibility of the test.
>>>>> 2. All components except JPanel and JComboBox were eliminated from 
>>>>> the test.
>>>>> 3. Frames' titles were corrected.
>>>>> 4. Method "test" was renamed and moved into EDT execution block.
>>>>> 5. Method "createAndShowGUI" was renamed.
>>>>> 6. Calls to JFrame's "dispose" method were added.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> The fix looks good but the test should be updated:
>>>>>>
>>>>>> 1. Is the following line needed for the test:
>>>>>> 63         frame.setVisible(true);
>>>>>> ?
>>>>>> If yes then you should use SunToolkit.realSync to wait until 
>>>>>> frame become visible.
>>>>>> The same comment for the line
>>>>>> 85         frame.setVisible(true);
>>>>>>
>>>>>> 2. Are label and layout and layout needed for the test purpose? 
>>>>>> If no, can you remove unused components?
>>>>>>
>>>>>> 3. The following code looks strange (two titles?)
>>>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>>>> ...
>>>>>>  47         frame.setTitle("why why why");
>>>>>>
>>>>>> 4. The test method should be on the EDT
>>>>>>
>>>>>> 5. There is no need to use the mainPanel field. Logically it 
>>>>>> should be local variable
>>>>>>
>>>>>> BTW: can you start with the fix for jdk8 and only then backport 
>>>>>> it to jdk7?
>>>>>>
>>>>>> Regards, Pavel
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following fix for a bug.
>>>>>>>
>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>>>
>>>>>>> For details on this bug please look at "Evaluation" field on a 
>>>>>>> web page of this bug. The provided webrev contains both a fix 
>>>>>>> and a corresponding unit-test. Before publishing this webrev all 
>>>>>>> unit-tests from the "java.awt" and
>>>>>>> "javax.swing" related to serialization were run and no negative 
>>>>>>> changes were observed comparing the results of tests' runs on 
>>>>>>> JDK with and without patch represented by this webrev.
>>>>>>>
>>>>>>> This is the second version of the fix. The first version was 
>>>>>>> submitted to the AWT development group through a review request 
>>>>>>> with the same subject and after discussion with engineers and 
>>>>>>> additional investigation of the problem it was decided to apply 
>>>>>>> the fix in Swing part of JDK.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>
>>>>
>


From pavel.porvatov at oracle.com  Fri Aug 31 13:49:34 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 31 Aug 2012 17:49:34 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <5040A188.7030302@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com> <503F8321.1060804@oracle.com>
	<50409686.3090800@oracle.com> <5040A188.7030302@oracle.com>
Message-ID: <5040C0EE.6040603@oracle.com>

Hi Anton,
> Hello Pavel,
>
> Thank you for the response with remarks. Yes, one additional "catch 
> (RuntimeException re)" block was added in my previous webrev. I 
> decided to add such a block, because of two following reasons:
>
> 1. To make an output stack trace shorter, but still containing a stack 
> trace of the expected NullPointerException, in case if such exception 
> is caught. Otherwise the final stack trace will contain 3 exceptions, 
> where only the third one is informational. This change simplifies 
> manual testing by diminishing a number of lines necessary for reading.
> 2. To eliminate extra folding of RuntimeException into a new 
> RuntimeException, which did not happen at all.
Why don't you catch just one IOException? I think it will solve both the 
problem described above and will look shorter and clearer for other people?

Regards, Pavel

>
> A similar approach was applied to "try/catch" block in "serializeGUI" 
> method for making the whole test consistent in the current webrev.
>
> Thank you,
> Anton
>
> On 31.08.2012 14:48, Pavel Porvatov wrote:
>> Hi Anton,
>>
>> I see you added
>>  57         } catch (RuntimeException re) {
>>  58             throw re;
>>
>> in serializeGUI method. Is it necessary? I think lines 72 and 73 can 
>> be removed as well...  I didn't noticed that code in the previous 
>> webrev, unfortunately.
>>
>> Regards, Pavel
>>> Hello Pavel,
>>>
>>> Could you review a new webrev with code changes reflecting your last 
>>> remark concerning a substitution of File streams for Byte streams in 
>>> the test class. The test was checked using "jtreg". It fails on JDK 
>>> 7 without this fix, and passes on JDK 7 with fix. URL of the new 
>>> webrev is the following.
>>>
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 29.08.2012 20:54, Anton Litvinov wrote:
>>>> Hello Pavel,
>>>>
>>>> Yes, the test fails on JDK 7 without fix and does not fail on JDK 7 
>>>> with fix. Yes, I will definitely prefer to substitute the code 
>>>> writing data to files for a code writing data to byte streams.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 29.08.2012 19:04, Pavel Porvatov wrote:
>>>>> Hi Anton,
>>>>>
>>>>> Does the test fail without the fix?
>>>>>
>>>>> All code look good except one thing: could you please replace 
>>>>> FileStreams by Byte streams? Regression tests should avoid to 
>>>>> change file system, and if there is such need tests should restore 
>>>>> file system in initial state
>>>>>> Hello Pavel,
>>>>>>
>>>>>> Thank you very much for a positive review of the fix and detailed 
>>>>>> remarks for the test. Could you review a corrected version of the 
>>>>>> test in a new webrev. I would like to clarify that a previous 
>>>>>> version of the test contained some irrelevant components, because 
>>>>>> I was not sure if I could significantly modify the original test 
>>>>>> case provided with the bug itself. URL of a webrev with the test 
>>>>>> class corrected according to your remarks is provided below.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>>>>
>>>>>> The modified test was checked using "jtreg" tool on JDK with and 
>>>>>> without this fix, and the test behaved properly. The following 
>>>>>> changes were made:
>>>>>> 1. Setting visibility of frames was removed, because it  does not 
>>>>>> influence reproducibility of the test.
>>>>>> 2. All components except JPanel and JComboBox were eliminated 
>>>>>> from the test.
>>>>>> 3. Frames' titles were corrected.
>>>>>> 4. Method "test" was renamed and moved into EDT execution block.
>>>>>> 5. Method "createAndShowGUI" was renamed.
>>>>>> 6. Calls to JFrame's "dispose" method were added.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> The fix looks good but the test should be updated:
>>>>>>>
>>>>>>> 1. Is the following line needed for the test:
>>>>>>> 63         frame.setVisible(true);
>>>>>>> ?
>>>>>>> If yes then you should use SunToolkit.realSync to wait until 
>>>>>>> frame become visible.
>>>>>>> The same comment for the line
>>>>>>> 85         frame.setVisible(true);
>>>>>>>
>>>>>>> 2. Are label and layout and layout needed for the test purpose? 
>>>>>>> If no, can you remove unused components?
>>>>>>>
>>>>>>> 3. The following code looks strange (two titles?)
>>>>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>>>>> ...
>>>>>>>  47         frame.setTitle("why why why");
>>>>>>>
>>>>>>> 4. The test method should be on the EDT
>>>>>>>
>>>>>>> 5. There is no need to use the mainPanel field. Logically it 
>>>>>>> should be local variable
>>>>>>>
>>>>>>> BTW: can you start with the fix for jdk8 and only then backport 
>>>>>>> it to jdk7?
>>>>>>>
>>>>>>> Regards, Pavel
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following fix for a bug.
>>>>>>>>
>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>>>>
>>>>>>>> For details on this bug please look at "Evaluation" field on a 
>>>>>>>> web page of this bug. The provided webrev contains both a fix 
>>>>>>>> and a corresponding unit-test. Before publishing this webrev 
>>>>>>>> all unit-tests from the "java.awt" and
>>>>>>>> "javax.swing" related to serialization were run and no negative 
>>>>>>>> changes were observed comparing the results of tests' runs on 
>>>>>>>> JDK with and without patch represented by this webrev.
>>>>>>>>
>>>>>>>> This is the second version of the fix. The first version was 
>>>>>>>> submitted to the AWT development group through a review request 
>>>>>>>> with the same subject and after discussion with engineers and 
>>>>>>>> additional investigation of the problem it was decided to apply 
>>>>>>>> the fix in Swing part of JDK.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>
>>>>>
>>



From anton.litvinov at oracle.com  Fri Aug 31 15:12:17 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 31 Aug 2012 19:12:17 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <5040C0EE.6040603@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com> <503F8321.1060804@oracle.com>
	<50409686.3090800@oracle.com> <5040A188.7030302@oracle.com>
	<5040C0EE.6040603@oracle.com>
Message-ID: <5040D451.7050501@oracle.com>

Hello Pavel,

Please look at a new webrev with corrections reflecting your remarks. 
Extra "catch (RuntimeException)" blocks were eliminated. On line 70, 
only "IOException" cannot be used, because "ClassNotFoundException" 
should be handled also.

Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.04

Thank you,
Anton

On 31.08.2012 17:49, Pavel Porvatov wrote:
> Hi Anton,
>> Hello Pavel,
>>
>> Thank you for the response with remarks. Yes, one additional "catch 
>> (RuntimeException re)" block was added in my previous webrev. I 
>> decided to add such a block, because of two following reasons:
>>
>> 1. To make an output stack trace shorter, but still containing a 
>> stack trace of the expected NullPointerException, in case if such 
>> exception is caught. Otherwise the final stack trace will contain 3 
>> exceptions, where only the third one is informational. This change 
>> simplifies manual testing by diminishing a number of lines necessary 
>> for reading.
>> 2. To eliminate extra folding of RuntimeException into a new 
>> RuntimeException, which did not happen at all.
> Why don't you catch just one IOException? I think it will solve both 
> the problem described above and will look shorter and clearer for 
> other people?
>
> Regards, Pavel
>
>>
>> A similar approach was applied to "try/catch" block in "serializeGUI" 
>> method for making the whole test consistent in the current webrev.
>>
>> Thank you,
>> Anton
>>
>> On 31.08.2012 14:48, Pavel Porvatov wrote:
>>> Hi Anton,
>>>
>>> I see you added
>>>  57         } catch (RuntimeException re) {
>>>  58             throw re;
>>>
>>> in serializeGUI method. Is it necessary? I think lines 72 and 73 can 
>>> be removed as well...  I didn't noticed that code in the previous 
>>> webrev, unfortunately.
>>>
>>> Regards, Pavel
>>>> Hello Pavel,
>>>>
>>>> Could you review a new webrev with code changes reflecting your 
>>>> last remark concerning a substitution of File streams for Byte 
>>>> streams in the test class. The test was checked using "jtreg". It 
>>>> fails on JDK 7 without this fix, and passes on JDK 7 with fix. URL 
>>>> of the new webrev is the following.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 29.08.2012 20:54, Anton Litvinov wrote:
>>>>> Hello Pavel,
>>>>>
>>>>> Yes, the test fails on JDK 7 without fix and does not fail on JDK 
>>>>> 7 with fix. Yes, I will definitely prefer to substitute the code 
>>>>> writing data to files for a code writing data to byte streams.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 29.08.2012 19:04, Pavel Porvatov wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> Does the test fail without the fix?
>>>>>>
>>>>>> All code look good except one thing: could you please replace 
>>>>>> FileStreams by Byte streams? Regression tests should avoid to 
>>>>>> change file system, and if there is such need tests should 
>>>>>> restore file system in initial state
>>>>>>> Hello Pavel,
>>>>>>>
>>>>>>> Thank you very much for a positive review of the fix and 
>>>>>>> detailed remarks for the test. Could you review a corrected 
>>>>>>> version of the test in a new webrev. I would like to clarify 
>>>>>>> that a previous version of the test contained some irrelevant 
>>>>>>> components, because I was not sure if I could significantly 
>>>>>>> modify the original test case provided with the bug itself. URL 
>>>>>>> of a webrev with the test class corrected according to your 
>>>>>>> remarks is provided below.
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>>>>>
>>>>>>> The modified test was checked using "jtreg" tool on JDK with and 
>>>>>>> without this fix, and the test behaved properly. The following 
>>>>>>> changes were made:
>>>>>>> 1. Setting visibility of frames was removed, because it  does 
>>>>>>> not influence reproducibility of the test.
>>>>>>> 2. All components except JPanel and JComboBox were eliminated 
>>>>>>> from the test.
>>>>>>> 3. Frames' titles were corrected.
>>>>>>> 4. Method "test" was renamed and moved into EDT execution block.
>>>>>>> 5. Method "createAndShowGUI" was renamed.
>>>>>>> 6. Calls to JFrame's "dispose" method were added.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> The fix looks good but the test should be updated:
>>>>>>>>
>>>>>>>> 1. Is the following line needed for the test:
>>>>>>>> 63         frame.setVisible(true);
>>>>>>>> ?
>>>>>>>> If yes then you should use SunToolkit.realSync to wait until 
>>>>>>>> frame become visible.
>>>>>>>> The same comment for the line
>>>>>>>> 85         frame.setVisible(true);
>>>>>>>>
>>>>>>>> 2. Are label and layout and layout needed for the test purpose? 
>>>>>>>> If no, can you remove unused components?
>>>>>>>>
>>>>>>>> 3. The following code looks strange (two titles?)
>>>>>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>>>>>> ...
>>>>>>>>  47         frame.setTitle("why why why");
>>>>>>>>
>>>>>>>> 4. The test method should be on the EDT
>>>>>>>>
>>>>>>>> 5. There is no need to use the mainPanel field. Logically it 
>>>>>>>> should be local variable
>>>>>>>>
>>>>>>>> BTW: can you start with the fix for jdk8 and only then backport 
>>>>>>>> it to jdk7?
>>>>>>>>
>>>>>>>> Regards, Pavel
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>
>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>>>>>
>>>>>>>>> For details on this bug please look at "Evaluation" field on a 
>>>>>>>>> web page of this bug. The provided webrev contains both a fix 
>>>>>>>>> and a corresponding unit-test. Before publishing this webrev 
>>>>>>>>> all unit-tests from the "java.awt" and
>>>>>>>>> "javax.swing" related to serialization were run and no 
>>>>>>>>> negative changes were observed comparing the results of tests' 
>>>>>>>>> runs on JDK with and without patch represented by this webrev.
>>>>>>>>>
>>>>>>>>> This is the second version of the fix. The first version was 
>>>>>>>>> submitted to the AWT development group through a review 
>>>>>>>>> request with the same subject and after discussion with 
>>>>>>>>> engineers and additional investigation of the problem it was 
>>>>>>>>> decided to apply the fix in Swing part of JDK.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>
>>>>>>
>>>
>


From pavel.porvatov at oracle.com  Fri Aug 31 15:41:34 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 31 Aug 2012 19:41:34 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <5040D451.7050501@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com> <503F8321.1060804@oracle.com>
	<50409686.3090800@oracle.com> <5040A188.7030302@oracle.com>
	<5040C0EE.6040603@oracle.com> <5040D451.7050501@oracle.com>
Message-ID: <5040DB2E.4070405@oracle.com>

Hi Anton,

Looks good for me

Regards, Pavel
> Hello Pavel,
>
> Please look at a new webrev with corrections reflecting your remarks. 
> Extra "catch (RuntimeException)" blocks were eliminated. On line 70, 
> only "IOException" cannot be used, because "ClassNotFoundException" 
> should be handled also.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.04
>
> Thank you,
> Anton
>
> On 31.08.2012 17:49, Pavel Porvatov wrote:
>> Hi Anton,
>>> Hello Pavel,
>>>
>>> Thank you for the response with remarks. Yes, one additional "catch 
>>> (RuntimeException re)" block was added in my previous webrev. I 
>>> decided to add such a block, because of two following reasons:
>>>
>>> 1. To make an output stack trace shorter, but still containing a 
>>> stack trace of the expected NullPointerException, in case if such 
>>> exception is caught. Otherwise the final stack trace will contain 3 
>>> exceptions, where only the third one is informational. This change 
>>> simplifies manual testing by diminishing a number of lines necessary 
>>> for reading.
>>> 2. To eliminate extra folding of RuntimeException into a new 
>>> RuntimeException, which did not happen at all.
>> Why don't you catch just one IOException? I think it will solve both 
>> the problem described above and will look shorter and clearer for 
>> other people?
>>
>> Regards, Pavel
>>
>>>
>>> A similar approach was applied to "try/catch" block in 
>>> "serializeGUI" method for making the whole test consistent in the 
>>> current webrev.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 31.08.2012 14:48, Pavel Porvatov wrote:
>>>> Hi Anton,
>>>>
>>>> I see you added
>>>>  57         } catch (RuntimeException re) {
>>>>  58             throw re;
>>>>
>>>> in serializeGUI method. Is it necessary? I think lines 72 and 73 
>>>> can be removed as well...  I didn't noticed that code in the 
>>>> previous webrev, unfortunately.
>>>>
>>>> Regards, Pavel
>>>>> Hello Pavel,
>>>>>
>>>>> Could you review a new webrev with code changes reflecting your 
>>>>> last remark concerning a substitution of File streams for Byte 
>>>>> streams in the test class. The test was checked using "jtreg". It 
>>>>> fails on JDK 7 without this fix, and passes on JDK 7 with fix. URL 
>>>>> of the new webrev is the following.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 29.08.2012 20:54, Anton Litvinov wrote:
>>>>>> Hello Pavel,
>>>>>>
>>>>>> Yes, the test fails on JDK 7 without fix and does not fail on JDK 
>>>>>> 7 with fix. Yes, I will definitely prefer to substitute the code 
>>>>>> writing data to files for a code writing data to byte streams.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 29.08.2012 19:04, Pavel Porvatov wrote:
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> Does the test fail without the fix?
>>>>>>>
>>>>>>> All code look good except one thing: could you please replace 
>>>>>>> FileStreams by Byte streams? Regression tests should avoid to 
>>>>>>> change file system, and if there is such need tests should 
>>>>>>> restore file system in initial state
>>>>>>>> Hello Pavel,
>>>>>>>>
>>>>>>>> Thank you very much for a positive review of the fix and 
>>>>>>>> detailed remarks for the test. Could you review a corrected 
>>>>>>>> version of the test in a new webrev. I would like to clarify 
>>>>>>>> that a previous version of the test contained some irrelevant 
>>>>>>>> components, because I was not sure if I could significantly 
>>>>>>>> modify the original test case provided with the bug itself. URL 
>>>>>>>> of a webrev with the test class corrected according to your 
>>>>>>>> remarks is provided below.
>>>>>>>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>>>>>>
>>>>>>>> The modified test was checked using "jtreg" tool on JDK with 
>>>>>>>> and without this fix, and the test behaved properly. The 
>>>>>>>> following changes were made:
>>>>>>>> 1. Setting visibility of frames was removed, because it  does 
>>>>>>>> not influence reproducibility of the test.
>>>>>>>> 2. All components except JPanel and JComboBox were eliminated 
>>>>>>>> from the test.
>>>>>>>> 3. Frames' titles were corrected.
>>>>>>>> 4. Method "test" was renamed and moved into EDT execution block.
>>>>>>>> 5. Method "createAndShowGUI" was renamed.
>>>>>>>> 6. Calls to JFrame's "dispose" method were added.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>>
>>>>>>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>>>>>>> Hi Anton,
>>>>>>>>>
>>>>>>>>> The fix looks good but the test should be updated:
>>>>>>>>>
>>>>>>>>> 1. Is the following line needed for the test:
>>>>>>>>> 63         frame.setVisible(true);
>>>>>>>>> ?
>>>>>>>>> If yes then you should use SunToolkit.realSync to wait until 
>>>>>>>>> frame become visible.
>>>>>>>>> The same comment for the line
>>>>>>>>> 85         frame.setVisible(true);
>>>>>>>>>
>>>>>>>>> 2. Are label and layout and layout needed for the test 
>>>>>>>>> purpose? If no, can you remove unused components?
>>>>>>>>>
>>>>>>>>> 3. The following code looks strange (two titles?)
>>>>>>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>>>>>>> ...
>>>>>>>>>  47         frame.setTitle("why why why");
>>>>>>>>>
>>>>>>>>> 4. The test method should be on the EDT
>>>>>>>>>
>>>>>>>>> 5. There is no need to use the mainPanel field. Logically it 
>>>>>>>>> should be local variable
>>>>>>>>>
>>>>>>>>> BTW: can you start with the fix for jdk8 and only then 
>>>>>>>>> backport it to jdk7?
>>>>>>>>>
>>>>>>>>> Regards, Pavel
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>>
>>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>>>>>>
>>>>>>>>>> For details on this bug please look at "Evaluation" field on 
>>>>>>>>>> a web page of this bug. The provided webrev contains both a 
>>>>>>>>>> fix and a corresponding unit-test. Before publishing this 
>>>>>>>>>> webrev all unit-tests from the "java.awt" and
>>>>>>>>>> "javax.swing" related to serialization were run and no 
>>>>>>>>>> negative changes were observed comparing the results of 
>>>>>>>>>> tests' runs on JDK with and without patch represented by this 
>>>>>>>>>> webrev.
>>>>>>>>>>
>>>>>>>>>> This is the second version of the fix. The first version was 
>>>>>>>>>> submitted to the AWT development group through a review 
>>>>>>>>>> request with the same subject and after discussion with 
>>>>>>>>>> engineers and additional investigation of the problem it was 
>>>>>>>>>> decided to apply the fix in Swing part of JDK.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>
>>>>
>>



From anton.litvinov at oracle.com  Fri Aug 31 15:51:42 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 31 Aug 2012 19:51:42 +0400
Subject: <Swing Dev> [7u8] Review request for 7193219: JComboBox
 serialization fails in JDK 1.7
In-Reply-To: <5040DB2E.4070405@oracle.com>
References: <503CEEBD.8070307@oracle.com> <503D03BB.8080502@oracle.com>
	<503E07F6.7050903@oracle.com> <503E2F76.7050909@oracle.com>
	<503E4943.6050202@oracle.com> <503F8321.1060804@oracle.com>
	<50409686.3090800@oracle.com> <5040A188.7030302@oracle.com>
	<5040C0EE.6040603@oracle.com> <5040D451.7050501@oracle.com>
	<5040DB2E.4070405@oracle.com>
Message-ID: <5040DD8E.1010405@oracle.com>

Hello Pavel,

Thank you very much for an approval of the last webrev.

Anton

On 31.08.2012 19:41, Pavel Porvatov wrote:
> Hi Anton,
>
> Looks good for me
>
> Regards, Pavel
>> Hello Pavel,
>>
>> Please look at a new webrev with corrections reflecting your remarks. 
>> Extra "catch (RuntimeException)" blocks were eliminated. On line 70, 
>> only "IOException" cannot be used, because "ClassNotFoundException" 
>> should be handled also.
>>
>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.04
>>
>> Thank you,
>> Anton
>>
>> On 31.08.2012 17:49, Pavel Porvatov wrote:
>>> Hi Anton,
>>>> Hello Pavel,
>>>>
>>>> Thank you for the response with remarks. Yes, one additional "catch 
>>>> (RuntimeException re)" block was added in my previous webrev. I 
>>>> decided to add such a block, because of two following reasons:
>>>>
>>>> 1. To make an output stack trace shorter, but still containing a 
>>>> stack trace of the expected NullPointerException, in case if such 
>>>> exception is caught. Otherwise the final stack trace will contain 3 
>>>> exceptions, where only the third one is informational. This change 
>>>> simplifies manual testing by diminishing a number of lines 
>>>> necessary for reading.
>>>> 2. To eliminate extra folding of RuntimeException into a new 
>>>> RuntimeException, which did not happen at all.
>>> Why don't you catch just one IOException? I think it will solve both 
>>> the problem described above and will look shorter and clearer for 
>>> other people?
>>>
>>> Regards, Pavel
>>>
>>>>
>>>> A similar approach was applied to "try/catch" block in 
>>>> "serializeGUI" method for making the whole test consistent in the 
>>>> current webrev.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 31.08.2012 14:48, Pavel Porvatov wrote:
>>>>> Hi Anton,
>>>>>
>>>>> I see you added
>>>>>  57         } catch (RuntimeException re) {
>>>>>  58             throw re;
>>>>>
>>>>> in serializeGUI method. Is it necessary? I think lines 72 and 73 
>>>>> can be removed as well...  I didn't noticed that code in the 
>>>>> previous webrev, unfortunately.
>>>>>
>>>>> Regards, Pavel
>>>>>> Hello Pavel,
>>>>>>
>>>>>> Could you review a new webrev with code changes reflecting your 
>>>>>> last remark concerning a substitution of File streams for Byte 
>>>>>> streams in the test class. The test was checked using "jtreg". It 
>>>>>> fails on JDK 7 without this fix, and passes on JDK 7 with fix. 
>>>>>> URL of the new webrev is the following.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.03
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 29.08.2012 20:54, Anton Litvinov wrote:
>>>>>>> Hello Pavel,
>>>>>>>
>>>>>>> Yes, the test fails on JDK 7 without fix and does not fail on 
>>>>>>> JDK 7 with fix. Yes, I will definitely prefer to substitute the 
>>>>>>> code writing data to files for a code writing data to byte streams.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 29.08.2012 19:04, Pavel Porvatov wrote:
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> Does the test fail without the fix?
>>>>>>>>
>>>>>>>> All code look good except one thing: could you please replace 
>>>>>>>> FileStreams by Byte streams? Regression tests should avoid to 
>>>>>>>> change file system, and if there is such need tests should 
>>>>>>>> restore file system in initial state
>>>>>>>>> Hello Pavel,
>>>>>>>>>
>>>>>>>>> Thank you very much for a positive review of the fix and 
>>>>>>>>> detailed remarks for the test. Could you review a corrected 
>>>>>>>>> version of the test in a new webrev. I would like to clarify 
>>>>>>>>> that a previous version of the test contained some irrelevant 
>>>>>>>>> components, because I was not sure if I could significantly 
>>>>>>>>> modify the original test case provided with the bug itself. 
>>>>>>>>> URL of a webrev with the test class corrected according to 
>>>>>>>>> your remarks is provided below.
>>>>>>>>>
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.02
>>>>>>>>>
>>>>>>>>> The modified test was checked using "jtreg" tool on JDK with 
>>>>>>>>> and without this fix, and the test behaved properly. The 
>>>>>>>>> following changes were made:
>>>>>>>>> 1. Setting visibility of frames was removed, because it  does 
>>>>>>>>> not influence reproducibility of the test.
>>>>>>>>> 2. All components except JPanel and JComboBox were eliminated 
>>>>>>>>> from the test.
>>>>>>>>> 3. Frames' titles were corrected.
>>>>>>>>> 4. Method "test" was renamed and moved into EDT execution block.
>>>>>>>>> 5. Method "createAndShowGUI" was renamed.
>>>>>>>>> 6. Calls to JFrame's "dispose" method were added.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>> On 28.08.2012 21:45, Pavel Porvatov wrote:
>>>>>>>>>> Hi Anton,
>>>>>>>>>>
>>>>>>>>>> The fix looks good but the test should be updated:
>>>>>>>>>>
>>>>>>>>>> 1. Is the following line needed for the test:
>>>>>>>>>> 63         frame.setVisible(true);
>>>>>>>>>> ?
>>>>>>>>>> If yes then you should use SunToolkit.realSync to wait until 
>>>>>>>>>> frame become visible.
>>>>>>>>>> The same comment for the line
>>>>>>>>>> 85         frame.setVisible(true);
>>>>>>>>>>
>>>>>>>>>> 2. Are label and layout and layout needed for the test 
>>>>>>>>>> purpose? If no, can you remove unused components?
>>>>>>>>>>
>>>>>>>>>> 3. The following code looks strange (two titles?)
>>>>>>>>>>  45         JFrame frame = new JFrame("HelloWorldSwing");
>>>>>>>>>> ...
>>>>>>>>>>  47         frame.setTitle("why why why");
>>>>>>>>>>
>>>>>>>>>> 4. The test method should be on the EDT
>>>>>>>>>>
>>>>>>>>>> 5. There is no need to use the mainPanel field. Logically it 
>>>>>>>>>> should be local variable
>>>>>>>>>>
>>>>>>>>>> BTW: can you start with the fix for jdk8 and only then 
>>>>>>>>>> backport it to jdk7?
>>>>>>>>>>
>>>>>>>>>> Regards, Pavel
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>>>
>>>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/7193219/webrev.01
>>>>>>>>>>>
>>>>>>>>>>> For details on this bug please look at "Evaluation" field on 
>>>>>>>>>>> a web page of this bug. The provided webrev contains both a 
>>>>>>>>>>> fix and a corresponding unit-test. Before publishing this 
>>>>>>>>>>> webrev all unit-tests from the "java.awt" and
>>>>>>>>>>> "javax.swing" related to serialization were run and no 
>>>>>>>>>>> negative changes were observed comparing the results of 
>>>>>>>>>>> tests' runs on JDK with and without patch represented by 
>>>>>>>>>>> this webrev.
>>>>>>>>>>>
>>>>>>>>>>> This is the second version of the fix. The first version was 
>>>>>>>>>>> submitted to the AWT development group through a review 
>>>>>>>>>>> request with the same subject and after discussion with 
>>>>>>>>>>> engineers and additional investigation of the problem it was 
>>>>>>>>>>> decided to apply the fix in Swing part of JDK.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Anton
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>


From pavel.porvatov at oracle.com  Fri Aug 31 16:50:08 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 31 Aug 2012 20:50:08 +0400
Subject: <Swing Dev> [7] Review request for 7123767 Wrong tooltip
 location in Multi-Monitor configurations
In-Reply-To: <503B6F25.9030009@oracle.com>
References: <5016903D.8010104@oracle.com> <502E7B01.1050801@oracle.com>
	<503B6F25.9030009@oracle.com>
Message-ID: <5040EB40.1070705@oracle.com>

Hi Vladislav,

I have several comments about the fix:
1. getDrawingRect: now localInsets should be requested only if 
localRect.contains(toFind) is true
2.
+                // Something's really wrong here - use the screen that our
+                // Component belongs to
+                if (workingBounds == null)
+                    workingBounds = 
insideComponent.getGraphicsConfiguration().getBounds();
a. You should always use {...} for if construction
b. It seems we should invoke adjustInsets there. To reduce the code I 
think you can rename getDrawingRect into getGraphicsConfiguration and 
return GraphicsConfiguration there. And only when GraphicsConfiguration 
is found calculate adjusted bounds...
3. getDrawingRect comment should have two ")" at the end

Abou the test:
1. You should use Toolkit.realSync after setVisible
2. I run the test on jdk1.8.0b51 and it passes. Looks strange...

Regards, Pavel
> Hi Pavel, all,
>
> please find new webrev here: 
> http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.02/
> Please see my comments inline.
>
> Regards,
> - Vlad
>
> On 8/17/2012 9:10 PM, Pavel Porvatov wrote:
>> Hi Vladislav,
>>
>> I have several comments about the fix:
>>
>> 1. javax.swing.ToolTipManager#showTipWindow: I think toFind variable 
>> should be initialized in if(preferredLocation != null) { ....} else 
>> {...} block. It looks more logical and code will be more compact 
>> (adjustedPreferredLocation can be removed at all, I think)
> Agreed. I've re-worked this piece.
>
>>
>> 2. Could you please explain why you are using union of all rectangles 
>> in the getDrawingRect method? In case two monitors are aligned on a 
>> diagonal totalRect will contain areas that are not covered by screen 
>> devices and popups can be placed incorrectly.
> Agreed again. I've re-designed getDrawingRect() function and placed 
> additional condition into showTipWindow() function; now every 
> situation should be handled correctly.
>
> Automated test was added, please see the webrev.
>
> Regards,
> - Vlad
>
>>
>> Regards, Pavel
>>
>>> Hello,
>>>
>>> please review the fix for 7123767: Wrong tooltip location in 
>>> Multi-Monitor configurations
>>>
>>> jdk7 webrev: http://cr.openjdk.java.net/~vkarnauk/7123767/webrev.00/
>>> test source: http://cr.openjdk.java.net/~vkarnauk/7123767/test/
>>> bug description: 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123767
>>>
>>> This is also a customer escalated issue in jdk6.
>>>
>>> On multi-monitor configurations Component.getLocationOnScreen() may 
>>> return negative values. Additionally, ToolTipManager.showTipWindow() 
>>> method calculates tip window location from Component' 
>>> getLocationOnScreen() return data and draws tip window using the 
>>> same GraphicsConfiguration instance as component's top-left corner, 
>>> which again can be of negative value. When component is stretched 
>>> across multiple screen devices, this may lead to a situation when 
>>> it's tooltip is drawn on wrong monitor.
>>>
>>> To fix this we should count all GraphicsConfiguration instances and 
>>> determine correct screen device to draw on. We should also take into 
>>> account that:
>>> 1) tip window preferred location could be set
>>> 2) preferred location could be greater than total virtual bounds of 
>>> all monitors. To make tip window visible in such case we move it to 
>>> the corresponding corner of total virtual bounds
>>> 3) exact order of monitors (left-to-right and top-to-bottom) is unknown
>>>
>>> I run jtreg against ToolTipManager tests and all tests passed (I run 
>>> it several times with different monitor configurations). I also 
>>> tested the fix with custom test program (please see the link 
>>> provided) with 4 possible monitor configurations (left-to-right, 
>>> right-to-left, top-to-bottom and bottom-to-top) and saw no issues.
>>>
>>> I added no new automated test(s) because this at least would require 
>>> multiple monitors to run.
>>>
>>> Regards,
>>> - Vlad
>>
>
>