From luchsh at linux.vnet.ibm.com  Sun Apr  1 03:16:22 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Sun, 01 Apr 2012 11:16:22 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F71D2AF.80307@oracle.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com> <4F71D2AF.80307@oracle.com>
Message-ID: <4F77C886.10507@linux.vnet.ibm.com>

Hi Pavel,

Here's the updated patch, including proposed solution for interior focus.
http://cr.openjdk.java.net/~luchsh/7155887_3/

In the orginal code as I understood, focus is only paint when 
!interiorFocus, in which case the background shadow and flatBox will 
shrink a bit to corperate with the outer focus whose size is same as the 
original component. My proposed solution is to shirink focus line for 
interior focus, but keep the same way of !interorFocus.

could you pls take a look?

On 03/27/2012 10:46 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>
> What do you think about another solution: can we set component state 
> as SynthConstants.FOCUSED before paintTextBackground is invoked. 
> Another solution is to set state as "focused" for ComboBox renderer 
> like the following:
>
>         if ("ComboBox.renderer".equals(c.getName())) {
>             for (Component comboBoxParent = c.getParent(); 
> comboBoxParent != null; comboBoxParent = comboBoxParent.getParent()) {
>                 if (comboBoxParent instanceof JComboBox){
>                     if(comboBoxParent.hasFocus()){
>                         state |= SynthConstants.FOCUSED;
>                     }
>                     break;
>                 }
>             }
>         }
> without other changes in GTKPainter.java (actually there is some 
> problem with "interiorFocus", but it could be resolved....)
>
> See also my answers below.
>> Hi Pavel,
>>
>> Thanks for review, here's the new patch and my answers are inlined.
>> http://cr.openjdk.java.net/~luchsh/7155887_2/
>>
>> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Swing-dev,
>>>>
>>>> ComboBox on linux GTK L&F does not works as gtk native 
>>>> applications, when get focused, the apperance of Java ComboBox 
>>>> remains unchanged but native GTK ComboBox control will have a 
>>>> outline to indicate it has got focused.
>>>>
>>>> The problem seems similar to bug
>>>> 6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>>> another bug
>>>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>>> was created for this issue,
>>>>
>>>> And here's the proposed patch to fix this problem,
>>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>>
>>>> Could anybody please help to take a look?
>>> I have several comments about the patch:
>>>
>>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get NPE 
>>> here
>> Yes, I've changed it to
>>
>> "ComboBox.renderer".equals(c.getName())
>>
>>>
>>> 2.
>>> +            for (Component comboBoxParent = c.getParent(); 
>>> comboBoxParent != null; comboBoxParent = comboBoxParent
>>> +                    .getParent()) {
>>> +                if (comboBoxParent instanceof JComboBox
>>> + && comboBoxParent.hasFocus()) {
>>> +                    comboBoxFocused = true;
>>> +                }
>>> +            }
>>>
>>> I'm not sure we should do such deep parent investigation. Why don't 
>>> you check first parent only?
>>>
>> javax.swing.CellRendererPane is inserted between the component and 
>> renderer, so if check only the first parent, it will retrieve a 
>> CellRendererPane object instead of JComboBox component. In the new 
>> patch, I added a break when JComboBox is encounterred so to make the 
>> effect similar to the first-parent-only approach.
> I found out the following code (see 
> com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
>         if (c instanceof ListCellRenderer &&
>                  container != null &&
>                  container.getParent() instanceof JComboBox ) {
>             ...
>         }
> I think we should use the same pattern
>>
>>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>>> !comboBoxFocused)"
>>> If you are going to ignore ENGINE.paintCachedImage when 
>>> comboBoxFocused, then there is no need to invoke it at all
>>>
>> yes, in the new patch I've changed the order of these two checks.
>>> 4. "if (comboBoxFocused || focusSize > 0)"
>>> I'm not sure we should paint focus if focusSize == 0
>>>
>> I think there's no need to paint the focus if focusSize ==0, since 
>> the focus width and height arguements passed to JNI method 
>> native_paint_focus() will both be zero.
> That's what I meant! (may be my phrase was not clear enough)
> Your condition "if (comboBoxFocused || focusSize > 0)" allows to paint 
> focus even if focusSize == 0...
>
Oh, sorry for my misunderstanding, the previous patch indeed got such a 
problem, but it may not be in the new patch.
> Regards, Pavel

Thanks and best regards!

- Jonathan



From alexlamsl at gmail.com  Sun Apr  1 19:25:36 2012
From: alexlamsl at gmail.com (Alex Lam S.L.)
Date: Sun, 1 Apr 2012 20:25:36 +0100
Subject: <Swing Dev> JSeparator rendered incorrectly on Windows 7
In-Reply-To: <4F757BE7.5040800@oracle.com>
References: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>
	<4F757BE7.5040800@oracle.com>
Message-ID: <CAGpACNuxFjUURWV0RwLcaWTWr+X3rrSTPU9cwCZBtRp09YojaA@mail.gmail.com>

Hi there,

I will try and narrow it down to a simple(r) test case and get back to you.


Regards,
Alex.



On Fri, Mar 30, 2012 at 10:24 AM, Pavel Porvatov
<pavel.porvatov at oracle.com> wrote:
> Hi Alex,
>
> Can you sent a small separated test? I used SwingSet2 demo with the same
> Windows and jdk versions and the problem is not reproducible...
>
> Thanks, Pavel
>
>
>> Hi there,
>>
>> I noticed that in some cases JSeparator would render differently (see
>> attached photo - first one from the top, left window).
>>
>> It is repeatable - I can quit and re-run the app and the same
>> JSeparator would be wrong. Curiously, I use the preview feature from
>> NetBeans for the project code which generates this window, and the
>> problem does not appear there.
>>
>>
>> Confused,
>> Alex.
>>
>> ---------------
>>
>> Microsoft Windows [Version 6.1.7601]
>>
>> java version "1.7.0_02"
>> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
>> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
>
>


From pavel.porvatov at oracle.com  Mon Apr  2 14:21:53 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 02 Apr 2012 18:21:53 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
Message-ID: <4F79B601.8050905@oracle.com>

Hi Mario,

I'd suggest to change the javax.swing.JPopupMenu#getPopup method:

         if (isLightWeightPopupEnabled()) {
             popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
         }
         else {
             popupFactory.setPopupType(PopupFactory.HEAVY_WEIGHT_POPUP); 
// Replaced MEDIUM_WEIGHT_POPUP
         }

I don't see any regressions, what do you think about that?

Regards, Pavel

> Hi all,
>
> Recently I came across this bug on our bug database:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=658654
>
> This is actually a long standing issue that bothered me too for quite
> some time, since the net result is that Java applications look weird
> in some situation (specifically with the native LAF, but also with the
> default ones).
>
> I think a quick and easy solution that would preserve backward
> compatibility would be to add a system property that allows forcing
> heavy weight rather then medium weight behaviour for popup windows.
>
> Most of the code is already in place, so probably the changes could
> either go in JPopupMenu.getPopup with the additional advantage of
> being quite circumscribed, for example:
>
>          PopupFactory popupFactory = PopupFactory.getSharedInstance();
>
>          if (isLightWeightPopupEnabled()) {
>              popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
>          }
>          else if (forceAlwaysHWMenues()) {
>              popupFactory.setPopupType(PopupFactory.HEAVY_WEIGHT_POPUP);
>          }
>          else {
>              popupFactory.setPopupType(PopupFactory.MEDIUM_WEIGHT_POPUP);
>          }
>
> or in a more general place forcing this to all the popup components to
> be HW. This change could be for example in JPopupFactory.getPopupType,
> right before the beginning of the method, for example:
>
>          if (owner == null || invokerInHeavyWeightPopup(owner) ||
>              getProperty(PopupFactory_FORCE_HEAVYWEIGHT_POPUP) {
>              popupType = HEAVY_WEIGHT_POPUP;
>          } else if (popupType == LIGHT_WEIGHT_POPUP&&
>                   !(contents instanceof JToolTip)&&
>                   !(contents instanceof JPopupMenu)) {
>              popupType = MEDIUM_WEIGHT_POPUP;
>          }
>
> I personally don't see much risk for either, but the latter has
> definitely more impact, so having things local to JPopupMenu seems
> better (disclaimer, I didn't try those changes, so maybe more tweaking
> is needed).
>
> What do you think?
>
> I would propose those changes for JKD8 of course.
>
> Cheers,
> Mario
>
> P.S. I'm not sure if I should include the AWT team in the loop too.



From pavel.porvatov at oracle.com  Tue Apr  3 11:45:00 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 03 Apr 2012 15:45:00 +0400
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F77C886.10507@linux.vnet.ibm.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com>
	<4F71D2AF.80307@oracle.com> <4F77C886.10507@linux.vnet.ibm.com>
Message-ID: <4F7AE2BC.1080601@oracle.com>

Hi Jonathan,

I have several comments:
1. containerParent instanceof JComboBox && containerParent != null
it is not necessary to check "containerParent != null" here

2.
-            if (!interiorFocus && (state & SynthConstants.FOCUSED) != 0) {
+
                  focusSize = style.getClassSpecificIntValue(context,
                          "focus-line-width",1);
+            if (!interiorFocus && (state & SynthConstants.FOCUSED) != 0) {
I don't see here any changes

3. Could you please explain the following changes?
-            if (focusSize > 0) {
+            if (focusSize > 0 && (state & SynthConstants.FOCUSED) != 0) {
+                if (interiorFocus) {
+                    x += focusSize;
+                    y += focusSize;
+                    w -= 2 * focusSize;
+                    h -= 2 * focusSize;
+                } else {


I applied the patch and observe that focused JComboBox looks strange 
(see attachments):
a. Native focus uses solid line
b. Native focused JComboBox paints focus rectangle across whole JComboBox

Regards, Pavel
> Hi Pavel,
>
> Here's the updated patch, including proposed solution for interior focus.
> http://cr.openjdk.java.net/~luchsh/7155887_3/
>
> In the orginal code as I understood, focus is only paint when 
> !interiorFocus, in which case the background shadow and flatBox will 
> shrink a bit to corperate with the outer focus whose size is same as 
> the original component. My proposed solution is to shirink focus line 
> for interior focus, but keep the same way of !interorFocus.
>
> could you pls take a look?
>
> On 03/27/2012 10:46 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>
>> What do you think about another solution: can we set component state 
>> as SynthConstants.FOCUSED before paintTextBackground is invoked. 
>> Another solution is to set state as "focused" for ComboBox renderer 
>> like the following:
>>
>>         if ("ComboBox.renderer".equals(c.getName())) {
>>             for (Component comboBoxParent = c.getParent(); 
>> comboBoxParent != null; comboBoxParent = comboBoxParent.getParent()) {
>>                 if (comboBoxParent instanceof JComboBox){
>>                     if(comboBoxParent.hasFocus()){
>>                         state |= SynthConstants.FOCUSED;
>>                     }
>>                     break;
>>                 }
>>             }
>>         }
>> without other changes in GTKPainter.java (actually there is some 
>> problem with "interiorFocus", but it could be resolved....)
>>
>> See also my answers below.
>>> Hi Pavel,
>>>
>>> Thanks for review, here's the new patch and my answers are inlined.
>>> http://cr.openjdk.java.net/~luchsh/7155887_2/
>>>
>>> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>> Hi Swing-dev,
>>>>>
>>>>> ComboBox on linux GTK L&F does not works as gtk native 
>>>>> applications, when get focused, the apperance of Java ComboBox 
>>>>> remains unchanged but native GTK ComboBox control will have a 
>>>>> outline to indicate it has got focused.
>>>>>
>>>>> The problem seems similar to bug
>>>>> 6947671 ( 
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>>>> another bug
>>>>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>>>> was created for this issue,
>>>>>
>>>>> And here's the proposed patch to fix this problem,
>>>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>>>
>>>>> Could anybody please help to take a look?
>>>> I have several comments about the patch:
>>>>
>>>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get 
>>>> NPE here
>>> Yes, I've changed it to
>>>
>>> "ComboBox.renderer".equals(c.getName())
>>>
>>>>
>>>> 2.
>>>> +            for (Component comboBoxParent = c.getParent(); 
>>>> comboBoxParent != null; comboBoxParent = comboBoxParent
>>>> +                    .getParent()) {
>>>> +                if (comboBoxParent instanceof JComboBox
>>>> + && comboBoxParent.hasFocus()) {
>>>> +                    comboBoxFocused = true;
>>>> +                }
>>>> +            }
>>>>
>>>> I'm not sure we should do such deep parent investigation. Why don't 
>>>> you check first parent only?
>>>>
>>> javax.swing.CellRendererPane is inserted between the component and 
>>> renderer, so if check only the first parent, it will retrieve a 
>>> CellRendererPane object instead of JComboBox component. In the new 
>>> patch, I added a break when JComboBox is encounterred so to make the 
>>> effect similar to the first-parent-only approach.
>> I found out the following code (see 
>> com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
>>         if (c instanceof ListCellRenderer &&
>>                  container != null &&
>>                  container.getParent() instanceof JComboBox ) {
>>             ...
>>         }
>> I think we should use the same pattern
>>>
>>>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>>>> !comboBoxFocused)"
>>>> If you are going to ignore ENGINE.paintCachedImage when 
>>>> comboBoxFocused, then there is no need to invoke it at all
>>>>
>>> yes, in the new patch I've changed the order of these two checks.
>>>> 4. "if (comboBoxFocused || focusSize > 0)"
>>>> I'm not sure we should paint focus if focusSize == 0
>>>>
>>> I think there's no need to paint the focus if focusSize ==0, since 
>>> the focus width and height arguements passed to JNI method 
>>> native_paint_focus() will both be zero.
>> That's what I meant! (may be my phrase was not clear enough)
>> Your condition "if (comboBoxFocused || focusSize > 0)" allows to 
>> paint focus even if focusSize == 0...
>>
> Oh, sorry for my misunderstanding, the previous patch indeed got such 
> a problem, but it may not be in the new patch.
>> Regards, Pavel
>
> Thanks and best regards!
>
> - Jonathan
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ver3.png
Type: image/png
Size: 6286 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120403/69838650/ver3.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: native.png
Type: image/png
Size: 5986 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120403/69838650/native.png>

From alexlamsl at gmail.com  Tue Apr  3 18:53:39 2012
From: alexlamsl at gmail.com (Alex Lam S.L.)
Date: Tue, 3 Apr 2012 19:53:39 +0100
Subject: <Swing Dev> JSeparator rendered incorrectly on Windows 7
In-Reply-To: <CAGpACNuxFjUURWV0RwLcaWTWr+X3rrSTPU9cwCZBtRp09YojaA@mail.gmail.com>
References: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>
	<4F757BE7.5040800@oracle.com>
	<CAGpACNuxFjUURWV0RwLcaWTWr+X3rrSTPU9cwCZBtRp09YojaA@mail.gmail.com>
Message-ID: <CAGpACNt2SjeajBkp+vEqdUUG-_H7XHvsXozbmQF52TfLpDELLg@mail.gmail.com>

Hi there,

I have found the cause of the problem - the difference between
JSeparator and JPopupMenu.Separator.

As I use the GUI builder on NetBeans, I don't know how or when it has
decided to slip in a single JSeparator into the mix.

Attached a simple test case demonstrating the problem, at least on Win7.

It's not a big deal to me now I've discovered the cause, although it
would be nice to know the difference between these two classes...


Regards,
Alex.




On Sun, Apr 1, 2012 at 8:25 PM, Alex Lam S.L. <alexlamsl at gmail.com> wrote:
> Hi there,
>
> I will try and narrow it down to a simple(r) test case and get back to you.
>
>
> Regards,
> Alex.
>
>
>
> On Fri, Mar 30, 2012 at 10:24 AM, Pavel Porvatov
> <pavel.porvatov at oracle.com> wrote:
>> Hi Alex,
>>
>> Can you sent a small separated test? I used SwingSet2 demo with the same
>> Windows and jdk versions and the problem is not reproducible...
>>
>> Thanks, Pavel
>>
>>
>>> Hi there,
>>>
>>> I noticed that in some cases JSeparator would render differently (see
>>> attached photo - first one from the top, left window).
>>>
>>> It is repeatable - I can quit and re-run the app and the same
>>> JSeparator would be wrong. Curiously, I use the preview feature from
>>> NetBeans for the project code which generates this window, and the
>>> problem does not appear there.
>>>
>>>
>>> Confused,
>>> Alex.
>>>
>>> ---------------
>>>
>>> Microsoft Windows [Version 6.1.7601]
>>>
>>> java version "1.7.0_02"
>>> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
>>> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MenuSeparator.java
Type: application/octet-stream
Size: 2018 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120403/dcee56bc/MenuSeparator.java>

From pavel.porvatov at oracle.com  Wed Apr  4 09:25:29 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 04 Apr 2012 13:25:29 +0400
Subject: <Swing Dev> JSeparator rendered incorrectly on Windows 7
In-Reply-To: <CAGpACNt2SjeajBkp+vEqdUUG-_H7XHvsXozbmQF52TfLpDELLg@mail.gmail.com>
References: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>
	<4F757BE7.5040800@oracle.com>
	<CAGpACNuxFjUURWV0RwLcaWTWr+X3rrSTPU9cwCZBtRp09YojaA@mail.gmail.com>
	<CAGpACNt2SjeajBkp+vEqdUUG-_H7XHvsXozbmQF52TfLpDELLg@mail.gmail.com>
Message-ID: <4F7C1389.4010102@oracle.com>

Hi Alex,
> Hi there,
>
> I have found the cause of the problem - the difference between
> JSeparator and JPopupMenu.Separator.
>
> As I use the GUI builder on NetBeans, I don't know how or when it has
> decided to slip in a single JSeparator into the mix.
>
> Attached a simple test case demonstrating the problem, at least on Win7.
>
> It's not a big deal to me now I've discovered the cause, although it
> would be nice to know the difference between these two classes...
There are three separators and they were designed for different purposes:
1. javax.swing.JSeparator (used for menus)
2. javax.swing.JPopupMenu.Separator (used for JPopupMenus)
3. javax.swing.JToolBar.Separator (used for JToolbars)

To avoid any confusion use correspondent separators in appropriate 
places or use addSeparator() methods from JMenu, JPopupMenu, and JToolbar.

Regards, Pavel
>
> Regards,
> Alex.
>
>
>
>
> On Sun, Apr 1, 2012 at 8:25 PM, Alex Lam S.L.<alexlamsl at gmail.com>  wrote:
>> Hi there,
>>
>> I will try and narrow it down to a simple(r) test case and get back to you.
>>
>>
>> Regards,
>> Alex.
>>
>>
>>
>> On Fri, Mar 30, 2012 at 10:24 AM, Pavel Porvatov
>> <pavel.porvatov at oracle.com>  wrote:
>>> Hi Alex,
>>>
>>> Can you sent a small separated test? I used SwingSet2 demo with the same
>>> Windows and jdk versions and the problem is not reproducible...
>>>
>>> Thanks, Pavel
>>>
>>>
>>>> Hi there,
>>>>
>>>> I noticed that in some cases JSeparator would render differently (see
>>>> attached photo - first one from the top, left window).
>>>>
>>>> It is repeatable - I can quit and re-run the app and the same
>>>> JSeparator would be wrong. Curiously, I use the preview feature from
>>>> NetBeans for the project code which generates this window, and the
>>>> problem does not appear there.
>>>>
>>>>
>>>> Confused,
>>>> Alex.
>>>>
>>>> ---------------
>>>>
>>>> Microsoft Windows [Version 6.1.7601]
>>>>
>>>> java version "1.7.0_02"
>>>> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
>>>



From alexandr.scherbatiy at oracle.com  Wed Apr  4 10:12:55 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 04 Apr 2012 14:12:55 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F757534.3040802@oracle.com>
References: <4F732FF1.3060908@oracle.com>
	<4F74291A.5020702@oracle.com>	<4F7438A7.2040904@oracle.com>
	<4F746383.2050204@oracle.com> <4F757534.3040802@oracle.com>
Message-ID: <4F7C1EA7.5070507@oracle.com>


webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.03/
test: http://cr.openjdk.java.net/~alexsch/7093156/test/02/

Now all properties are generated with the following suffixes: 
xxx.textAndMnemonic and xxx.titleAndMnemonic
- patterns which are generated to properties with the 
xxx.textAndMnemonic suffix:
   (xxxNameText, xxxNameMnemonic)
   (xxxNameText, xxxMnemonic)
   (xxx.nameText, xxx.mnemonic)
   (xxxText, xxxMnemonic)

- pattern which is generated to properties with the xxx.titleAndMnemonic 
suffix:
    (xxxTitle, xxxMnemonic)

After that the extended hashmap check a key suffix and generate a 
compositeKey which allows to get a property in a new format and extract 
a text, mnemonic or mnemonic index from it.

  The test gets a path to the old properties and L&F class. If L&F is 
not null than it is set. After that the test gets all properties and 
it's values and check that values are equal to the values which are got 
from the  UIManager.get(key, locale).

  There are some exceptions which are included into the exclude list in 
the end of the test.
  For example a mnemonic can be set to zero or to a character instead of 
using the character integer key value.
  Or there can be defined just mnemonics without a text.

Thanks,
Alexandr.

On 3/30/2012 12:56 PM, Alexander Scherbatiy wrote:
>
> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.01/
>
> There is the updated webrev  which is used the TextAndMnemonicPattern 
> class and separate getTextProperty and getMnemonicProperty methods. 
> The getMnemonicFromProperty returns null in case if a mnemonic has not 
> been found.
>
>  See other comments inline...
>
> On 3/29/2012 5:28 PM, Pavel Porvatov wrote:
>> I'll try explain what I meant below...
>>
>> Lets take the first loop:
>> +                for (int i = 0; i < TEXT_SUFFIX.length; i++) {
>> +                    String suffix = TEXT_SUFFIX[i];
>> +                    if (stringKey.endsWith(suffix)) {
>> +                        value = super.get(stringKey + AND_MNEMONIC);
>> +                        if (value != null) {
>> +                            return getText(value.toString());
>> +                        }
>> +                    }
>> +                }
>> and lets stringKey = BlaBlaBlaNameText. Then you'll invoke 
>> super.get() twice and the loop will have 4 iterations. So if you will 
>> use for the first loop only "Text", "Title" you will have only 2 loop 
>> iterations and no unnecessary super.get() invocations.
>
>   I have added the TextAndMnemonicPattern class and updated the code 
> to use the following patterns:
>   ( texts: { "NameText", "Text", "Title"} , mnemonic: "Mnemonic")
>   ( texts: { "nameText" } , mnemonic: "mnemonic")
>
>   Now the "for each" loop is used and for each mnemonic there is only 
> one iteration of the text.
>
>>
>> About "They are (xxxNameText, xxxMnemonic), (xxx.nameText, 
>> xxx.mnemonic),(xxxText, xxxMnemonic) and (xxxTitle, xxxMnemonic)": 
>> can we don't use "Name" for pair (xxxNameText, xxxMnemonic), like 
>> xxxTextAndMnemonic? For consistency we could  use for pair 
>> (xxx.nameText, xxx.mnemonic) xxx.textAndMnemonic...
>
>   1)   There are real collisions if we will use the same suffix like 
> xxx.textAndMnemonic for all properties. For example see the 
> gtk.properties:
>    FileChooser.renameFileErrorTitle=Error
>    FileChooser.renameFileErrorText=Error renaming file "{0}" to "{1}"
>
>   Changing it to the same suffix will lead to:
>      FileChooser.renameFileError.textAndMnemonic=Error
>      FileChooser.renameFileError.textAndMnemonic=Error renaming file 
> "{0}" to "{1}"
>
>    So one value will be lost.
>
>   2)  We really need to check all these text suffixes.
>
>     There are 3 examples from the swing property files:
>      ColorChooser.hsvNameText=HSV
>      ColorChooser.hsvMnemonic=72
>      FileChooser.helpButtonText=Help
>      FileChooser.helpButtonMnemonic=72
>      GTKColorChooserPanel.nameText=GTK Color Chooser
>      GTKColorChooserPanel.mnemonic=71
>
>     which are converted to the new format:
>     FileChooser.helpButtonTextAndMnemonic=&Help
>     ColorChooser.hsvNameTextAndMnemonic=&HSV
>     GTKColorChooserPanel.nameTextAndMnemonic=&GTK Color Chooser
>
>      Now on the left side there are requests and on the right side are 
> our actions:
>         ColorChooser.hsvNameText  |  check that it is request to the 
> text (has NameText suffix) and convert to new format 
> ColorChooser.hsvNameTextAndMnemonic (add AndMnemonic  suffix)
>         GTKColorChooserPanel.nameText | check that it is request to 
> the text (has nameText) and convert to new format 
> GTKColorChooserPanel.nameTextAndMnemonicadd AndMnemonic  suffix)
>         FileChooser.helpButtonMnemonic | check that it is a request to 
> the mnemonic (has Mnemonic  suffix) and convert to new format (remove 
> Mnemonic suffix and add TextAndMnemonic suffix)
>         GTKColorChooserPanel.mnemonic | check that it is a request to 
> the mnemonic (has mnemonic  suffix) and convert to new format (remove 
> mnemonic suffix and add nameTextAndMnemonic suffix)
>
>     The suffixes for the text can be Text and Title as well.
>     So the "NameText", "Text", "Title" and "nameText" suffixes are 
> already used in swing components and their unification requires to 
> updating a lot of java code.
>>
>>>
>>>>
>>>> 3. Could you pleas use "for each" loops (if possible), they are 
>>>> more compact and readable
>>>
>>>     In the second loop the i index is used to add a TEXT_SUFFIX 
>>> after cutting a MNEMONIC_SUFFIX.
>>>     So the first loop can use the "for each" loop.
>> Yep! That's what I meant...
>>>
>>>    May be it is better to have a TextAndMnemonic class that holds 
>>> values for the corresponded text and mnemonic suffixes?
>>>
>>>>
>>>> 4. Integer.toString((int) Character.toUpperCase(c)) looks a little 
>>>> bit tricky. Can we use something like this:
>>>> String.valueOf(Character.toUpperCase(c)) ?
>>>      For example  there is the property:
>>>        ColorChooser.rgbRedTextAndMnemonic=Re&d
>>>     The code that needs a mnemonic expect that it gets the integer 
>>> value |68| in the string instead of  char D.
>>>     So the right mnemonic value should be
>>>        ColorChooser.rgbRedMnemonic=68
>>>
>> Ok. BTW: I think "return null" will be more correct in the 
>> getMnemonic method
>
>     Updated the method to return null if a mnemonic has not been found.
>
>    Thanks,
>   Alexandr.
>
>>>>
>>>> 5. What is the reason to have the second loop? 
>>>      The first loop checks is it a request to a text value. The 
>>> second loop checks is it a request to a mnemonic value.
>>>
>>>> Can we just check
>>>> stringKey.endsWith("mnemonic") || stringKey.endsWith("Mnemonic")?
>>>      There might be collisions. It is better to explicitly check 
>>> that a text suffix from a pattern have the certain suffix from the 
>>> mnemonic pattern.
>>
>> Regards, Pavel
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>>
>>>> Regards, Pavel
>>>>
>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/
>>>>>
>>>>> The properties in the swing resources files are changed from the
>>>>>   xxxText=ABC
>>>>>   xxxMnemonic=B
>>>>> to
>>>>>   xxxTextAndMnemonic=A&BC
>>>>>
>>>>> where Text suffix can be one of the following: "NameText", 
>>>>> "nameText", "Text" and  "Title"
>>>>>
>>>>>
>>>>> The hashmap in UIDefaults class is extended to return the correct 
>>>>> values for the keys xxxText and xxxMnemonic from the stored 
>>>>> xxxTextAndMnemonic string.
>>>>>
>>>>> There is no html text in the swing resource files so this case is 
>>>>> not considered.
>>>>> The fix covers only the swing resource files in the JDK:
>>>>>   src/share/classes/com/sun/swing/internal/plaf
>>>>>   src/share/classes/com/sun/java/swing/plaf
>>>>>
>>>>> The demo resources will be fixed in the separated issue.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>
>>>
>>
>
>



From pavel.porvatov at oracle.com  Wed Apr  4 11:21:57 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 04 Apr 2012 15:21:57 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F7C1EA7.5070507@oracle.com>
References: <4F732FF1.3060908@oracle.com>
	<4F74291A.5020702@oracle.com>	<4F7438A7.2040904@oracle.com>
	<4F746383.2050204@oracle.com> <4F757534.3040802@oracle.com>
	<4F7C1EA7.5070507@oracle.com>
Message-ID: <4F7C2ED5.6060400@oracle.com>

Hi Alexander,

Looks great, I approve that! Could you please attach your test to CR 
7093156? And one minor notice: you should update javadoc of the 
TextAndMnemonicHashMap class. 
"FileChooser.saveButtonTextAndMnemonic=&Save" should be 
"FileChooser.saveButton.textAndMnemonic=&Save"

Regards, Pavel
>
> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.03/
> test: http://cr.openjdk.java.net/~alexsch/7093156/test/02/
>
> Now all properties are generated with the following suffixes: 
> xxx.textAndMnemonic and xxx.titleAndMnemonic
> - patterns which are generated to properties with the 
> xxx.textAndMnemonic suffix:
>   (xxxNameText, xxxNameMnemonic)
>   (xxxNameText, xxxMnemonic)
>   (xxx.nameText, xxx.mnemonic)
>   (xxxText, xxxMnemonic)
>
> - pattern which is generated to properties with the 
> xxx.titleAndMnemonic suffix:
>    (xxxTitle, xxxMnemonic)
>
> After that the extended hashmap check a key suffix and generate a 
> compositeKey which allows to get a property in a new format and 
> extract a text, mnemonic or mnemonic index from it.
>
>  The test gets a path to the old properties and L&F class. If L&F is 
> not null than it is set. After that the test gets all properties and 
> it's values and check that values are equal to the values which are 
> got from the  UIManager.get(key, locale).
>
>  There are some exceptions which are included into the exclude list in 
> the end of the test.
>  For example a mnemonic can be set to zero or to a character instead 
> of using the character integer key value.
>  Or there can be defined just mnemonics without a text.
>
> Thanks,
> Alexandr.
>
> On 3/30/2012 12:56 PM, Alexander Scherbatiy wrote:
>>
>> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.01/
>>
>> There is the updated webrev  which is used the TextAndMnemonicPattern 
>> class and separate getTextProperty and getMnemonicProperty methods. 
>> The getMnemonicFromProperty returns null in case if a mnemonic has 
>> not been found.
>>
>>  See other comments inline...
>>
>> On 3/29/2012 5:28 PM, Pavel Porvatov wrote:
>>> I'll try explain what I meant below...
>>>
>>> Lets take the first loop:
>>> +                for (int i = 0; i < TEXT_SUFFIX.length; i++) {
>>> +                    String suffix = TEXT_SUFFIX[i];
>>> +                    if (stringKey.endsWith(suffix)) {
>>> +                        value = super.get(stringKey + AND_MNEMONIC);
>>> +                        if (value != null) {
>>> +                            return getText(value.toString());
>>> +                        }
>>> +                    }
>>> +                }
>>> and lets stringKey = BlaBlaBlaNameText. Then you'll invoke 
>>> super.get() twice and the loop will have 4 iterations. So if you 
>>> will use for the first loop only "Text", "Title" you will have only 
>>> 2 loop iterations and no unnecessary super.get() invocations.
>>
>>   I have added the TextAndMnemonicPattern class and updated the code 
>> to use the following patterns:
>>   ( texts: { "NameText", "Text", "Title"} , mnemonic: "Mnemonic")
>>   ( texts: { "nameText" } , mnemonic: "mnemonic")
>>
>>   Now the "for each" loop is used and for each mnemonic there is only 
>> one iteration of the text.
>>
>>>
>>> About "They are (xxxNameText, xxxMnemonic), (xxx.nameText, 
>>> xxx.mnemonic),(xxxText, xxxMnemonic) and (xxxTitle, xxxMnemonic)": 
>>> can we don't use "Name" for pair (xxxNameText, xxxMnemonic), like 
>>> xxxTextAndMnemonic? For consistency we could  use for pair 
>>> (xxx.nameText, xxx.mnemonic) xxx.textAndMnemonic...
>>
>>   1)   There are real collisions if we will use the same suffix like 
>> xxx.textAndMnemonic for all properties. For example see the 
>> gtk.properties:
>>    FileChooser.renameFileErrorTitle=Error
>>    FileChooser.renameFileErrorText=Error renaming file "{0}" to "{1}"
>>
>>   Changing it to the same suffix will lead to:
>>      FileChooser.renameFileError.textAndMnemonic=Error
>>      FileChooser.renameFileError.textAndMnemonic=Error renaming file 
>> "{0}" to "{1}"
>>
>>    So one value will be lost.
>>
>>   2)  We really need to check all these text suffixes.
>>
>>     There are 3 examples from the swing property files:
>>      ColorChooser.hsvNameText=HSV
>>      ColorChooser.hsvMnemonic=72
>>      FileChooser.helpButtonText=Help
>>      FileChooser.helpButtonMnemonic=72
>>      GTKColorChooserPanel.nameText=GTK Color Chooser
>>      GTKColorChooserPanel.mnemonic=71
>>
>>     which are converted to the new format:
>>     FileChooser.helpButtonTextAndMnemonic=&Help
>>     ColorChooser.hsvNameTextAndMnemonic=&HSV
>>     GTKColorChooserPanel.nameTextAndMnemonic=&GTK Color Chooser
>>
>>      Now on the left side there are requests and on the right side 
>> are our actions:
>>         ColorChooser.hsvNameText  |  check that it is request to the 
>> text (has NameText suffix) and convert to new format 
>> ColorChooser.hsvNameTextAndMnemonic (add AndMnemonic  suffix)
>>         GTKColorChooserPanel.nameText | check that it is request to 
>> the text (has nameText) and convert to new format 
>> GTKColorChooserPanel.nameTextAndMnemonicadd AndMnemonic  suffix)
>>         FileChooser.helpButtonMnemonic | check that it is a request 
>> to the mnemonic (has Mnemonic  suffix) and convert to new format 
>> (remove Mnemonic suffix and add TextAndMnemonic suffix)
>>         GTKColorChooserPanel.mnemonic | check that it is a request to 
>> the mnemonic (has mnemonic  suffix) and convert to new format (remove 
>> mnemonic suffix and add nameTextAndMnemonic suffix)
>>
>>     The suffixes for the text can be Text and Title as well.
>>     So the "NameText", "Text", "Title" and "nameText" suffixes are 
>> already used in swing components and their unification requires to 
>> updating a lot of java code.
>>>
>>>>
>>>>>
>>>>> 3. Could you pleas use "for each" loops (if possible), they are 
>>>>> more compact and readable
>>>>
>>>>     In the second loop the i index is used to add a TEXT_SUFFIX 
>>>> after cutting a MNEMONIC_SUFFIX.
>>>>     So the first loop can use the "for each" loop.
>>> Yep! That's what I meant...
>>>>
>>>>    May be it is better to have a TextAndMnemonic class that holds 
>>>> values for the corresponded text and mnemonic suffixes?
>>>>
>>>>>
>>>>> 4. Integer.toString((int) Character.toUpperCase(c)) looks a little 
>>>>> bit tricky. Can we use something like this:
>>>>> String.valueOf(Character.toUpperCase(c)) ?
>>>>      For example  there is the property:
>>>>        ColorChooser.rgbRedTextAndMnemonic=Re&d
>>>>     The code that needs a mnemonic expect that it gets the integer 
>>>> value |68| in the string instead of  char D.
>>>>     So the right mnemonic value should be
>>>>        ColorChooser.rgbRedMnemonic=68
>>>>
>>> Ok. BTW: I think "return null" will be more correct in the 
>>> getMnemonic method
>>
>>     Updated the method to return null if a mnemonic has not been found.
>>
>>    Thanks,
>>   Alexandr.
>>
>>>>>
>>>>> 5. What is the reason to have the second loop? 
>>>>      The first loop checks is it a request to a text value. The 
>>>> second loop checks is it a request to a mnemonic value.
>>>>
>>>>> Can we just check
>>>>> stringKey.endsWith("mnemonic") || stringKey.endsWith("Mnemonic")?
>>>>      There might be collisions. It is better to explicitly check 
>>>> that a text suffix from a pattern have the certain suffix from the 
>>>> mnemonic pattern.
>>>
>>> Regards, Pavel
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/
>>>>>>
>>>>>> The properties in the swing resources files are changed from the
>>>>>>   xxxText=ABC
>>>>>>   xxxMnemonic=B
>>>>>> to
>>>>>>   xxxTextAndMnemonic=A&BC
>>>>>>
>>>>>> where Text suffix can be one of the following: "NameText", 
>>>>>> "nameText", "Text" and  "Title"
>>>>>>
>>>>>>
>>>>>> The hashmap in UIDefaults class is extended to return the correct 
>>>>>> values for the keys xxxText and xxxMnemonic from the stored 
>>>>>> xxxTextAndMnemonic string.
>>>>>>
>>>>>> There is no html text in the swing resource files so this case is 
>>>>>> not considered.
>>>>>> The fix covers only the swing resource files in the JDK:
>>>>>>   src/share/classes/com/sun/swing/internal/plaf
>>>>>>   src/share/classes/com/sun/java/swing/plaf
>>>>>>
>>>>>> The demo resources will be fixed in the separated issue.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>



From alexlamsl at gmail.com  Wed Apr  4 16:24:21 2012
From: alexlamsl at gmail.com (Alex Lam S.L.)
Date: Wed, 4 Apr 2012 17:24:21 +0100
Subject: <Swing Dev> JSeparator rendered incorrectly on Windows 7
In-Reply-To: <4F7C1389.4010102@oracle.com>
References: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>
	<4F757BE7.5040800@oracle.com>
	<CAGpACNuxFjUURWV0RwLcaWTWr+X3rrSTPU9cwCZBtRp09YojaA@mail.gmail.com>
	<CAGpACNt2SjeajBkp+vEqdUUG-_H7XHvsXozbmQF52TfLpDELLg@mail.gmail.com>
	<4F7C1389.4010102@oracle.com>
Message-ID: <CAGpACNujfM6GyZooTHUeWCgwMgXE4JeLiZZSRKanWysxuVyt+A@mail.gmail.com>

Hi there,

Thanks for the clarification.

To be honest, I will probably never have to touch that because I
always use a GUI builder, but it's always nice to learn something new.


Regards,
Alex.



On Wed, Apr 4, 2012 at 10:25 AM, Pavel Porvatov
<pavel.porvatov at oracle.com> wrote:
> Hi Alex,
>
>> Hi there,
>>
>> I have found the cause of the problem - the difference between
>> JSeparator and JPopupMenu.Separator.
>>
>> As I use the GUI builder on NetBeans, I don't know how or when it has
>> decided to slip in a single JSeparator into the mix.
>>
>> Attached a simple test case demonstrating the problem, at least on Win7.
>>
>> It's not a big deal to me now I've discovered the cause, although it
>> would be nice to know the difference between these two classes...
>
> There are three separators and they were designed for different purposes:
> 1. javax.swing.JSeparator (used for menus)
> 2. javax.swing.JPopupMenu.Separator (used for JPopupMenus)
> 3. javax.swing.JToolBar.Separator (used for JToolbars)
>
> To avoid any confusion use correspondent separators in appropriate places or
> use addSeparator() methods from JMenu, JPopupMenu, and JToolbar.
>
> Regards, Pavel
>
>>
>> Regards,
>> Alex.
>>
>>
>>
>>
>> On Sun, Apr 1, 2012 at 8:25 PM, Alex Lam S.L.<alexlamsl at gmail.com> ?wrote:
>>>
>>> Hi there,
>>>
>>> I will try and narrow it down to a simple(r) test case and get back to
>>> you.
>>>
>>>
>>> Regards,
>>> Alex.
>>>
>>>
>>>
>>> On Fri, Mar 30, 2012 at 10:24 AM, Pavel Porvatov
>>> <pavel.porvatov at oracle.com> ?wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Can you sent a small separated test? I used SwingSet2 demo with the same
>>>> Windows and jdk versions and the problem is not reproducible...
>>>>
>>>> Thanks, Pavel
>>>>
>>>>
>>>>> Hi there,
>>>>>
>>>>> I noticed that in some cases JSeparator would render differently (see
>>>>> attached photo - first one from the top, left window).
>>>>>
>>>>> It is repeatable - I can quit and re-run the app and the same
>>>>> JSeparator would be wrong. Curiously, I use the preview feature from
>>>>> NetBeans for the project code which generates this window, and the
>>>>> problem does not appear there.
>>>>>
>>>>>
>>>>> Confused,
>>>>> Alex.
>>>>>
>>>>> ---------------
>>>>>
>>>>> Microsoft Windows [Version 6.1.7601]
>>>>>
>>>>> java version "1.7.0_02"
>>>>> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
>>>>
>>>>
>


From pavel.porvatov at oracle.com  Thu Apr  5 15:59:33 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 05 Apr 2012 19:59:33 +0400
Subject: <Swing Dev> Review request for 7146146: Deadlock between subclass
 of AbstractDocument and UndoManager
Message-ID: <4F7DC165.2030003@oracle.com>

Hi,

This is a review request for CR 7146146

Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146146
Webrev: http://cr.openjdk.java.net/~rupashka/7146146/webrev.0/

Evaluation of the problem:
We should do any notifications outside of internal locks. The solution 
is to correct AbstractDocument#insertString method and move 
fireInsertUpdate and fireUndoableEditUpdate invocations from 
writeLock/writeUnlock block

Regards, Pavel


From luchsh at linux.vnet.ibm.com  Fri Apr  6 07:55:41 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 06 Apr 2012 15:55:41 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F7AE2BC.1080601@oracle.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com>
	<4F71D2AF.80307@oracle.com> <4F77C886.10507@linux.vnet.ibm.com>
	<4F7AE2BC.1080601@oracle.com>
Message-ID: <4F7EA17D.1000902@linux.vnet.ibm.com>

Hi Pavel

On 04/03/2012 07:45 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>
> I have several comments:
> 1. containerParent instanceof JComboBox && containerParent != null
> it is not necessary to check "containerParent != null" here
>

Yes, the null checking is not necessary here.

> 2.
> -            if (!interiorFocus && (state & SynthConstants.FOCUSED) != 
> 0) {
> +
>                  focusSize = style.getClassSpecificIntValue(context,
>                          "focus-line-width",1);
> +            if (!interiorFocus && (state & SynthConstants.FOCUSED) != 
> 0) {
> I don't see here any changes
>

There is indeed some changes, please refer to following link of raw text 
patch,
http://cr.openjdk.java.net/~luchsh/7154030_3/jdk.patch

The statement of retrieving focus-line-width property has been moved up.

> 3. Could you please explain the following changes?
> -            if (focusSize > 0) {
> +            if (focusSize > 0 && (state & SynthConstants.FOCUSED) != 
> 0) {
> +                if (interiorFocus) {
> +                    x += focusSize;
> +                    y += focusSize;
> +                    w -= 2 * focusSize;
> +                    h -= 2 * focusSize;
> +                } else {
>

I found the explanation of GTK geometry from following link
http://svn.gnome.org/viewvc/gtk%2B/trunk/docs/widget_geometry.txt?view=markup

And above piece of code is trying to render interior focus separately 
from exterior focus in the same way as 
GTKPainter.paintButtonBackgroundImpl(), (GTKPainter.java: 363).

>
> I applied the patch and observe that focused JComboBox looks strange 
> (see attachments):
> a. Native focus uses solid line
The patch only changed the size and position of focus rectangle not the 
style, so it is using the unchanged focus style.
> b. Native focused JComboBox paints focus rectangle across whole JComboBox
It depends on the GTK version and ComboBox's 'style'.

I made a simple native program for questions b.

/*
  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * version 2 for more details (a copy is included in the LICENSE file that
  * accompanied this code).
  *
  * You should have received a copy of the GNU General Public License version
  * 2 along with this work; if not, write to the Free Software Foundation,
  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  * or visit www.oracle.com if you need additional information or have any
  * questions.
  */

/*
  * Portions Copyright (c) 2012 IBM Corporation
  */

#include <gtk/gtk.h>

static gboolean delete_event(GtkWidget *widget, GdkEvent *event, 
gpointer data ) {
     return FALSE;
}

static void destroy(GtkWidget *widget, gpointer   data ) {
     gtk_main_quit ();
}

int main(int argc, char *argv[]) {
     GtkWidget *window;
     GtkWidget *comboText;
     GtkWidget *fixed;
     GtkWidget *button;
     GtkWidget *combo;
     GtkWidget *comboEntry;
     GList *glist = NULL;

     gtk_init (&argc, &argv);

     // init
     window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
     g_signal_connect (window, "delete-event", G_CALLBACK 
(delete_event), NULL);
     g_signal_connect (window, "destroy", G_CALLBACK (destroy), NULL);
     gtk_container_set_border_width (GTK_CONTAINER (window), 10);

     fixed = gtk_fixed_new();
     gtk_container_add (GTK_CONTAINER (window), fixed);

     //Button
     button = gtk_button_new_with_label("GTK button");

     // ComboBox using combo box text new()
     comboText = gtk_combo_box_text_new();
     gtk_combo_box_append_text(GTK_COMBO_BOX(comboText), "aaaaa");
     gtk_combo_box_append_text(GTK_COMBO_BOX(comboText), "GtkComboBoxText");
     gtk_combo_box_set_active(GTK_COMBO_BOX(comboText), TRUE);

     // ComboBox using deprecated combo
     combo = gtk_combo_new();
     glist = g_list_append (glist, "GtkCombo");
     glist = g_list_append (glist, "GTK");
     glist = g_list_append (glist, "theme");
     gtk_combo_set_popdown_strings (GTK_COMBO (combo), glist);

     // ComboBox using combo box entry new()
     GtkTreeIter iter;
     GtkTreeModel *list_store = gtk_list_store_new(1, G_TYPE_STRING);
     gtk_list_store_clear(list_store);
     gtk_list_store_append(GTK_LIST_STORE(list_store), &iter);
     gtk_list_store_set(GTK_LIST_STORE(list_store), &iter, 
G_TYPE_STRING, "123", -1);
     comboEntry = gtk_combo_box_entry_new_with_model(list_store, 0);
     gtk_combo_box_set_active(GTK_COMBO_BOX(comboEntry), TRUE);

     // pack & show
     gtk_fixed_put(GTK_FIXED(fixed), button, 0, 0);
     gtk_fixed_put(GTK_FIXED(fixed), comboText, 0, 30);
     gtk_fixed_put(GTK_FIXED(fixed), comboEntry, 0, 60);
     gtk_fixed_put(GTK_FIXED(fixed), combo, 0, 90);

     gtk_widget_show(button);
     gtk_widget_show(comboText);
     gtk_widget_show(combo);
     gtk_widget_show(comboEntry);

     gtk_widget_show (fixed);
     gtk_widget_show (window);
     gtk_main ();

     // clean up
     g_list_free(glist);

     return 0;
}

Compile above code using following command and run the binary,
gcc -Wall comboboxtest.c -o comboboxtest `pkg-config --cflags gtk+-2.0` 
`pkg-config --libs gtk+-2.0`

So far as I see from the docs and above demo, there're several ways for 
native GTK application to create a ComboBox component,
1), gtk_combo_box_text_new() way will draw focus rectangle accross the 
whole ComboBox component;
2), gtk_combo_box_entry_new_with_model() way will have two focus points 
and draw the rectangle for each of them.
3), gtk_combo_new() way will draw focus rectangle on the text area only 
not on the whole ComboBox.

I think current swing's ComboBox is trying to follow condition 3), 
right? if so, the focus size problem may not be a inconsistency problem, 
does that make sense?

> Regards, Pavel
>> Hi Pavel,
>>
>> Here's the updated patch, including proposed solution for interior 
>> focus.
>> http://cr.openjdk.java.net/~luchsh/7155887_3/
>>
>> In the orginal code as I understood, focus is only paint when 
>> !interiorFocus, in which case the background shadow and flatBox will 
>> shrink a bit to corperate with the outer focus whose size is same as 
>> the original component. My proposed solution is to shirink focus line 
>> for interior focus, but keep the same way of !interorFocus.
>>
>> could you pls take a look?
>>
>> On 03/27/2012 10:46 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>
>>> What do you think about another solution: can we set component state 
>>> as SynthConstants.FOCUSED before paintTextBackground is invoked. 
>>> Another solution is to set state as "focused" for ComboBox renderer 
>>> like the following:
>>>
>>>         if ("ComboBox.renderer".equals(c.getName())) {
>>>             for (Component comboBoxParent = c.getParent(); 
>>> comboBoxParent != null; comboBoxParent = comboBoxParent.getParent()) {
>>>                 if (comboBoxParent instanceof JComboBox){
>>>                     if(comboBoxParent.hasFocus()){
>>>                         state |= SynthConstants.FOCUSED;
>>>                     }
>>>                     break;
>>>                 }
>>>             }
>>>         }
>>> without other changes in GTKPainter.java (actually there is some 
>>> problem with "interiorFocus", but it could be resolved....)
>>>
>>> See also my answers below.
>>>> Hi Pavel,
>>>>
>>>> Thanks for review, here's the new patch and my answers are inlined.
>>>> http://cr.openjdk.java.net/~luchsh/7155887_2/
>>>>
>>>> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>> Hi Swing-dev,
>>>>>>
>>>>>> ComboBox on linux GTK L&F does not works as gtk native 
>>>>>> applications, when get focused, the apperance of Java ComboBox 
>>>>>> remains unchanged but native GTK ComboBox control will have a 
>>>>>> outline to indicate it has got focused.
>>>>>>
>>>>>> The problem seems similar to bug
>>>>>> 6947671 ( 
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>>>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>>>>> another bug
>>>>>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>>>>> was created for this issue,
>>>>>>
>>>>>> And here's the proposed patch to fix this problem,
>>>>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>>>>
>>>>>> Could anybody please help to take a look?
>>>>> I have several comments about the patch:
>>>>>
>>>>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get 
>>>>> NPE here
>>>> Yes, I've changed it to
>>>>
>>>> "ComboBox.renderer".equals(c.getName())
>>>>
>>>>>
>>>>> 2.
>>>>> +            for (Component comboBoxParent = c.getParent(); 
>>>>> comboBoxParent != null; comboBoxParent = comboBoxParent
>>>>> +                    .getParent()) {
>>>>> +                if (comboBoxParent instanceof JComboBox
>>>>> + && comboBoxParent.hasFocus()) {
>>>>> +                    comboBoxFocused = true;
>>>>> +                }
>>>>> +            }
>>>>>
>>>>> I'm not sure we should do such deep parent investigation. Why 
>>>>> don't you check first parent only?
>>>>>
>>>> javax.swing.CellRendererPane is inserted between the component and 
>>>> renderer, so if check only the first parent, it will retrieve a 
>>>> CellRendererPane object instead of JComboBox component. In the new 
>>>> patch, I added a break when JComboBox is encounterred so to make 
>>>> the effect similar to the first-parent-only approach.
>>> I found out the following code (see 
>>> com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
>>>         if (c instanceof ListCellRenderer &&
>>>                  container != null &&
>>>                  container.getParent() instanceof JComboBox ) {
>>>             ...
>>>         }
>>> I think we should use the same pattern
>>>>
>>>>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>>>>> !comboBoxFocused)"
>>>>> If you are going to ignore ENGINE.paintCachedImage when 
>>>>> comboBoxFocused, then there is no need to invoke it at all
>>>>>
>>>> yes, in the new patch I've changed the order of these two checks.
>>>>> 4. "if (comboBoxFocused || focusSize > 0)"
>>>>> I'm not sure we should paint focus if focusSize == 0
>>>>>
>>>> I think there's no need to paint the focus if focusSize ==0, since 
>>>> the focus width and height arguements passed to JNI method 
>>>> native_paint_focus() will both be zero.
>>> That's what I meant! (may be my phrase was not clear enough)
>>> Your condition "if (comboBoxFocused || focusSize > 0)" allows to 
>>> paint focus even if focusSize == 0...
>>>
>> Oh, sorry for my misunderstanding, the previous patch indeed got such 
>> a problem, but it may not be in the new patch.
>>> Regards, Pavel
>>
>> Thanks and best regards!
>>
>> - Jonathan
>>
>

Thanks and best regards!

- Jonathan



From luchsh at linux.vnet.ibm.com  Fri Apr  6 09:21:58 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 06 Apr 2012 17:21:58 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F71E3B9.9090103@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com>
Message-ID: <4F7EB5B6.6090009@linux.vnet.ibm.com>

Hi Pavel,

Here's the update patch,
http://cr.openjdk.java.net/~luchsh/7154030_4/

My comments are inlined.

On 03/27/2012 11:58 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hello Pavel,
>>
>> Here's the updated patch and automatic test for bug 7154030, could 
>> you please take another look?
>> http://cr.openjdk.java.net/~luchsh/7154030_2/
> I have several comments:
>
> 1. What about the following comment from Artem:
> "Even if we accept the change in JComponent.hide(), we should then 
> override show() as well (lightweight component may be non-opaque, so 
> we should repaint from its parent)"
> ?
>
I've updated my test case by including non-opaque components, but I do 
no see a need for overriding show(), is there anything incorrect with 
the updated testcase or my understanding?

> 2. Could you please clarify your changes in setVisible method?
> As I see in comments
>             // Some (all should) LayoutManagers do not consider components
>             // that are not visible. As such we need to revalidate 
> when the
>             // visible bit changes.
>             revalidate();
> but now this code is invoked only for setVisible(true)
>
For the setVisible(false) case, the repainting and revalidating 
operations will be done in new method JComponent.hide(), so this change 
is just to reduce some duplicated actions.

> 3. Could you please follow our code conventions?  (see 
> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>
Sorry for this problem, I was trying to keeping aligned with the 
original style of JComponent.java, which I later realized to be 
inappropriate. In the updated patch, code has been well formatted.

> 4. Your test is not automatic one. I think you could use 
> java.awt.Robot#createScreenCapture and analyze result of hide method.

See the link, it should be automatic now.

>
> Regards, Pavel
>>
>> Thanks and best regards
>> - Jonathan Lu
>>
>> On 03/26/2012 09:38 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> Thanks for your explanation.
>>>>
>>>> But this bug affects almost all Swing components, hide()'s presence 
>>>> also helps to maintain backward compatibility, so is it possible to 
>>>> put a fix in JComponent to help all the potential affected 
>>>> applications to work correctly? 
>>> Of course that's possible. Do you have final version of the fix? 
>>> Please don't forget write an automatic test.
>>>> if not, is it there any sunset plan for these deprecated APIs?
>>> I don't now such plans.
>>>
>>> Regards, Pavel
>>>
>>> P.S. I removed <AWT Dev>, it seems only Swing will be affected in 
>>> this fix
>>>> Thanks and best regards!
>>>>
>>>> - Jonathan
>>>>
>>>> 2012/3/20 Pavel Porvatov <pavel.porvatov at oracle.com 
>>>> <mailto:pavel.porvatov at oracle.com>>
>>>>
>>>>     Hi Jonathan,
>>>>>     Hi Artem,
>>>>>
>>>>>     2012/3/20 Artem Ananiev <artem.ananiev at oracle.com
>>>>>     <mailto:artem.ananiev at oracle.com>>
>>>>>
>>>>>         Hi, Jonathan,
>>>>>
>>>>>         I'm adding swing-dev to CC as we now consider changing
>>>>>         Swing code.
>>>>>
>>>>>         What you propose sounds technically reasonable, but I
>>>>>         don't think it is worth doing anyway as show() and hide()
>>>>>         have been deprecated for years now.
>>>>>
>>>>>
>>>>>     Although show() and hide() have been deprecated for years, in
>>>>>     my opinion supporting these APIs will still benefit many
>>>>>     applications and convince users that Java still has got strong
>>>>>     backward compatibility :D. Any ideas from Swing group?
>>>>     I don't see why the words "backward compatibility" are here.
>>>>     There is a bug in deprecated methods "show" and "hide" (I've
>>>>     checked that jdk5 has the same problem), and that's one
>>>>     additional reason to use setVisible(). I agree with Artem that
>>>>     fixing deprecated API is not a high priority task (but we
>>>>     should keep backward compatibility, of course). I also think,
>>>>     that "to leave all as is" is a good decision for the described
>>>>     problem
>>>>
>>>>     Regards, Pavel
>>>>
>>>>>
>>>>>
>>>>>         Even if we accept the change in JComponent.hide(), we
>>>>>         should then override show() as well (lightweight component
>>>>>         may be non-opaque, so we should repaint from its parent),
>>>>>         so there will be code duplication. This is one more reason
>>>>>         to leave all as is.
>>>>>
>>>>>
>>>>>     Yes, I noticed that code duplication too and am trying to make
>>>>>     a more compact patch for this problem.
>>>>>
>>>>>         This is my personal opinion, I'm not a Swing expert,
>>>>>         though. Let anyone from the Swing group comment.
>>>>>
>>>>>         Thanks,
>>>>>
>>>>>         Artem
>>>>>
>>>>>         On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>>>>>
>>>>>             Hi Artem,
>>>>>
>>>>>             Thanks for your time.
>>>>>
>>>>>             2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>>>>>             <mailto:artem.ananiev at oracle.com>
>>>>>             <mailto:artem.ananiev at oracle.com
>>>>>             <mailto:artem.ananiev at oracle.com>>>
>>>>>
>>>>>                Hi, Jonathan,
>>>>>
>>>>>                given the code in java.awt.Component, your
>>>>>             statement about
>>>>>                difference between hide() and setVisible(false)
>>>>>             looks pretty strange
>>>>>                to me. Indeed, here is the implementation:
>>>>>
>>>>>
>>>>>
>>>>>                    public void show(boolean b) {
>>>>>                        if (b) {
>>>>>                            show();
>>>>>                        } else {
>>>>>                            hide();
>>>>>                        }
>>>>>                    }
>>>>>
>>>>>                and
>>>>>
>>>>>                    public void setVisible(boolean b) {
>>>>>                        show(b);
>>>>>                    }
>>>>>
>>>>>                In JComponent the latter method is overridden and
>>>>>             adds exactly what
>>>>>                you propose: parent.repaint(). This addition makes
>>>>>             sense for
>>>>>                lightweight components (e.g. Swing), but
>>>>>             heavyweight AWT components
>>>>>                shouldn't require this: repaint request is sent
>>>>>             from the native system.
>>>>>
>>>>>
>>>>>             Yes, lightweight and  heavyweight components differ in
>>>>>             painting. The
>>>>>             original test case only works for the conditions of
>>>>>             lightweight
>>>>>             components, with another test case for heavyweight
>>>>>             components, I found
>>>>>             that the problem could not be reproduced on AWT any
>>>>>             more. I think the
>>>>>             change is only applicable for Swing components, so how
>>>>>             about repaint in
>>>>>             JComponent.hide() like this?
>>>>>
>>>>>             diff -r cdbb33303ea3
>>>>>             src/share/classes/javax/swing/JComponent.java
>>>>>             --- a/src/share/classes/javax/swing/JComponent.java  
>>>>>              Wed Mar 14
>>>>>             13:50:37 2012 -0700 <tel:2012%20-0700> <tel:2012%20-0700>
>>>>>             +++ b/src/share/classes/javax/swing/JComponent.java  
>>>>>              Tue Mar 20
>>>>>             16:24:09 2012 +0800
>>>>>             @@ -5237,6 +5237,16 @@
>>>>>                      }
>>>>>                  }
>>>>>
>>>>>             +    public void hide() {
>>>>>             +        super.hide();
>>>>>             +        Container parent = getParent();
>>>>>             +        if (parent != null) {
>>>>>             +            Rectangle r = getBounds();
>>>>>             +            parent.repaint(r.x, r.y, r.width, r.height);
>>>>>             +            parent.invalidate();
>>>>>             +        }
>>>>>             +    }
>>>>>             +
>>>>>                  /**
>>>>>                   * Returns whether or not the region of the
>>>>>             specified component is
>>>>>                   * obscured by a sibling.
>>>>>
>>>>>
>>>>>
>>>>>                Thanks,
>>>>>
>>>>>                Artem
>>>>>
>>>>>
>>>>>                On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>>>>>
>>>>>                    Hi awt-dev,
>>>>>
>>>>>                    java.awt.Component.hide() was declared as
>>>>>             deprecation and
>>>>>                    replaced by
>>>>>                    setVisible(boolean), but in my tests, it does
>>>>>             not works in the
>>>>>                    same way
>>>>>                    as setVisible(false). The reason of this
>>>>>             failure is that
>>>>>                    java.awt.Component.hide() does not repaint the
>>>>>             special area it
>>>>>                    used to
>>>>>                    taken of parent container. Although this is
>>>>>             deprecated method,
>>>>>                    it may
>>>>>                    still valuable for customers due to
>>>>>             compatibility reason. Bug
>>>>>                    7154030
>>>>>                    created for this issue.
>>>>>
>>>>>                    Here's a simple test case to demonstrate this
>>>>>             problem.
>>>>>
>>>>>                    /*
>>>>>                      * Copyright (c) 2012 Oracle and/or its
>>>>>             affiliates. All rights
>>>>>                    reserved.
>>>>>                      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR
>>>>>             THIS FILE HEADER.
>>>>>                      *
>>>>>                      * This code is free software; you can
>>>>>             redistribute it and/or
>>>>>                    modify it
>>>>>                      * under the terms of the GNU General Public
>>>>>             License version 2
>>>>>                    only, as
>>>>>                      * published by the Free Software Foundation.
>>>>>                      *
>>>>>                      * This code is distributed in the hope that
>>>>>             it will be useful, but
>>>>>                    WITHOUT
>>>>>                      * ANY WARRANTY; without even the implied
>>>>>             warranty of
>>>>>                    MERCHANTABILITY or
>>>>>                      * FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>>>             GNU General
>>>>>                    Public License
>>>>>                      * version 2 for more details (a copy is
>>>>>             included in the
>>>>>                    LICENSE file that
>>>>>                      * accompanied this code).
>>>>>                      *
>>>>>                      * You should have received a copy of the GNU
>>>>>             General Public
>>>>>                    License
>>>>>                    version
>>>>>                      * 2 along with this work; if not, write to
>>>>>             the Free Software
>>>>>                    Foundation,
>>>>>                      * Inc., 51 Franklin St, Fifth Floor, Boston,
>>>>>             MA 02110-1301 USA.
>>>>>                      *
>>>>>                      * Please contact Oracle, 500 Oracle Parkway,
>>>>>             Redwood Shores,
>>>>>                    CA 94065 USA
>>>>>                      * or visit www.oracle.com
>>>>>             <http://www.oracle.com> <http://www.oracle.com> if you
>>>>>             need
>>>>>                    additional information or have any
>>>>>                      * questions.
>>>>>                      */
>>>>>
>>>>>                    /*
>>>>>                      * Portions Copyright (c) 2012 IBM Corporation
>>>>>                      */
>>>>>
>>>>>                    import javax.swing.*;
>>>>>
>>>>>                    /* @test 1.1 2012/03/15
>>>>>                        @bug 7154030
>>>>>                        @run main/manual ComponentHideShowTest.html */
>>>>>
>>>>>                    @SuppressWarnings("serial")
>>>>>                    public class ComponetHideShowTest extends JFrame {
>>>>>                         JInternalFrame internalFrame;
>>>>>                         JButton btn;
>>>>>                         JDesktopPane desktop;
>>>>>
>>>>>                         ComponetHideShowTest(String name) {
>>>>>                             super(name);
>>>>>                             desktop = new JDesktopPane();
>>>>>                             setContentPane(desktop);
>>>>>
>>>>>                             setSize(600, 400);
>>>>>                             setVisible(true);
>>>>>
>>>>>                             internalFrame = new
>>>>>             JInternalFrame("Test Internal Frame");
>>>>>                             internalFrame.setSize(100, 100);
>>>>>                             internalFrame.setLocation(10, 10);
>>>>>                             internalFrame.setVisible(true)__;
>>>>>                             desktop.add(internalFrame);
>>>>>
>>>>>                             btn = new JButton("OK");
>>>>>                             btn.setSize(100, 50);
>>>>>                             btn.setLocation( 300, 300);
>>>>>                             btn.setVisible(true);
>>>>>                             desktop.add(btn);
>>>>>
>>>>>                            
>>>>>             setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>>>>>                         }
>>>>>
>>>>>                         @SuppressWarnings("__deprecation")
>>>>>                         public void runTest() throws Exception {
>>>>>                             Object[] options = { "Yes, I saw it",
>>>>>             "No, I did not
>>>>>                    see it!" };
>>>>>
>>>>>                             int ret =
>>>>>             JOptionPane.showOptionDialog(__this,
>>>>>                    "Do you see the internal window?",
>>>>>             "InternalFrmaeHideTest",
>>>>>                                     JOptionPane.YES_NO_OPTION,
>>>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>>>                                     options, options[1]);
>>>>>
>>>>>                             if (ret == 1 || ret ==
>>>>>             JOptionPane.CLOSED_OPTION) {
>>>>>                                 throw new Exception("Failed to
>>>>>             display internal
>>>>>                    window");
>>>>>                             }
>>>>>
>>>>>                             internalFrame.hide();
>>>>>                             btn.hide();
>>>>>
>>>>>                             ret = JOptionPane.showOptionDialog(__this,
>>>>>                    "Do you see the internal window?",
>>>>>             "InternalFrmaeHideTest",
>>>>>                                     JOptionPane.YES_NO_OPTION,
>>>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>>>                                     options, options[1]);
>>>>>
>>>>>                             if (ret == 0 || ret ==
>>>>>             JOptionPane.CLOSED_OPTION) {
>>>>>                                 throw new Exception("Failed to
>>>>>             hide internal window");
>>>>>                             }
>>>>>
>>>>>                             internalFrame.show();
>>>>>                             btn.show();
>>>>>
>>>>>                             ret = JOptionPane.showOptionDialog(__this,
>>>>>                    "Do you see the internal window?",
>>>>>             "InternalFrmaeHideTest",
>>>>>                                     JOptionPane.YES_NO_OPTION,
>>>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>>>                                     options, options[1]);
>>>>>
>>>>>                             if (ret == 1 || ret ==
>>>>>             JOptionPane.CLOSED_OPTION) {
>>>>>                                 throw new Exception("Failed to
>>>>>             hide internal window");
>>>>>                             }
>>>>>                         }
>>>>>
>>>>>                         public static void main(String[] args)
>>>>>             throws Exception {
>>>>>                             ComponetHideShowTest test = null;
>>>>>                             test = new
>>>>>             ComponetHideShowTest("__InternalFrameHideTest");
>>>>>                             test.runTest();
>>>>>                         }
>>>>>                    }
>>>>>
>>>>>                    And here's the patch
>>>>>             http://cr.openjdk.java.net/~__littlee/7154030/
>>>>>             <http://cr.openjdk.java.net/%7E__littlee/7154030/>
>>>>>             <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>>>>>
>>>>>                    Can anybody please help to take a look?
>>>>>
>>>>>                    Cheers!
>>>>>                    - Jonathan
>>>>>
>>>>>
>>>>>             Best regards!
>>>>>             - Jonathan
>>>>>
>>>>>
>>>>>     Thanks a lot !
>>>>>
>>>>>     - Jonathan
>>>>
>>>>
>>>
>>
>


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

From artem.ananiev at oracle.com  Fri Apr  6 10:19:18 2012
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 06 Apr 2012 14:19:18 +0400
Subject: <Swing Dev> Review request for 7146146: Deadlock between
 subclass of AbstractDocument and UndoManager
In-Reply-To: <4F7DC165.2030003@oracle.com>
References: <4F7DC165.2030003@oracle.com>
Message-ID: <4F7EC326.4050607@oracle.com>

Hi, Pavel,

the fix looks fine, except code formatting: some of the added/changed 
lines are too long, which makes the code less readable.

Thanks,

Artem

On 4/5/2012 7:59 PM, Pavel Porvatov wrote:
> Hi,
>
> This is a review request for CR 7146146
>
> Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146146
> Webrev: http://cr.openjdk.java.net/~rupashka/7146146/webrev.0/
>
> Evaluation of the problem:
> We should do any notifications outside of internal locks. The solution
> is to correct AbstractDocument#insertString method and move
> fireInsertUpdate and fireUndoableEditUpdate invocations from
> writeLock/writeUnlock block
>
> Regards, Pavel


From zhouyx at linux.vnet.ibm.com  Wed Apr 11 07:39:27 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 11 Apr 2012 15:39:27 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F61E737.7010201@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
Message-ID: <CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>

Hi Pavel,

    As awt team has committed the related bug(
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I prepared the
webrev for this
bug(7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>)
again.

    The new webrev: http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/  .

The sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
Previous discussion:
http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html

    Please take a look once more, thank you.

On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
>
>  Hi Pavel,
>
>     Thanks for your comments.
>
>  About the 1st question, I modified the testcase a little to demonstrate
> the problem, testcase is pasted at the end.
>
>  If textArea.setEditable(true) is executed, the frame disposes, but
> application doesn't exit.
> If textArea.setEditable(false), the application exits as normal.
>
>  java 1.7.0_01 and latest java8 code are tested.  And TextField contains
> this problem as well. I'll add it to fix later.
> Shall I report a separate bug for it ?
>
> Yes. I think it will be better if you fix the described above problem as a
> separate bug. Note that it should be reviewed by the AWT team...
>
>
>
>  About the 2nd question, I was driven by the comment "// TODO : fix this
> duplicate code". Is there any strong reason to keep it ?
>
> I'm absolutely agree with removing duplicate code. My second question was
> about added by you "jtext.getCaret().setVisible(false)" in the
> XTextAreaPeer.java class. I wrote:
> 2. Why don't we need the same code in the XTextFieldPeer class?
>
> As I can see you've noticed that XTextFieldPeer should be fixed as well
> (in a separate fix with XTextAreaPeer)
>
> Regards, Pavel
>
>
>
>  ///////////////////////////////////  a testcase
>  ////////////////////////////////////////////////////////////
>  /*
>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>   * You should have received a copy of the GNU General Public License
> version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>   * questions.
>  */
>
>  /*
>  * Portions Copyright (c) 2012 IBM Corporation
>  */
>
>  /* @test
>  * @bug
>  * @summary editable TextArea blocks gui app from dispose.
>  * @author Sean Chou
>  */
>
>  import java.awt.FlowLayout;
> import java.awt.Frame;
> import java.awt.TextArea;
> import java.awt.Toolkit;
> import java.lang.reflect.Field;
>
>  import javax.swing.JFrame;
> import javax.swing.JTextArea;
> import javax.swing.SwingUtilities;
> import javax.swing.text.DefaultCaret;
>
>  import sun.awt.SunToolkit;
>
>  public class TextAreaDisposeBug {
>     public static volatile boolean passed = false;
>
>      public static Frame frame = null;
>     public static TextArea textArea = null;
>
>      public static DefaultCaret caret = null;
>     public static Class XTextAreaPeerClzz = null;
>
>      public static void main(String[] args) throws Exception {
>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame = new JFrame("Test");
>
>                 textArea = new TextArea("editable textArea");
>                 textArea.setEditable(true);
> //                textArea.setEditable(false);
>
>                  frame.setLayout(new FlowLayout());
>                 frame.add(textArea);
>
>                  frame.pack();
>                 frame.setVisible(true);
>
>             }
>         });
>         toolkit.realSync();
>
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame.dispose();
>             }
>         });
>         toolkit.realSync();
>     }
>
>  }
>
>
>
> //////////////////////////////////////////////////////////////////////////////////////////
>  /*
>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>   * You should have received a copy of the GNU General Public License
> version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>   * questions.
>  */
>
>  /*
>  * Portions Copyright (c) 2012 IBM Corporation
>  */
>
>
>  /* @test
>  * @bug
>  * @summary editable TextField blocks gui app from dispose.
>  * @author Sean Chou
>  */
>
>  import java.awt.FlowLayout;
> import java.awt.Frame;
> import java.awt.TextField;
> import java.awt.Toolkit;
> import java.lang.reflect.Field;
>
>  import javax.swing.JFrame;
> import javax.swing.JTextArea;
> import javax.swing.SwingUtilities;
> import javax.swing.text.DefaultCaret;
>
>  import sun.awt.SunToolkit;
>
>  public class TextFieldDisposeBug {
>     public static volatile boolean passed = false;
>
>      public static Frame frame = null;
>     public static TextField textField = null;
>
>      public static DefaultCaret caret = null;
>     public static Class XTextAreaPeerClzz = null;
>
>      public static void main(String[] args) throws Exception {
>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame = new JFrame("Test");
>
>                 textField = new TextField("editable textArea");
> //                textField.setEditable(true);
>                 textField.setEditable(false);
>
>                  frame.setLayout(new FlowLayout());
>                 frame.add(textField);
>
>                  frame.pack();
>                 frame.setVisible(true);
>
>             }
>         });
>         toolkit.realSync();
>
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame.dispose();
>             }
>         });
>         toolkit.realSync();
>     }
>
>  }
>
>
>  On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov <
> pavel.porvatov at oracle.com> wrote:
>
>>  Hi Sean,
>>
>> I have a couple questions about the following code in the
>> XTextAreaPeer.java class
>> +        // visible caret has a timer thread, which must be stopped
>> +        jtext.getCaret().setVisible(false);
>>
>> 1. Why this code wasn't needed before your fix, when caret was visible
>> for enabled text area?
>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>
>> About the bug7129742 test:
>> Because of the passed field is used from different threads you must use
>> synchronization or mark the field as a volatile.
>>
>> Regards, Pavel
>>
>>
>> Hi Alexander,
>>
>>      XTextFieldPeer and   XTextAreaPeer have a same inner
>> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
>> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
>> the XAWTCaret in XTextFieldPeer and changed the
>> XAWTCaret  into a static class, so XTextFieldPeer can
>> use XAWTCaret from XTextAreaPeer  .
>>
>>      As XAWTCaret is only used in the following
>> method  in both XTextAreaPeer and  XTextFieldPeer .
>> protected Caret createCaret() {
>>  return new XAWTCaret();
>>  }
>>      I think this modification should not bring side effect.
>>
>>  On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
>> Alexander.Potochkin at oracle.com> wrote:
>>
>>> Hello Sean
>>>
>>> Could you give more details about your changes in XTextFieldPeer?
>>>
>>> Thanks
>>> alexp
>>>
>>>  Hi all,
>>>>
>>>>   I updated the patch to as suggested and simplified the testcase .
>>>> Would anyone like to take a look again ? Thanks.
>>>>
>>>>   The webrev is at :
>>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <
>>>> http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>
>>>>
>>>>  Previous discussion at :
>>>>
>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>
>>>> --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>
>>
>>
>>  --
>> 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/20120411/19a7c0fb/attachment.html>

From pavel.porvatov at oracle.com  Wed Apr 11 13:40:42 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 11 Apr 2012 17:40:42 +0400
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F7EB5B6.6090009@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
Message-ID: <4F8589DA.5000600@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> Here's the update patch,
> http://cr.openjdk.java.net/~luchsh/7154030_4/
>
Could you please explain one change in the JComponent.java:

+    public void hide() {
+        if (isVisible()) {
+            super.hide();

I think super.hide() should be invoked always. You must also add a 
javadoc to the new hide method (see {@inheritDoc} for details)

See also my comments below

> My comments are inlined.
>
> On 03/27/2012 11:58 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hello Pavel,
>>>
>>> Here's the updated patch and automatic test for bug 7154030, could 
>>> you please take another look?
>>> http://cr.openjdk.java.net/~luchsh/7154030_2/
>> I have several comments:
>>
>> 1. What about the following comment from Artem:
>> "Even if we accept the change in JComponent.hide(), we should then 
>> override show() as well (lightweight component may be non-opaque, so 
>> we should repaint from its parent)"
>> ?
>>
> I've updated my test case by including non-opaque components, but I do 
> no see a need for overriding show(), is there anything incorrect with 
> the updated testcase or my understanding?
>
>> 2. Could you please clarify your changes in setVisible method?
>> As I see in comments
>>             // Some (all should) LayoutManagers do not consider 
>> components
>>             // that are not visible. As such we need to revalidate 
>> when the
>>             // visible bit changes.
>>             revalidate();
>> but now this code is invoked only for setVisible(true)
>>
> For the setVisible(false) case, the repainting and revalidating 
> operations will be done in new method JComponent.hide(), so this 
> change is just to reduce some duplicated actions.
Ok
>
>> 3. Could you please follow our code conventions?  (see 
>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>
> Sorry for this problem, I was trying to keeping aligned with the 
> original style of JComponent.java, which I later realized to be 
> inappropriate. In the updated patch, code has been well formatted.
>
>> 4. Your test is not automatic one. I think you could use 
>> java.awt.Robot#createScreenCapture and analyze result of hide method.
>
> See the link, it should be automatic now.
The test should be corrected:
1. All Swing components must be accessed from the EDT thread
2. What is the reason to introduce the MyButton class? I think the test 
can be simplified, if you will use the Util#compareBufferedImages (see 
test\javax\swing\regtesthelpers\Util.java) method. Just take 
screen-shots between show/hide and compare them
3. Thread.sleep(milisecond) should be replaced by the 
SunToolkit#realSync method (many existing tests uses it)

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120411/77b1c774/attachment.html>

From luchsh at linux.vnet.ibm.com  Thu Apr 12 11:14:53 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 12 Apr 2012 19:14:53 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F8589DA.5000600@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com>
Message-ID: <4F86B92D.9080900@linux.vnet.ibm.com>

Hi Pavel,

Here's another updated patch.
http://cr.openjdk.java.net/~luchsh/7154030_5/

My comments are inlined.

On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Pavel,
>>
>> Here's the update patch,
>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>
> Could you please explain one change in the JComponent.java:
>
> +    public void hide() {
> +        if (isVisible()) {
> +            super.hide();
>
> I think super.hide() should be invoked always. You must also add a 
> javadoc to the new hide method (see {@inheritDoc} for details)

Yes, the old patch may cause Component.isPacked not to be set correctly, 
so moved super.hide() up.

>
> See also my comments below
>
>> My comments are inlined.
>>
>> On 03/27/2012 11:58 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hello Pavel,
>>>>
>>>> Here's the updated patch and automatic test for bug 7154030, could 
>>>> you please take another look?
>>>> http://cr.openjdk.java.net/~luchsh/7154030_2/
>>> I have several comments:
>>>
>>> 1. What about the following comment from Artem:
>>> "Even if we accept the change in JComponent.hide(), we should then 
>>> override show() as well (lightweight component may be non-opaque, so 
>>> we should repaint from its parent)"
>>> ?
>>>
>> I've updated my test case by including non-opaque components, but I 
>> do no see a need for overriding show(), is there anything incorrect 
>> with the updated testcase or my understanding?
>>
>>> 2. Could you please clarify your changes in setVisible method?
>>> As I see in comments
>>>             // Some (all should) LayoutManagers do not consider 
>>> components
>>>             // that are not visible. As such we need to revalidate 
>>> when the
>>>             // visible bit changes.
>>>             revalidate();
>>> but now this code is invoked only for setVisible(true)
>>>
>> For the setVisible(false) case, the repainting and revalidating 
>> operations will be done in new method JComponent.hide(), so this 
>> change is just to reduce some duplicated actions.
> Ok
>>
>>> 3. Could you please follow our code conventions?  (see 
>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>
>> Sorry for this problem, I was trying to keeping aligned with the 
>> original style of JComponent.java, which I later realized to be 
>> inappropriate. In the updated patch, code has been well formatted.
>>
>>> 4. Your test is not automatic one. I think you could use 
>>> java.awt.Robot#createScreenCapture and analyze result of hide method.
>>
>> See the link, it should be automatic now.
> The test should be corrected:
> 1. All Swing components must be accessed from the EDT thread
Updated in the new test.
> 2. What is the reason to introduce the MyButton class? I think the 
> test can be simplified, if you will use the Util#compareBufferedImages 
> (see test\javax\swing\regtesthelpers\Util.java) method. Just take 
> screen-shots between show/hide and compare them

The reason of introducing MyButton class is to test the show/hide of 
non-opaque component.
I've changed pixel comparison to Util#compareBufferedImages approach.

> 3. Thread.sleep(milisecond) should be replaced by the 
> SunToolkit#realSync method (many existing tests uses it)
>
Updated in new test.

> Regards, Pavel

Thanks and best regards
- Jonathan

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

From luchsh at linux.vnet.ibm.com  Thu Apr 12 11:37:12 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 12 Apr 2012 19:37:12 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
Message-ID: <4F86BE68.1010706@linux.vnet.ibm.com>

Hello swing-dev,

I've got a patch for bug 7055065, can anybody please help to take a look?
http://cr.openjdk.java.net/~luchsh/7055065/

And also a simple test case for this issue here.

/*
  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * version 2 for more details (a copy is included in the LICENSE file that
  * accompanied this code).
  *
  * You should have received a copy of the GNU General Public License 
version
  * 2 along with this work; if not, write to the Free Software Foundation,
  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  * or visit www.oracle.com if you need additional information or have any
  * questions.
  */

/*
  * Portions Copyright (c) 2012 IBM Corporation
  */

import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import javax.swing.table.AbstractTableModel;
import javax.swing.table.TableModel;
import javax.swing.table.TableRowSorter;
import java.awt.Dimension;
import java.awt.GridLayout;

public class TableDemo extends JPanel {

     public TableDemo() {
         super(new GridLayout(1, 0));

         final String[] columnNames = { "String", "Number" };
         final Object[][] data = { { "aaaa", new Integer(5) },
                 { "bbbb", new Integer(3) }, { "cccc", new Integer(2) },
                 { "dddd", new Integer(20) }, { "eeee", new Integer(10) } };
         final JTable table = new JTable(data, columnNames);

         table.setPreferredScrollableViewportSize(new Dimension(500, 400));
         table.setFillsViewportHeight(true);
         TableModel dataModel = new AbstractTableModel() {

             public int getColumnCount() {
                 return columnNames.length;
             }
             public int getRowCount() {
                 return data.length;
             }
             public Object getValueAt(int row, int col) {
                 return data[row][col];
             }
             public String getColumnName(int column) {
                 return columnNames[column];
             }
             public Class<?> getColumnClass(int c) {
                 return getValueAt(0, c).getClass();
             }
             public boolean isCellEditable(int row, int col) {
                 return col != 5;
             }
             public void setValueAt(Object aValue, int row, int column) {
                 data[row][column] = aValue;
             }
         };
         table.setModel(dataModel);
         TableRowSorter<TableModel> sorter = new TableRowSorter<TableModel>(
                 dataModel);
         table.setRowSorter(sorter);

         JScrollPane scrollPane = new JScrollPane(table);
         add(scrollPane);
     }

     public static void main(String[] args) throws Exception {
         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
             public void run() {
                 JFrame frame = new JFrame("SimpleTableDemo");
                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

                 TableDemo newContentPane = new TableDemo();
                 newContentPane.setOpaque(true);
                 frame.setContentPane(newContentPane);

                 frame.pack();
                 frame.setVisible(true);
             }
         });
     }
}

To reproduce the problem,
please click on one cell from the "Number" column, delete all the 
content but do not press enter to quit editing status, then click the 
column title of "Number" column to sort, NPE will be thrown.

The cause of this problem is when trying to quit editing with empty 
content of a cell  and also try to accept the partially edited value 
using stopCellEditing(), following two actions will be taken.
1, the cellEditor of current table will be set to null.
2, the value type of this column does not have a constructor to accept 
"Object[]" parameter, false will be returned.
Then swing will try to cancel edition without accepting the partially 
edited value using cancelCellEditing() which will get null for the value 
of cellEditor thus lead to this NPE.

The patch is trying to return earlier before the type compatibility 
check of partially edited values when empty cell values encountered.

Cheers!
- Jonathan



From pavel.porvatov at oracle.com  Thu Apr 12 14:24:22 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 12 Apr 2012 18:24:22 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
Message-ID: <4F86E596.1080701@oracle.com>

Hi Sean,

The fix looks good, but I have several comments about the test:
1. You shouldn't use Swing components on non-EDT threads, so 
frame.dispose() should be done on the EDT
2. "These exceptions mean the implementation of XTextAreaPeer is 
changed" - I think is XTextAreaPeer is changed, then the test should be 
fixed as well or removed (if the test become inapplicable. Therefore in 
that situation the test should fail but not skipped

Regards, Pavel

> Hi Pavel,
>
>     As awt team has committed the related 
> bug(http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I 
> prepared the webrev for this bug(7129742 
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>) again.
>
>     The new webrev: 
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.05/>  .
>
> The sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
> Previous discussion: 
> http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>
>     Please take a look once more, thank you.
>
> On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>>
>>     Hi Pavel,
>>
>>        Thanks for your comments.
>>
>>     About the 1st question, I modified the testcase a little to
>>     demonstrate the problem, testcase is pasted at the end.
>>
>>     If textArea.setEditable(true) is executed, the frame disposes,
>>     but application doesn't exit.
>>     If textArea.setEditable(false), the application exits as normal.
>>
>>     java 1.7.0_01 and latest java8 code are tested.  And TextField
>>     contains this problem as well. I'll add it to fix later.
>>     Shall I report a separate bug for it ?
>     Yes. I think it will be better if you fix the described above
>     problem as a separate bug. Note that it should be reviewed by the
>     AWT team...
>
>>
>>
>>     About the 2nd question, I was driven by the comment "// TODO :
>>     fix this duplicate code". Is there any strong reason to keep it ?
>     I'm absolutely agree with removing duplicate code. My second
>     question was about added by you
>     "jtext.getCaret().setVisible(false)" in the XTextAreaPeer.java
>     class. I wrote:
>     2. Why don't we need the same code in the XTextFieldPeer class?
>
>     As I can see you've noticed that XTextFieldPeer should be fixed as
>     well (in a separate fix with XTextAreaPeer)
>
>     Regards, Pavel
>
>>
>>
>>     ///////////////////////////////////  a testcase
>>      ////////////////////////////////////////////////////////////
>>     /*
>>      * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>>     reserved.
>>      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>      *
>>      * This code is free software; you can redistribute it and/or
>>     modify it
>>      * under the terms of the GNU General Public License version 2
>>     only, as
>>      * published by the Free Software Foundation.
>>      *
>>      * This code is distributed in the hope that it will be useful,
>>     but WITHOUT
>>      * ANY WARRANTY; without even the implied warranty of
>>     MERCHANTABILITY or
>>      * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>>     License
>>      * version 2 for more details (a copy is included in the LICENSE
>>     file that
>>      * accompanied this code).
>>      *
>>      * You should have received a copy of the GNU General Public
>>     License version
>>      * 2 along with this work; if not, write to the Free Software
>>     Foundation,
>>      * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>      *
>>      * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
>>     94065 USA
>>      * or visit www.oracle.com <http://www.oracle.com> if you need
>>     additional information or have any
>>      * questions.
>>      */
>>
>>     /*
>>      * Portions Copyright (c) 2012 IBM Corporation
>>      */
>>
>>     /* @test
>>      * @bug
>>      * @summary editable TextArea blocks gui app from dispose.
>>      * @author Sean Chou
>>      */
>>
>>     import java.awt.FlowLayout;
>>     import java.awt.Frame;
>>     import java.awt.TextArea;
>>     import java.awt.Toolkit;
>>     import java.lang.reflect.Field;
>>
>>     import javax.swing.JFrame;
>>     import javax.swing.JTextArea;
>>     import javax.swing.SwingUtilities;
>>     import javax.swing.text.DefaultCaret;
>>
>>     import sun.awt.SunToolkit;
>>
>>     public class TextAreaDisposeBug {
>>         public static volatile boolean passed = false;
>>
>>         public static Frame frame = null;
>>         public static TextArea textArea = null;
>>
>>         public static DefaultCaret caret = null;
>>         public static Class XTextAreaPeerClzz = null;
>>
>>         public static void main(String[] args) throws Exception {
>>             SunToolkit toolkit = (SunToolkit)
>>     Toolkit.getDefaultToolkit();
>>             SwingUtilities.invokeAndWait(new Runnable() {
>>                 @Override
>>                 public void run() {
>>                     frame = new JFrame("Test");
>>                     textArea = new TextArea("editable textArea");
>>                     textArea.setEditable(true);
>>     //                textArea.setEditable(false);
>>
>>                     frame.setLayout(new FlowLayout());
>>                     frame.add(textArea);
>>
>>                     frame.pack();
>>                     frame.setVisible(true);
>>                 }
>>             });
>>             toolkit.realSync();
>>             SwingUtilities.invokeAndWait(new Runnable() {
>>                 @Override
>>                 public void run() {
>>                     frame.dispose();
>>                 }
>>             });
>>             toolkit.realSync();
>>         }
>>
>>     }
>>
>>
>>     //////////////////////////////////////////////////////////////////////////////////////////
>>
>>     /*
>>      * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>>     reserved.
>>      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>      *
>>      * This code is free software; you can redistribute it and/or
>>     modify it
>>      * under the terms of the GNU General Public License version 2
>>     only, as
>>      * published by the Free Software Foundation.
>>      *
>>      * This code is distributed in the hope that it will be useful,
>>     but WITHOUT
>>      * ANY WARRANTY; without even the implied warranty of
>>     MERCHANTABILITY or
>>      * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>>     License
>>      * version 2 for more details (a copy is included in the LICENSE
>>     file that
>>      * accompanied this code).
>>      *
>>      * You should have received a copy of the GNU General Public
>>     License version
>>      * 2 along with this work; if not, write to the Free Software
>>     Foundation,
>>      * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>      *
>>      * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
>>     94065 USA
>>      * or visit www.oracle.com <http://www.oracle.com> if you need
>>     additional information or have any
>>      * questions.
>>      */
>>
>>     /*
>>      * Portions Copyright (c) 2012 IBM Corporation
>>      */
>>
>>
>>     /* @test
>>      * @bug
>>      * @summary editable TextField blocks gui app from dispose.
>>      * @author Sean Chou
>>      */
>>
>>     import java.awt.FlowLayout;
>>     import java.awt.Frame;
>>     import java.awt.TextField;
>>     import java.awt.Toolkit;
>>     import java.lang.reflect.Field;
>>
>>     import javax.swing.JFrame;
>>     import javax.swing.JTextArea;
>>     import javax.swing.SwingUtilities;
>>     import javax.swing.text.DefaultCaret;
>>
>>     import sun.awt.SunToolkit;
>>
>>     public class TextFieldDisposeBug {
>>         public static volatile boolean passed = false;
>>
>>         public static Frame frame = null;
>>         public static TextField textField = null;
>>
>>         public static DefaultCaret caret = null;
>>         public static Class XTextAreaPeerClzz = null;
>>
>>         public static void main(String[] args) throws Exception {
>>             SunToolkit toolkit = (SunToolkit)
>>     Toolkit.getDefaultToolkit();
>>             SwingUtilities.invokeAndWait(new Runnable() {
>>                 @Override
>>                 public void run() {
>>                     frame = new JFrame("Test");
>>                     textField = new TextField("editable textArea");
>>     //                textField.setEditable(true);
>>                     textField.setEditable(false);
>>
>>                     frame.setLayout(new FlowLayout());
>>                     frame.add(textField);
>>
>>                     frame.pack();
>>                     frame.setVisible(true);
>>                 }
>>             });
>>             toolkit.realSync();
>>             SwingUtilities.invokeAndWait(new Runnable() {
>>                 @Override
>>                 public void run() {
>>                     frame.dispose();
>>                 }
>>             });
>>             toolkit.realSync();
>>         }
>>
>>     }
>>
>>
>>     On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Sean,
>>
>>         I have a couple questions about the following code in the
>>         XTextAreaPeer.java class
>>         +        // visible caret has a timer thread, which must be
>>         stopped
>>         +        jtext.getCaret().setVisible(false);
>>
>>         1. Why this code wasn't needed before your fix, when caret
>>         was visible for enabled text area?
>>         2. Why don't we need the same code in the XTextFieldPeer class?
>>
>>         About the bug7129742 test:
>>         Because of the passed field is used from different threads
>>         you must use synchronization or mark the field as a volatile.
>>
>>         Regards, Pavel
>>
>>
>>>         Hi Alexander,
>>>
>>>             XTextFieldPeer and   XTextAreaPeer have a same inner
>>>         class XAWTCaret, and in  XTextAreaPeer  there is also a
>>>         comment:
>>>         "// TODO : fix this duplicate code "   before XAWTCaret . So
>>>         I removed the XAWTCaret in XTextFieldPeer and changed the
>>>         XAWTCaret  into a static class, so XTextFieldPeer can
>>>         use XAWTCaret from XTextAreaPeer  .
>>>
>>>             As XAWTCaret is only used in the following
>>>         method  in both XTextAreaPeer and  XTextFieldPeer .
>>>         protected Caret createCaret() {
>>>          return new XAWTCaret();
>>>          }
>>>             I think this modification should not bring side effect.
>>>
>>>         On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin
>>>         <Alexander.Potochkin at oracle.com
>>>         <mailto:Alexander.Potochkin at oracle.com>> wrote:
>>>
>>>             Hello Sean
>>>
>>>             Could you give more details about your changes in
>>>             XTextFieldPeer?
>>>
>>>             Thanks
>>>             alexp
>>>
>>>                 Hi all,
>>>
>>>                   I updated the patch to as suggested and simplified
>>>                 the testcase .
>>>                 Would anyone like to take a look again ? Thanks.
>>>
>>>                  The webrev is at :
>>>                 http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>                 <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>
>>>
>>>
>>>                  Previous discussion at :
>>>                 http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>
>>>                 -- 
>>>                 Best Regards,
>>>                 Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>         -- 
>>>         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/20120412/e99e3af5/attachment.html>

From zhouyx at linux.vnet.ibm.com  Fri Apr 13 08:19:36 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Fri, 13 Apr 2012 16:19:36 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F86E596.1080701@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
Message-ID: <CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>

Hi Pavel,

    I modified the testcase according to your comments. The webrev is
http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/  .  Please take a
look again.

On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> The fix looks good, but I have several comments about the test:
> 1. You shouldn't use Swing components on non-EDT threads, so
> frame.dispose() should be done on the EDT
>
I made a really stupid mistake... When I was checking the testcase and
found frame.dispose() in main method, I added a volatile to the frame
variable...


> 2. "These exceptions mean the implementation of XTextAreaPeer is changed"
> - I think is XTextAreaPeer is changed, then the test should be fixed as
> well or removed (if the test become inapplicable. Therefore in that
> situation the test should fail but not skipped
>
> Regards, Pavel
>
>
>  Hi Pavel,
>
>      As awt team has committed the related bug(
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I prepared the
> webrev for this bug(7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>)
> again.
>
>      The new webrev: http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/
> .
>
>  The sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
> Previous discussion:
> http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>
>      Please take a look once more, thank you.
>
> On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov <pavel.porvatov at oracle.com
> > wrote:
>
>>  Hi Sean,
>>
>>
>>  Hi Pavel,
>>
>>     Thanks for your comments.
>>
>>  About the 1st question, I modified the testcase a little to demonstrate
>> the problem, testcase is pasted at the end.
>>
>>  If textArea.setEditable(true) is executed, the frame disposes, but
>> application doesn't exit.
>> If textArea.setEditable(false), the application exits as normal.
>>
>>  java 1.7.0_01 and latest java8 code are tested.  And TextField contains
>> this problem as well. I'll add it to fix later.
>> Shall I report a separate bug for it ?
>>
>>  Yes. I think it will be better if you fix the described above problem as
>> a separate bug. Note that it should be reviewed by the AWT team...
>>
>>
>>
>>  About the 2nd question, I was driven by the comment "// TODO : fix this
>> duplicate code". Is there any strong reason to keep it ?
>>
>>  I'm absolutely agree with removing duplicate code. My second question
>> was about added by you "jtext.getCaret().setVisible(false)" in the
>> XTextAreaPeer.java class. I wrote:
>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>
>>  As I can see you've noticed that XTextFieldPeer should be fixed as well
>> (in a separate fix with XTextAreaPeer)
>>
>> Regards, Pavel
>>
>>
>>
>>  ///////////////////////////////////  a testcase
>>  ////////////////////////////////////////////////////////////
>>  /*
>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but
>> WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>   * You should have received a copy of the GNU General Public License
>> version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>   * questions.
>>  */
>>
>>  /*
>>  * Portions Copyright (c) 2012 IBM Corporation
>>  */
>>
>>  /* @test
>>  * @bug
>>  * @summary editable TextArea blocks gui app from dispose.
>>  * @author Sean Chou
>>  */
>>
>>  import java.awt.FlowLayout;
>> import java.awt.Frame;
>> import java.awt.TextArea;
>> import java.awt.Toolkit;
>> import java.lang.reflect.Field;
>>
>>  import javax.swing.JFrame;
>> import javax.swing.JTextArea;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.DefaultCaret;
>>
>>  import sun.awt.SunToolkit;
>>
>>  public class TextAreaDisposeBug {
>>     public static volatile boolean passed = false;
>>
>>      public static Frame frame = null;
>>     public static TextArea textArea = null;
>>
>>      public static DefaultCaret caret = null;
>>     public static Class XTextAreaPeerClzz = null;
>>
>>      public static void main(String[] args) throws Exception {
>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>         SwingUtilities.invokeAndWait(new Runnable() {
>>             @Override
>>             public void run() {
>>                 frame = new JFrame("Test");
>>
>>                 textArea = new TextArea("editable textArea");
>>                 textArea.setEditable(true);
>> //                textArea.setEditable(false);
>>
>>                  frame.setLayout(new FlowLayout());
>>                 frame.add(textArea);
>>
>>                  frame.pack();
>>                 frame.setVisible(true);
>>
>>             }
>>         });
>>         toolkit.realSync();
>>
>>         SwingUtilities.invokeAndWait(new Runnable() {
>>             @Override
>>             public void run() {
>>                 frame.dispose();
>>             }
>>         });
>>         toolkit.realSync();
>>     }
>>
>>  }
>>
>>
>>
>> //////////////////////////////////////////////////////////////////////////////////////////
>>  /*
>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but
>> WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>   * You should have received a copy of the GNU General Public License
>> version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>   * questions.
>>  */
>>
>>  /*
>>  * Portions Copyright (c) 2012 IBM Corporation
>>  */
>>
>>
>>  /* @test
>>  * @bug
>>  * @summary editable TextField blocks gui app from dispose.
>>  * @author Sean Chou
>>  */
>>
>>  import java.awt.FlowLayout;
>> import java.awt.Frame;
>> import java.awt.TextField;
>> import java.awt.Toolkit;
>> import java.lang.reflect.Field;
>>
>>  import javax.swing.JFrame;
>> import javax.swing.JTextArea;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.DefaultCaret;
>>
>>  import sun.awt.SunToolkit;
>>
>>  public class TextFieldDisposeBug {
>>     public static volatile boolean passed = false;
>>
>>      public static Frame frame = null;
>>     public static TextField textField = null;
>>
>>      public static DefaultCaret caret = null;
>>     public static Class XTextAreaPeerClzz = null;
>>
>>      public static void main(String[] args) throws Exception {
>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>         SwingUtilities.invokeAndWait(new Runnable() {
>>             @Override
>>             public void run() {
>>                 frame = new JFrame("Test");
>>
>>                 textField = new TextField("editable textArea");
>> //                textField.setEditable(true);
>>                 textField.setEditable(false);
>>
>>                  frame.setLayout(new FlowLayout());
>>                 frame.add(textField);
>>
>>                  frame.pack();
>>                 frame.setVisible(true);
>>
>>             }
>>         });
>>         toolkit.realSync();
>>
>>         SwingUtilities.invokeAndWait(new Runnable() {
>>             @Override
>>             public void run() {
>>                 frame.dispose();
>>             }
>>         });
>>         toolkit.realSync();
>>     }
>>
>>  }
>>
>>
>>  On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov <
>> pavel.porvatov at oracle.com> wrote:
>>
>>>  Hi Sean,
>>>
>>> I have a couple questions about the following code in the
>>> XTextAreaPeer.java class
>>> +        // visible caret has a timer thread, which must be stopped
>>> +        jtext.getCaret().setVisible(false);
>>>
>>> 1. Why this code wasn't needed before your fix, when caret was visible
>>> for enabled text area?
>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>
>>> About the bug7129742 test:
>>> Because of the passed field is used from different threads you must use
>>> synchronization or mark the field as a volatile.
>>>
>>> Regards, Pavel
>>>
>>>
>>> Hi Alexander,
>>>
>>>      XTextFieldPeer and   XTextAreaPeer have a same inner
>>> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
>>> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
>>> the XAWTCaret in XTextFieldPeer and changed the
>>> XAWTCaret  into a static class, so XTextFieldPeer can
>>> use XAWTCaret from XTextAreaPeer  .
>>>
>>>      As XAWTCaret is only used in the following
>>> method  in both XTextAreaPeer and  XTextFieldPeer .
>>> protected Caret createCaret() {
>>>  return new XAWTCaret();
>>>  }
>>>      I think this modification should not bring side effect.
>>>
>>>  On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
>>> Alexander.Potochkin at oracle.com> wrote:
>>>
>>>> Hello Sean
>>>>
>>>> Could you give more details about your changes in XTextFieldPeer?
>>>>
>>>> Thanks
>>>> alexp
>>>>
>>>>  Hi all,
>>>>>
>>>>>   I updated the patch to as suggested and simplified the testcase .
>>>>> Would anyone like to take a look again ? Thanks.
>>>>>
>>>>>   The webrev is at :
>>>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <
>>>>> http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>
>>>>>
>>>>>  Previous discussion at :
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>> Sean Chou
>>>>>
>>>>>
>>>>
>>>
>>>
>>>  --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>>>
>>
>>
>>  --
>> 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/20120413/bfe73736/attachment.html>

From pavel.porvatov at oracle.com  Fri Apr 13 09:59:17 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 13 Apr 2012 13:59:17 +0400
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F86BE68.1010706@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com>
Message-ID: <4F87F8F5.3000406@oracle.com>

Hi Jonathan,

The fix looks good. Could you please write an automatic test, put it 
into an appropriate place of repository and make a webrev with fix and test?

Regards, Pavel
> Hello swing-dev,
>
> I've got a patch for bug 7055065, can anybody please help to take a look?
> http://cr.openjdk.java.net/~luchsh/7055065/
>
> And also a simple test case for this issue here.
>
> /*
>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but 
> WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file 
> that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License 
> version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 
> USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
>
> /*
>  * Portions Copyright (c) 2012 IBM Corporation
>  */
>
> import javax.swing.JFrame;
> import javax.swing.JPanel;
> import javax.swing.JScrollPane;
> import javax.swing.JTable;
> import javax.swing.table.AbstractTableModel;
> import javax.swing.table.TableModel;
> import javax.swing.table.TableRowSorter;
> import java.awt.Dimension;
> import java.awt.GridLayout;
>
> public class TableDemo extends JPanel {
>
>     public TableDemo() {
>         super(new GridLayout(1, 0));
>
>         final String[] columnNames = { "String", "Number" };
>         final Object[][] data = { { "aaaa", new Integer(5) },
>                 { "bbbb", new Integer(3) }, { "cccc", new Integer(2) },
>                 { "dddd", new Integer(20) }, { "eeee", new Integer(10) 
> } };
>         final JTable table = new JTable(data, columnNames);
>
>         table.setPreferredScrollableViewportSize(new Dimension(500, 
> 400));
>         table.setFillsViewportHeight(true);
>         TableModel dataModel = new AbstractTableModel() {
>
>             public int getColumnCount() {
>                 return columnNames.length;
>             }
>             public int getRowCount() {
>                 return data.length;
>             }
>             public Object getValueAt(int row, int col) {
>                 return data[row][col];
>             }
>             public String getColumnName(int column) {
>                 return columnNames[column];
>             }
>             public Class<?> getColumnClass(int c) {
>                 return getValueAt(0, c).getClass();
>             }
>             public boolean isCellEditable(int row, int col) {
>                 return col != 5;
>             }
>             public void setValueAt(Object aValue, int row, int column) {
>                 data[row][column] = aValue;
>             }
>         };
>         table.setModel(dataModel);
>         TableRowSorter<TableModel> sorter = new 
> TableRowSorter<TableModel>(
>                 dataModel);
>         table.setRowSorter(sorter);
>
>         JScrollPane scrollPane = new JScrollPane(table);
>         add(scrollPane);
>     }
>
>     public static void main(String[] args) throws Exception {
>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>             public void run() {
>                 JFrame frame = new JFrame("SimpleTableDemo");
>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>
>                 TableDemo newContentPane = new TableDemo();
>                 newContentPane.setOpaque(true);
>                 frame.setContentPane(newContentPane);
>
>                 frame.pack();
>                 frame.setVisible(true);
>             }
>         });
>     }
> }
>
> To reproduce the problem,
> please click on one cell from the "Number" column, delete all the 
> content but do not press enter to quit editing status, then click the 
> column title of "Number" column to sort, NPE will be thrown.
>
> The cause of this problem is when trying to quit editing with empty 
> content of a cell  and also try to accept the partially edited value 
> using stopCellEditing(), following two actions will be taken.
> 1, the cellEditor of current table will be set to null.
> 2, the value type of this column does not have a constructor to accept 
> "Object[]" parameter, false will be returned.
> Then swing will try to cancel edition without accepting the partially 
> edited value using cancelCellEditing() which will get null for the 
> value of cellEditor thus lead to this NPE.
>
> The patch is trying to return earlier before the type compatibility 
> check of partially edited values when empty cell values encountered.
>
> Cheers!
> - Jonathan
>



From pavel.porvatov at oracle.com  Fri Apr 13 10:39:47 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 13 Apr 2012 14:39:47 +0400
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F86B92D.9080900@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
Message-ID: <4F880273.3080704@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> Here's another updated patch.
> http://cr.openjdk.java.net/~luchsh/7154030_5/
>
> My comments are inlined.
See below
>
> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> Here's the update patch,
>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>
>> Could you please explain one change in the JComponent.java:
>>
>> +    public void hide() {
>> +        if (isVisible()) {
>> +            super.hide();
>>
>> I think super.hide() should be invoked always. You must also add a 
>> javadoc to the new hide method (see {@inheritDoc} for details)
>
> Yes, the old patch may cause Component.isPacked not to be set 
> correctly, so moved super.hide() up.
Ok. The next question: I think we should use in "if (isVisible())" 
isShowing instead of isVisible. What do you think about that?
>
>>
>>
>>
>>>> 3. Could you please follow our code conventions?  (see 
>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>
>>> Sorry for this problem, I was trying to keeping aligned with the 
>>> original style of JComponent.java, which I later realized to be 
>>> inappropriate. In the updated patch, code has been well formatted.
>>>
>>>> 4. Your test is not automatic one. I think you could use 
>>>> java.awt.Robot#createScreenCapture and analyze result of hide method.
>>>
>>> See the link, it should be automatic now.
>> The test should be corrected:
>> 1. All Swing components must be accessed from the EDT thread
> Updated in the new test.
>> 2. What is the reason to introduce the MyButton class? I think the 
>> test can be simplified, if you will use the 
>> Util#compareBufferedImages (see 
>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>> screen-shots between show/hide and compare them
>
> The reason of introducing MyButton class is to test the show/hide of 
> non-opaque component.
Why can't we use something like following:
                 button.setOpaque(false);
                 button.setBackground(new Color(255, 0, 0, 128));

> I've changed pixel comparison to Util#compareBufferedImages approach.
>
>> 3. Thread.sleep(milisecond) should be replaced by the 
>> SunToolkit#realSync method (many existing tests uses it)
>>
> Updated in new test.
Looks good. Could you please remove unnecessary "volatile" modifiers?

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120413/9e3c77b6/attachment.html>

From pavel.porvatov at oracle.com  Sun Apr 15 09:31:06 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sun, 15 Apr 2012 13:31:06 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
Message-ID: <4F8A955A.5010605@oracle.com>

Hi Sean,
> Hi Pavel,
>
>     I modified the testcase according to your comments. The webrev is 
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.06/>  .  Please 
> take a look again.
And now when fastreturn is true the test doesn't stop.

Regards, Pavel
>
> On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>
>     The fix looks good, but I have several comments about the test:
>     1. You shouldn't use Swing components on non-EDT threads, so
>     frame.dispose() should be done on the EDT
>
> I made a really stupid mistake... When I was checking the testcase and 
> found frame.dispose() in main method, I added a volatile to the frame 
> variable...
>
>     2. "These exceptions mean the implementation of XTextAreaPeer is
>     changed" - I think is XTextAreaPeer is changed, then the test
>     should be fixed as well or removed (if the test become
>     inapplicable. Therefore in that situation the test should fail but
>     not skipped
>
>     Regards, Pavel
>
>
>>     Hi Pavel,
>>
>>         As awt team has committed the related
>>     bug(http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I
>>     prepared the webrev for this bug(7129742
>>     <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>) again.
>>
>>         The new webrev:
>>     http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.05/>  .
>>
>>     The sunbug:
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
>>     Previous discussion:
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>>
>>
>>         Please take a look once more, thank you.
>>
>>     On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Sean,
>>>
>>>         Hi Pavel,
>>>
>>>            Thanks for your comments.
>>>
>>>         About the 1st question, I modified the testcase a little to
>>>         demonstrate the problem, testcase is pasted at the end.
>>>
>>>         If textArea.setEditable(true) is executed, the frame
>>>         disposes, but application doesn't exit.
>>>         If textArea.setEditable(false), the application exits as normal.
>>>
>>>         java 1.7.0_01 and latest java8 code are tested.  And
>>>         TextField contains this problem as well. I'll add it to fix
>>>         later.
>>>         Shall I report a separate bug for it ?
>>         Yes. I think it will be better if you fix the described above
>>         problem as a separate bug. Note that it should be reviewed by
>>         the AWT team...
>>
>>>
>>>
>>>         About the 2nd question, I was driven by the comment "// TODO
>>>         : fix this duplicate code". Is there any strong reason to
>>>         keep it ?
>>         I'm absolutely agree with removing duplicate code. My second
>>         question was about added by you
>>         "jtext.getCaret().setVisible(false)" in the
>>         XTextAreaPeer.java class. I wrote:
>>         2. Why don't we need the same code in the XTextFieldPeer class?
>>
>>         As I can see you've noticed that XTextFieldPeer should be
>>         fixed as well (in a separate fix with XTextAreaPeer)
>>
>>         Regards, Pavel
>>
>>>
>>>
>>>         ///////////////////////////////////  a testcase
>>>          ////////////////////////////////////////////////////////////
>>>         /*
>>>          * Copyright (c) 2012 Oracle and/or its affiliates. All
>>>         rights reserved.
>>>          * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>          *
>>>          * This code is free software; you can redistribute it
>>>         and/or modify it
>>>          * under the terms of the GNU General Public License version
>>>         2 only, as
>>>          * published by the Free Software Foundation.
>>>          *
>>>          * This code is distributed in the hope that it will be
>>>         useful, but WITHOUT
>>>          * ANY WARRANTY; without even the implied warranty of
>>>         MERCHANTABILITY or
>>>          * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
>>>         Public License
>>>          * version 2 for more details (a copy is included in the
>>>         LICENSE file that
>>>          * accompanied this code).
>>>          *
>>>          * You should have received a copy of the GNU General Public
>>>         License version
>>>          * 2 along with this work; if not, write to the Free
>>>         Software Foundation,
>>>          * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>          *
>>>          * Please contact Oracle, 500 Oracle Parkway, Redwood
>>>         Shores, CA 94065 USA
>>>          * or visit www.oracle.com <http://www.oracle.com> if you
>>>         need additional information or have any
>>>          * questions.
>>>          */
>>>
>>>         /*
>>>          * Portions Copyright (c) 2012 IBM Corporation
>>>          */
>>>
>>>         /* @test
>>>          * @bug
>>>          * @summary editable TextArea blocks gui app from dispose.
>>>          * @author Sean Chou
>>>          */
>>>
>>>         import java.awt.FlowLayout;
>>>         import java.awt.Frame;
>>>         import java.awt.TextArea;
>>>         import java.awt.Toolkit;
>>>         import java.lang.reflect.Field;
>>>
>>>         import javax.swing.JFrame;
>>>         import javax.swing.JTextArea;
>>>         import javax.swing.SwingUtilities;
>>>         import javax.swing.text.DefaultCaret;
>>>
>>>         import sun.awt.SunToolkit;
>>>
>>>         public class TextAreaDisposeBug {
>>>             public static volatile boolean passed = false;
>>>
>>>             public static Frame frame = null;
>>>             public static TextArea textArea = null;
>>>
>>>             public static DefaultCaret caret = null;
>>>             public static Class XTextAreaPeerClzz = null;
>>>
>>>             public static void main(String[] args) throws Exception {
>>>                 SunToolkit toolkit = (SunToolkit)
>>>         Toolkit.getDefaultToolkit();
>>>                 SwingUtilities.invokeAndWait(new Runnable() {
>>>                     @Override
>>>                     public void run() {
>>>                         frame = new JFrame("Test");
>>>                         textArea = new TextArea("editable textArea");
>>>                         textArea.setEditable(true);
>>>         //                textArea.setEditable(false);
>>>
>>>                         frame.setLayout(new FlowLayout());
>>>                         frame.add(textArea);
>>>
>>>                         frame.pack();
>>>                         frame.setVisible(true);
>>>                     }
>>>                 });
>>>                 toolkit.realSync();
>>>                 SwingUtilities.invokeAndWait(new Runnable() {
>>>                     @Override
>>>                     public void run() {
>>>                         frame.dispose();
>>>                     }
>>>                 });
>>>                 toolkit.realSync();
>>>             }
>>>
>>>         }
>>>
>>>
>>>         //////////////////////////////////////////////////////////////////////////////////////////
>>>
>>>         /*
>>>          * Copyright (c) 2012 Oracle and/or its affiliates. All
>>>         rights reserved.
>>>          * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>          *
>>>          * This code is free software; you can redistribute it
>>>         and/or modify it
>>>          * under the terms of the GNU General Public License version
>>>         2 only, as
>>>          * published by the Free Software Foundation.
>>>          *
>>>          * This code is distributed in the hope that it will be
>>>         useful, but WITHOUT
>>>          * ANY WARRANTY; without even the implied warranty of
>>>         MERCHANTABILITY or
>>>          * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
>>>         Public License
>>>          * version 2 for more details (a copy is included in the
>>>         LICENSE file that
>>>          * accompanied this code).
>>>          *
>>>          * You should have received a copy of the GNU General Public
>>>         License version
>>>          * 2 along with this work; if not, write to the Free
>>>         Software Foundation,
>>>          * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>          *
>>>          * Please contact Oracle, 500 Oracle Parkway, Redwood
>>>         Shores, CA 94065 USA
>>>          * or visit www.oracle.com <http://www.oracle.com> if you
>>>         need additional information or have any
>>>          * questions.
>>>          */
>>>
>>>         /*
>>>          * Portions Copyright (c) 2012 IBM Corporation
>>>          */
>>>
>>>
>>>         /* @test
>>>          * @bug
>>>          * @summary editable TextField blocks gui app from dispose.
>>>          * @author Sean Chou
>>>          */
>>>
>>>         import java.awt.FlowLayout;
>>>         import java.awt.Frame;
>>>         import java.awt.TextField;
>>>         import java.awt.Toolkit;
>>>         import java.lang.reflect.Field;
>>>
>>>         import javax.swing.JFrame;
>>>         import javax.swing.JTextArea;
>>>         import javax.swing.SwingUtilities;
>>>         import javax.swing.text.DefaultCaret;
>>>
>>>         import sun.awt.SunToolkit;
>>>
>>>         public class TextFieldDisposeBug {
>>>             public static volatile boolean passed = false;
>>>
>>>             public static Frame frame = null;
>>>             public static TextField textField = null;
>>>
>>>             public static DefaultCaret caret = null;
>>>             public static Class XTextAreaPeerClzz = null;
>>>
>>>             public static void main(String[] args) throws Exception {
>>>                 SunToolkit toolkit = (SunToolkit)
>>>         Toolkit.getDefaultToolkit();
>>>                 SwingUtilities.invokeAndWait(new Runnable() {
>>>                     @Override
>>>                     public void run() {
>>>                         frame = new JFrame("Test");
>>>                         textField = new TextField("editable textArea");
>>>         //                textField.setEditable(true);
>>>                         textField.setEditable(false);
>>>
>>>                         frame.setLayout(new FlowLayout());
>>>                         frame.add(textField);
>>>
>>>                         frame.pack();
>>>                         frame.setVisible(true);
>>>                     }
>>>                 });
>>>                 toolkit.realSync();
>>>                 SwingUtilities.invokeAndWait(new Runnable() {
>>>                     @Override
>>>                     public void run() {
>>>                         frame.dispose();
>>>                     }
>>>                 });
>>>                 toolkit.realSync();
>>>             }
>>>
>>>         }
>>>
>>>
>>>         On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov
>>>         <pavel.porvatov at oracle.com
>>>         <mailto:pavel.porvatov at oracle.com>> wrote:
>>>
>>>             Hi Sean,
>>>
>>>             I have a couple questions about the following code in
>>>             the XTextAreaPeer.java class
>>>             +        // visible caret has a timer thread, which must
>>>             be stopped
>>>             +        jtext.getCaret().setVisible(false);
>>>
>>>             1. Why this code wasn't needed before your fix, when
>>>             caret was visible for enabled text area?
>>>             2. Why don't we need the same code in the XTextFieldPeer
>>>             class?
>>>
>>>             About the bug7129742 test:
>>>             Because of the passed field is used from different
>>>             threads you must use synchronization or mark the field
>>>             as a volatile.
>>>
>>>             Regards, Pavel
>>>
>>>
>>>>             Hi Alexander,
>>>>
>>>>                 XTextFieldPeer and   XTextAreaPeer have a same
>>>>             inner class XAWTCaret, and in  XTextAreaPeer  there is
>>>>             also a comment:
>>>>             "// TODO : fix this duplicate code "   before XAWTCaret
>>>>             . So I removed the XAWTCaret in XTextFieldPeer and
>>>>             changed the
>>>>             XAWTCaret  into a static class, so XTextFieldPeer can
>>>>             use XAWTCaret from XTextAreaPeer  .
>>>>
>>>>                 As XAWTCaret is only used in the following
>>>>             method  in both XTextAreaPeer and  XTextFieldPeer .
>>>>             protected Caret createCaret() {
>>>>              return new XAWTCaret();
>>>>              }
>>>>                 I think this modification should not bring side effect.
>>>>
>>>>             On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin
>>>>             <Alexander.Potochkin at oracle.com
>>>>             <mailto:Alexander.Potochkin at oracle.com>> wrote:
>>>>
>>>>                 Hello Sean
>>>>
>>>>                 Could you give more details about your changes in
>>>>                 XTextFieldPeer?
>>>>
>>>>                 Thanks
>>>>                 alexp
>>>>
>>>>                     Hi all,
>>>>
>>>>                       I updated the patch to as suggested and
>>>>                     simplified the testcase .
>>>>                     Would anyone like to take a look again ? Thanks.
>>>>
>>>>                      The webrev is at :
>>>>                     http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/
>>>>                     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>                     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>
>>>>
>>>>
>>>>                      Previous discussion at :
>>>>                     http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>
>>>>                     -- 
>>>>                     Best Regards,
>>>>                     Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Best Regards,
>>>>             Sean Chou
>>>>
>>>
>>>
>>>
>>>
>>>         -- 
>>>         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/20120415/242b9169/attachment.html>

From zhouyx at linux.vnet.ibm.com  Mon Apr 16 04:33:42 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 16 Apr 2012 12:33:42 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F8A955A.5010605@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
Message-ID: <CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>

Hi Pavel,

    Modified and tested on windows and linux.

webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/



On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> Hi Pavel,
>
>      I modified the testcase according to your comments. The webrev is
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/  .  Please take a
> look again.
>
> And now when fastreturn is true the test doesn't stop.
>
> Regards, Pavel
>
>
> On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov <
> pavel.porvatov at oracle.com> wrote:
>
>>  Hi Sean,
>>
>> The fix looks good, but I have several comments about the test:
>> 1. You shouldn't use Swing components on non-EDT threads, so
>> frame.dispose() should be done on the EDT
>>
> I made a really stupid mistake... When I was checking the testcase and
> found frame.dispose() in main method, I added a volatile to the frame
> variable...
>
>
>>  2. "These exceptions mean the implementation of XTextAreaPeer is
>> changed" - I think is XTextAreaPeer is changed, then the test should be
>> fixed as well or removed (if the test become inapplicable. Therefore in
>> that situation the test should fail but not skipped
>>
>> Regards, Pavel
>>
>>
>>  Hi Pavel,
>>
>>      As awt team has committed the related bug(
>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I prepared
>> the webrev for this bug(7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>)
>> again.
>>
>>      The new webrev:
>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/  .
>>
>>  The sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
>> Previous discussion:
>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>>
>>      Please take a look once more, thank you.
>>
>> On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov <
>> pavel.porvatov at oracle.com> wrote:
>>
>>>  Hi Sean,
>>>
>>>
>>>  Hi Pavel,
>>>
>>>     Thanks for your comments.
>>>
>>>  About the 1st question, I modified the testcase a little to
>>> demonstrate the problem, testcase is pasted at the end.
>>>
>>>  If textArea.setEditable(true) is executed, the frame disposes, but
>>> application doesn't exit.
>>> If textArea.setEditable(false), the application exits as normal.
>>>
>>>  java 1.7.0_01 and latest java8 code are tested.  And TextField
>>> contains this problem as well. I'll add it to fix later.
>>> Shall I report a separate bug for it ?
>>>
>>>  Yes. I think it will be better if you fix the described above problem
>>> as a separate bug. Note that it should be reviewed by the AWT team...
>>>
>>>
>>>
>>>  About the 2nd question, I was driven by the comment "// TODO : fix
>>> this duplicate code". Is there any strong reason to keep it ?
>>>
>>>  I'm absolutely agree with removing duplicate code. My second question
>>> was about added by you "jtext.getCaret().setVisible(false)" in the
>>> XTextAreaPeer.java class. I wrote:
>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>
>>>  As I can see you've noticed that XTextFieldPeer should be fixed as well
>>> (in a separate fix with XTextAreaPeer)
>>>
>>> Regards, Pavel
>>>
>>>
>>>
>>>  ///////////////////////////////////  a testcase
>>>  ////////////////////////////////////////////////////////////
>>>  /*
>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>>  * under the terms of the GNU General Public License version 2 only, as
>>>  * published by the Free Software Foundation.
>>>  *
>>>  * This code is distributed in the hope that it will be useful, but
>>> WITHOUT
>>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>  * version 2 for more details (a copy is included in the LICENSE file
>>> that
>>>  * accompanied this code).
>>>  *
>>>   * You should have received a copy of the GNU General Public License
>>> version
>>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>  *
>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065
>>> USA
>>>  * or visit www.oracle.com if you need additional information or have
>>> any
>>>   * questions.
>>>  */
>>>
>>>  /*
>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>  */
>>>
>>>  /* @test
>>>  * @bug
>>>  * @summary editable TextArea blocks gui app from dispose.
>>>  * @author Sean Chou
>>>  */
>>>
>>>  import java.awt.FlowLayout;
>>> import java.awt.Frame;
>>> import java.awt.TextArea;
>>> import java.awt.Toolkit;
>>> import java.lang.reflect.Field;
>>>
>>>  import javax.swing.JFrame;
>>> import javax.swing.JTextArea;
>>> import javax.swing.SwingUtilities;
>>> import javax.swing.text.DefaultCaret;
>>>
>>>  import sun.awt.SunToolkit;
>>>
>>>  public class TextAreaDisposeBug {
>>>     public static volatile boolean passed = false;
>>>
>>>      public static Frame frame = null;
>>>     public static TextArea textArea = null;
>>>
>>>      public static DefaultCaret caret = null;
>>>     public static Class XTextAreaPeerClzz = null;
>>>
>>>      public static void main(String[] args) throws Exception {
>>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>             @Override
>>>             public void run() {
>>>                 frame = new JFrame("Test");
>>>
>>>                 textArea = new TextArea("editable textArea");
>>>                 textArea.setEditable(true);
>>> //                textArea.setEditable(false);
>>>
>>>                  frame.setLayout(new FlowLayout());
>>>                 frame.add(textArea);
>>>
>>>                  frame.pack();
>>>                 frame.setVisible(true);
>>>
>>>             }
>>>         });
>>>         toolkit.realSync();
>>>
>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>             @Override
>>>             public void run() {
>>>                 frame.dispose();
>>>             }
>>>         });
>>>         toolkit.realSync();
>>>     }
>>>
>>>  }
>>>
>>>
>>>
>>> //////////////////////////////////////////////////////////////////////////////////////////
>>>  /*
>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>>  * under the terms of the GNU General Public License version 2 only, as
>>>  * published by the Free Software Foundation.
>>>  *
>>>  * This code is distributed in the hope that it will be useful, but
>>> WITHOUT
>>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>  * version 2 for more details (a copy is included in the LICENSE file
>>> that
>>>  * accompanied this code).
>>>  *
>>>   * You should have received a copy of the GNU General Public License
>>> version
>>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>  *
>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065
>>> USA
>>>  * or visit www.oracle.com if you need additional information or have
>>> any
>>>   * questions.
>>>  */
>>>
>>>  /*
>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>  */
>>>
>>>
>>>  /* @test
>>>  * @bug
>>>  * @summary editable TextField blocks gui app from dispose.
>>>  * @author Sean Chou
>>>  */
>>>
>>>  import java.awt.FlowLayout;
>>> import java.awt.Frame;
>>> import java.awt.TextField;
>>> import java.awt.Toolkit;
>>> import java.lang.reflect.Field;
>>>
>>>  import javax.swing.JFrame;
>>> import javax.swing.JTextArea;
>>> import javax.swing.SwingUtilities;
>>> import javax.swing.text.DefaultCaret;
>>>
>>>  import sun.awt.SunToolkit;
>>>
>>>  public class TextFieldDisposeBug {
>>>     public static volatile boolean passed = false;
>>>
>>>      public static Frame frame = null;
>>>     public static TextField textField = null;
>>>
>>>      public static DefaultCaret caret = null;
>>>     public static Class XTextAreaPeerClzz = null;
>>>
>>>      public static void main(String[] args) throws Exception {
>>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>             @Override
>>>             public void run() {
>>>                 frame = new JFrame("Test");
>>>
>>>                 textField = new TextField("editable textArea");
>>> //                textField.setEditable(true);
>>>                 textField.setEditable(false);
>>>
>>>                  frame.setLayout(new FlowLayout());
>>>                 frame.add(textField);
>>>
>>>                  frame.pack();
>>>                 frame.setVisible(true);
>>>
>>>             }
>>>         });
>>>         toolkit.realSync();
>>>
>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>             @Override
>>>             public void run() {
>>>                 frame.dispose();
>>>             }
>>>         });
>>>         toolkit.realSync();
>>>     }
>>>
>>>  }
>>>
>>>
>>>  On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov <
>>> pavel.porvatov at oracle.com> wrote:
>>>
>>>>  Hi Sean,
>>>>
>>>> I have a couple questions about the following code in the
>>>> XTextAreaPeer.java class
>>>> +        // visible caret has a timer thread, which must be stopped
>>>> +        jtext.getCaret().setVisible(false);
>>>>
>>>> 1. Why this code wasn't needed before your fix, when caret was visible
>>>> for enabled text area?
>>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>>
>>>> About the bug7129742 test:
>>>> Because of the passed field is used from different threads you must use
>>>> synchronization or mark the field as a volatile.
>>>>
>>>> Regards, Pavel
>>>>
>>>>
>>>> Hi Alexander,
>>>>
>>>>      XTextFieldPeer and   XTextAreaPeer have a same inner
>>>> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
>>>> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
>>>> the XAWTCaret in XTextFieldPeer and changed the
>>>> XAWTCaret  into a static class, so XTextFieldPeer can
>>>> use XAWTCaret from XTextAreaPeer  .
>>>>
>>>>      As XAWTCaret is only used in the following
>>>> method  in both XTextAreaPeer and  XTextFieldPeer .
>>>> protected Caret createCaret() {
>>>>  return new XAWTCaret();
>>>>  }
>>>>      I think this modification should not bring side effect.
>>>>
>>>>  On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
>>>> Alexander.Potochkin at oracle.com> wrote:
>>>>
>>>>> Hello Sean
>>>>>
>>>>> Could you give more details about your changes in XTextFieldPeer?
>>>>>
>>>>> Thanks
>>>>> alexp
>>>>>
>>>>>  Hi all,
>>>>>>
>>>>>>   I updated the patch to as suggested and simplified the testcase .
>>>>>> Would anyone like to take a look again ? Thanks.
>>>>>>
>>>>>>   The webrev is at :
>>>>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <
>>>>>> http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>>
>>>>>>
>>>>>>  Previous discussion at :
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>> Sean Chou
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>>>
>>
>>
>>  --
>> 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/20120416/2d8d40d1/attachment.html>

From luchsh at linux.vnet.ibm.com  Mon Apr 16 07:56:14 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 16 Apr 2012 15:56:14 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F87F8F5.3000406@oracle.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
Message-ID: <4F8BD09E.6020209@linux.vnet.ibm.com>

Hi Pavel,

Thanks for reviewing, here's the webrev patch and automatic test. Could 
you please help to take another look?
http://cr.openjdk.java.net/~luchsh/7055065/

Thanks & regards!
- Jonathan

On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>
> The fix looks good. Could you please write an automatic test, put it 
> into an appropriate place of repository and make a webrev with fix and 
> test?
>
> Regards, Pavel
>> Hello swing-dev,
>>
>> I've got a patch for bug 7055065, can anybody please help to take a 
>> look?
>> http://cr.openjdk.java.net/~luchsh/7055065/
>>
>> And also a simple test case for this issue here.
>>
>> /*
>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but 
>> WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file 
>> that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License 
>> version
>>  * 2 along with this work; if not, write to the Free Software 
>> Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>> 94065 USA
>>  * or visit www.oracle.com if you need additional information or have 
>> any
>>  * questions.
>>  */
>>
>> /*
>>  * Portions Copyright (c) 2012 IBM Corporation
>>  */
>>
>> import javax.swing.JFrame;
>> import javax.swing.JPanel;
>> import javax.swing.JScrollPane;
>> import javax.swing.JTable;
>> import javax.swing.table.AbstractTableModel;
>> import javax.swing.table.TableModel;
>> import javax.swing.table.TableRowSorter;
>> import java.awt.Dimension;
>> import java.awt.GridLayout;
>>
>> public class TableDemo extends JPanel {
>>
>>     public TableDemo() {
>>         super(new GridLayout(1, 0));
>>
>>         final String[] columnNames = { "String", "Number" };
>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>                 { "bbbb", new Integer(3) }, { "cccc", new Integer(2) },
>>                 { "dddd", new Integer(20) }, { "eeee", new 
>> Integer(10) } };
>>         final JTable table = new JTable(data, columnNames);
>>
>>         table.setPreferredScrollableViewportSize(new Dimension(500, 
>> 400));
>>         table.setFillsViewportHeight(true);
>>         TableModel dataModel = new AbstractTableModel() {
>>
>>             public int getColumnCount() {
>>                 return columnNames.length;
>>             }
>>             public int getRowCount() {
>>                 return data.length;
>>             }
>>             public Object getValueAt(int row, int col) {
>>                 return data[row][col];
>>             }
>>             public String getColumnName(int column) {
>>                 return columnNames[column];
>>             }
>>             public Class<?> getColumnClass(int c) {
>>                 return getValueAt(0, c).getClass();
>>             }
>>             public boolean isCellEditable(int row, int col) {
>>                 return col != 5;
>>             }
>>             public void setValueAt(Object aValue, int row, int column) {
>>                 data[row][column] = aValue;
>>             }
>>         };
>>         table.setModel(dataModel);
>>         TableRowSorter<TableModel> sorter = new 
>> TableRowSorter<TableModel>(
>>                 dataModel);
>>         table.setRowSorter(sorter);
>>
>>         JScrollPane scrollPane = new JScrollPane(table);
>>         add(scrollPane);
>>     }
>>
>>     public static void main(String[] args) throws Exception {
>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>             public void run() {
>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>
>>                 TableDemo newContentPane = new TableDemo();
>>                 newContentPane.setOpaque(true);
>>                 frame.setContentPane(newContentPane);
>>
>>                 frame.pack();
>>                 frame.setVisible(true);
>>             }
>>         });
>>     }
>> }
>>
>> To reproduce the problem,
>> please click on one cell from the "Number" column, delete all the 
>> content but do not press enter to quit editing status, then click the 
>> column title of "Number" column to sort, NPE will be thrown.
>>
>> The cause of this problem is when trying to quit editing with empty 
>> content of a cell  and also try to accept the partially edited value 
>> using stopCellEditing(), following two actions will be taken.
>> 1, the cellEditor of current table will be set to null.
>> 2, the value type of this column does not have a constructor to 
>> accept "Object[]" parameter, false will be returned.
>> Then swing will try to cancel edition without accepting the partially 
>> edited value using cancelCellEditing() which will get null for the 
>> value of cellEditor thus lead to this NPE.
>>
>> The patch is trying to return earlier before the type compatibility 
>> check of partially edited values when empty cell values encountered.
>>
>> Cheers!
>> - Jonathan
>>
>



From pavel.porvatov at oracle.com  Mon Apr 16 11:51:04 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 16 Apr 2012 15:51:04 +0400
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8BD09E.6020209@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com>
Message-ID: <4F8C07A8.7020509@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> Thanks for reviewing, here's the webrev patch and automatic test. 
> Could you please help to take another look?
> http://cr.openjdk.java.net/~luchsh/7055065/
The fix looks good. Could you please fix few minor changes:

1. Don't use full class names like javax.swing.SwingUtilities when 
possible. I didn't find such rule in our Code Conventions but we follow 
this rule.

2. Swap two lines please
   frame.setVisible(true);
   frame.setLocation(0, 0);
That's not critical for the test but we shouldn't provide bad examples

3. I've recently introduced the Util#invokeOnEDT method. It can simplify 
your test and the getHeaderClickPoint and getCellClickPoint methods can 
be removed.

Regards, Pavel
>
> Thanks & regards!
> - Jonathan
>
> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>
>> The fix looks good. Could you please write an automatic test, put it 
>> into an appropriate place of repository and make a webrev with fix 
>> and test?
>>
>> Regards, Pavel
>>> Hello swing-dev,
>>>
>>> I've got a patch for bug 7055065, can anybody please help to take a 
>>> look?
>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>
>>> And also a simple test case for this issue here.
>>>
>>> /*
>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>> reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>>  * under the terms of the GNU General Public License version 2 only, as
>>>  * published by the Free Software Foundation.
>>>  *
>>>  * This code is distributed in the hope that it will be useful, but 
>>> WITHOUT
>>>  * ANY WARRANTY; without even the implied warranty of 
>>> MERCHANTABILITY or
>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>> License
>>>  * version 2 for more details (a copy is included in the LICENSE 
>>> file that
>>>  * accompanied this code).
>>>  *
>>>  * You should have received a copy of the GNU General Public License 
>>> version
>>>  * 2 along with this work; if not, write to the Free Software 
>>> Foundation,
>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>  *
>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>> 94065 USA
>>>  * or visit www.oracle.com if you need additional information or 
>>> have any
>>>  * questions.
>>>  */
>>>
>>> /*
>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>  */
>>>
>>> import javax.swing.JFrame;
>>> import javax.swing.JPanel;
>>> import javax.swing.JScrollPane;
>>> import javax.swing.JTable;
>>> import javax.swing.table.AbstractTableModel;
>>> import javax.swing.table.TableModel;
>>> import javax.swing.table.TableRowSorter;
>>> import java.awt.Dimension;
>>> import java.awt.GridLayout;
>>>
>>> public class TableDemo extends JPanel {
>>>
>>>     public TableDemo() {
>>>         super(new GridLayout(1, 0));
>>>
>>>         final String[] columnNames = { "String", "Number" };
>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>                 { "bbbb", new Integer(3) }, { "cccc", new Integer(2) },
>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>> Integer(10) } };
>>>         final JTable table = new JTable(data, columnNames);
>>>
>>>         table.setPreferredScrollableViewportSize(new Dimension(500, 
>>> 400));
>>>         table.setFillsViewportHeight(true);
>>>         TableModel dataModel = new AbstractTableModel() {
>>>
>>>             public int getColumnCount() {
>>>                 return columnNames.length;
>>>             }
>>>             public int getRowCount() {
>>>                 return data.length;
>>>             }
>>>             public Object getValueAt(int row, int col) {
>>>                 return data[row][col];
>>>             }
>>>             public String getColumnName(int column) {
>>>                 return columnNames[column];
>>>             }
>>>             public Class<?> getColumnClass(int c) {
>>>                 return getValueAt(0, c).getClass();
>>>             }
>>>             public boolean isCellEditable(int row, int col) {
>>>                 return col != 5;
>>>             }
>>>             public void setValueAt(Object aValue, int row, int 
>>> column) {
>>>                 data[row][column] = aValue;
>>>             }
>>>         };
>>>         table.setModel(dataModel);
>>>         TableRowSorter<TableModel> sorter = new 
>>> TableRowSorter<TableModel>(
>>>                 dataModel);
>>>         table.setRowSorter(sorter);
>>>
>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>         add(scrollPane);
>>>     }
>>>
>>>     public static void main(String[] args) throws Exception {
>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>             public void run() {
>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>
>>>                 TableDemo newContentPane = new TableDemo();
>>>                 newContentPane.setOpaque(true);
>>>                 frame.setContentPane(newContentPane);
>>>
>>>                 frame.pack();
>>>                 frame.setVisible(true);
>>>             }
>>>         });
>>>     }
>>> }
>>>
>>> To reproduce the problem,
>>> please click on one cell from the "Number" column, delete all the 
>>> content but do not press enter to quit editing status, then click 
>>> the column title of "Number" column to sort, NPE will be thrown.
>>>
>>> The cause of this problem is when trying to quit editing with empty 
>>> content of a cell  and also try to accept the partially edited value 
>>> using stopCellEditing(), following two actions will be taken.
>>> 1, the cellEditor of current table will be set to null.
>>> 2, the value type of this column does not have a constructor to 
>>> accept "Object[]" parameter, false will be returned.
>>> Then swing will try to cancel edition without accepting the 
>>> partially edited value using cancelCellEditing() which will get null 
>>> for the value of cellEditor thus lead to this NPE.
>>>
>>> The patch is trying to return earlier before the type compatibility 
>>> check of partially edited values when empty cell values encountered.
>>>
>>> Cheers!
>>> - Jonathan
>>>
>>
>



From pavel.porvatov at oracle.com  Mon Apr 16 12:10:18 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 16 Apr 2012 16:10:18 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
	<CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
Message-ID: <4F8C0C2A.6040602@oracle.com>

Hi Sean

The fix looks good for me

Regards, Pavel

> Hi Pavel,
>
>     Modified and tested on windows and linux.
>
> webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.07/>
>
>
>
> On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>>     Hi Pavel,
>>
>>         I modified the testcase according to your comments. The
>>     webrev is http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.06/>  .
>>      Please take a look again.
>     And now when fastreturn is true the test doesn't stop.
>
>     Regards, Pavel
>
>>
>>     On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Sean,
>>
>>         The fix looks good, but I have several comments about the test:
>>         1. You shouldn't use Swing components on non-EDT threads, so
>>         frame.dispose() should be done on the EDT
>>
>>     I made a really stupid mistake... When I was checking the
>>     testcase and found frame.dispose() in main method, I added a
>>     volatile to the frame variable...
>>
>>         2. "These exceptions mean the implementation of XTextAreaPeer
>>         is changed" - I think is XTextAreaPeer is changed, then the
>>         test should be fixed as well or removed (if the test become
>>         inapplicable. Therefore in that situation the test should
>>         fail but not skipped
>>
>>         Regards, Pavel
>>
>>
>>>         Hi Pavel,
>>>
>>>             As awt team has committed the related
>>>         bug(http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b),
>>>         I prepared the webrev for this bug(7129742
>>>         <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>) again.
>>>
>>>
>>>             The new webrev:
>>>         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/
>>>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.05/>  .
>>>
>>>         The sunbug:
>>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
>>>         Previous discussion:
>>>         http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>>>
>>>
>>>             Please take a look once more, thank you.
>>>
>>>         On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov
>>>         <pavel.porvatov at oracle.com
>>>         <mailto:pavel.porvatov at oracle.com>> wrote:
>>>
>>>             Hi Sean,
>>>>
>>>>             Hi Pavel,
>>>>
>>>>                Thanks for your comments.
>>>>
>>>>             About the 1st question, I modified the testcase a
>>>>             little to demonstrate the problem, testcase is pasted
>>>>             at the end.
>>>>
>>>>             If textArea.setEditable(true) is executed, the frame
>>>>             disposes, but application doesn't exit.
>>>>             If textArea.setEditable(false), the application exits
>>>>             as normal.
>>>>
>>>>             java 1.7.0_01 and latest java8 code are tested.  And
>>>>             TextField contains this problem as well. I'll add it to
>>>>             fix later.
>>>>             Shall I report a separate bug for it ?
>>>             Yes. I think it will be better if you fix the described
>>>             above problem as a separate bug. Note that it should be
>>>             reviewed by the AWT team...
>>>
>>>>
>>>>
>>>>             About the 2nd question, I was driven by the comment "//
>>>>             TODO : fix this duplicate code". Is there any strong
>>>>             reason to keep it ?
>>>             I'm absolutely agree with removing duplicate code. My
>>>             second question was about added by you
>>>             "jtext.getCaret().setVisible(false)" in the
>>>             XTextAreaPeer.java class. I wrote:
>>>             2. Why don't we need the same code in the XTextFieldPeer
>>>             class?
>>>
>>>             As I can see you've noticed that XTextFieldPeer should
>>>             be fixed as well (in a separate fix with XTextAreaPeer)
>>>
>>>             Regards, Pavel
>>>
>>>>
>>>>
>>>>             ///////////////////////////////////  a testcase
>>>>              ////////////////////////////////////////////////////////////
>>>>             /*
>>>>              * Copyright (c) 2012 Oracle and/or its affiliates. All
>>>>             rights reserved.
>>>>              * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS
>>>>             FILE HEADER.
>>>>              *
>>>>              * This code is free software; you can redistribute it
>>>>             and/or modify it
>>>>              * under the terms of the GNU General Public License
>>>>             version 2 only, as
>>>>              * published by the Free Software Foundation.
>>>>              *
>>>>              * This code is distributed in the hope that it will be
>>>>             useful, but WITHOUT
>>>>              * ANY WARRANTY; without even the implied warranty of
>>>>             MERCHANTABILITY or
>>>>              * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>>             General Public License
>>>>              * version 2 for more details (a copy is included in
>>>>             the LICENSE file that
>>>>              * accompanied this code).
>>>>              *
>>>>              * You should have received a copy of the GNU General
>>>>             Public License version
>>>>              * 2 along with this work; if not, write to the Free
>>>>             Software Foundation,
>>>>              * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>>>>             02110-1301 USA.
>>>>              *
>>>>              * Please contact Oracle, 500 Oracle Parkway, Redwood
>>>>             Shores, CA 94065 USA
>>>>              * or visit www.oracle.com <http://www.oracle.com> if
>>>>             you need additional information or have any
>>>>              * questions.
>>>>              */
>>>>
>>>>             /*
>>>>              * Portions Copyright (c) 2012 IBM Corporation
>>>>              */
>>>>
>>>>             /* @test
>>>>              * @bug
>>>>              * @summary editable TextArea blocks gui app from dispose.
>>>>              * @author Sean Chou
>>>>              */
>>>>
>>>>             import java.awt.FlowLayout;
>>>>             import java.awt.Frame;
>>>>             import java.awt.TextArea;
>>>>             import java.awt.Toolkit;
>>>>             import java.lang.reflect.Field;
>>>>
>>>>             import javax.swing.JFrame;
>>>>             import javax.swing.JTextArea;
>>>>             import javax.swing.SwingUtilities;
>>>>             import javax.swing.text.DefaultCaret;
>>>>
>>>>             import sun.awt.SunToolkit;
>>>>
>>>>             public class TextAreaDisposeBug {
>>>>                 public static volatile boolean passed = false;
>>>>
>>>>                 public static Frame frame = null;
>>>>                 public static TextArea textArea = null;
>>>>
>>>>                 public static DefaultCaret caret = null;
>>>>                 public static Class XTextAreaPeerClzz = null;
>>>>
>>>>                 public static void main(String[] args) throws
>>>>             Exception {
>>>>                     SunToolkit toolkit = (SunToolkit)
>>>>             Toolkit.getDefaultToolkit();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame = new JFrame("Test");
>>>>                             textArea = new TextArea("editable
>>>>             textArea");
>>>>                             textArea.setEditable(true);
>>>>             //                textArea.setEditable(false);
>>>>
>>>>                             frame.setLayout(new FlowLayout());
>>>>                             frame.add(textArea);
>>>>
>>>>                             frame.pack();
>>>>                             frame.setVisible(true);
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame.dispose();
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                 }
>>>>
>>>>             }
>>>>
>>>>
>>>>             //////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>>             /*
>>>>              * Copyright (c) 2012 Oracle and/or its affiliates. All
>>>>             rights reserved.
>>>>              * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS
>>>>             FILE HEADER.
>>>>              *
>>>>              * This code is free software; you can redistribute it
>>>>             and/or modify it
>>>>              * under the terms of the GNU General Public License
>>>>             version 2 only, as
>>>>              * published by the Free Software Foundation.
>>>>              *
>>>>              * This code is distributed in the hope that it will be
>>>>             useful, but WITHOUT
>>>>              * ANY WARRANTY; without even the implied warranty of
>>>>             MERCHANTABILITY or
>>>>              * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>>             General Public License
>>>>              * version 2 for more details (a copy is included in
>>>>             the LICENSE file that
>>>>              * accompanied this code).
>>>>              *
>>>>              * You should have received a copy of the GNU General
>>>>             Public License version
>>>>              * 2 along with this work; if not, write to the Free
>>>>             Software Foundation,
>>>>              * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>>>>             02110-1301 USA.
>>>>              *
>>>>              * Please contact Oracle, 500 Oracle Parkway, Redwood
>>>>             Shores, CA 94065 USA
>>>>              * or visit www.oracle.com <http://www.oracle.com> if
>>>>             you need additional information or have any
>>>>              * questions.
>>>>              */
>>>>
>>>>             /*
>>>>              * Portions Copyright (c) 2012 IBM Corporation
>>>>              */
>>>>
>>>>
>>>>             /* @test
>>>>              * @bug
>>>>              * @summary editable TextField blocks gui app from dispose.
>>>>              * @author Sean Chou
>>>>              */
>>>>
>>>>             import java.awt.FlowLayout;
>>>>             import java.awt.Frame;
>>>>             import java.awt.TextField;
>>>>             import java.awt.Toolkit;
>>>>             import java.lang.reflect.Field;
>>>>
>>>>             import javax.swing.JFrame;
>>>>             import javax.swing.JTextArea;
>>>>             import javax.swing.SwingUtilities;
>>>>             import javax.swing.text.DefaultCaret;
>>>>
>>>>             import sun.awt.SunToolkit;
>>>>
>>>>             public class TextFieldDisposeBug {
>>>>                 public static volatile boolean passed = false;
>>>>
>>>>                 public static Frame frame = null;
>>>>                 public static TextField textField = null;
>>>>
>>>>                 public static DefaultCaret caret = null;
>>>>                 public static Class XTextAreaPeerClzz = null;
>>>>
>>>>                 public static void main(String[] args) throws
>>>>             Exception {
>>>>                     SunToolkit toolkit = (SunToolkit)
>>>>             Toolkit.getDefaultToolkit();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame = new JFrame("Test");
>>>>                             textField = new TextField("editable
>>>>             textArea");
>>>>             //                textField.setEditable(true);
>>>>                             textField.setEditable(false);
>>>>
>>>>                             frame.setLayout(new FlowLayout());
>>>>                             frame.add(textField);
>>>>
>>>>                             frame.pack();
>>>>                             frame.setVisible(true);
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame.dispose();
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                 }
>>>>
>>>>             }
>>>>
>>>>
>>>>             On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov
>>>>             <pavel.porvatov at oracle.com
>>>>             <mailto:pavel.porvatov at oracle.com>> wrote:
>>>>
>>>>                 Hi Sean,
>>>>
>>>>                 I have a couple questions about the following code
>>>>                 in the XTextAreaPeer.java class
>>>>                 +        // visible caret has a timer thread, which
>>>>                 must be stopped
>>>>                 +        jtext.getCaret().setVisible(false);
>>>>
>>>>                 1. Why this code wasn't needed before your fix,
>>>>                 when caret was visible for enabled text area?
>>>>                 2. Why don't we need the same code in the
>>>>                 XTextFieldPeer class?
>>>>
>>>>                 About the bug7129742 test:
>>>>                 Because of the passed field is used from different
>>>>                 threads you must use synchronization or mark the
>>>>                 field as a volatile.
>>>>
>>>>                 Regards, Pavel
>>>>
>>>>
>>>>>                 Hi Alexander,
>>>>>
>>>>>                     XTextFieldPeer and   XTextAreaPeer have a same
>>>>>                 inner class XAWTCaret, and in 
>>>>>                 XTextAreaPeer  there is also a comment:
>>>>>                 "// TODO : fix this duplicate code " 
>>>>>                  before XAWTCaret . So I removed the XAWTCaret
>>>>>                 in XTextFieldPeer and changed the
>>>>>                 XAWTCaret  into a static class,
>>>>>                 so XTextFieldPeer can
>>>>>                 use XAWTCaret from XTextAreaPeer  .
>>>>>
>>>>>                     As XAWTCaret is only used in the following
>>>>>                 method  in both XTextAreaPeer and  XTextFieldPeer .
>>>>>                 protected Caret createCaret() {
>>>>>                  return new XAWTCaret();
>>>>>                  }
>>>>>                     I think this modification should not bring
>>>>>                 side effect.
>>>>>
>>>>>                 On Mon, Mar 12, 2012 at 1:27 AM, Alexander
>>>>>                 Potochkin <Alexander.Potochkin at oracle.com
>>>>>                 <mailto:Alexander.Potochkin at oracle.com>> wrote:
>>>>>
>>>>>                     Hello Sean
>>>>>
>>>>>                     Could you give more details about your changes
>>>>>                     in XTextFieldPeer?
>>>>>
>>>>>                     Thanks
>>>>>                     alexp
>>>>>
>>>>>                         Hi all,
>>>>>
>>>>>                           I updated the patch to as suggested and
>>>>>                         simplified the testcase .
>>>>>                         Would anyone like to take a look again ?
>>>>>                         Thanks.
>>>>>
>>>>>                          The webrev is at :
>>>>>                         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/
>>>>>                         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>                         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>
>>>>>
>>>>>
>>>>>                          Previous discussion at :
>>>>>                         http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>>
>>>>>                         -- 
>>>>>                         Best Regards,
>>>>>                         Sean Chou
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Best Regards,
>>>>>                 Sean Chou
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Best Regards,
>>>>             Sean Chou
>>>>
>>>
>>>
>>>
>>>
>>>         -- 
>>>         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/20120416/1575cc6c/attachment.html>

From neugens.limasoftware at gmail.com  Mon Apr 16 12:13:39 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 16 Apr 2012 14:13:39 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4F79B601.8050905@oracle.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
Message-ID: <CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>

2012/4/2 Pavel Porvatov <pavel.porvatov at oracle.com>:
> Hi Mario,
>
> I'd suggest to change the javax.swing.JPopupMenu#getPopup method:
>
> ? ? ? ?if (isLightWeightPopupEnabled()) {
> ? ? ? ? ? ?popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
> ? ? ? ?}
> ? ? ? ?else {
> ? ? ? ? ? ?popupFactory.setPopupType(PopupFactory.HEAVY_WEIGHT_POPUP); //
> Replaced MEDIUM_WEIGHT_POPUP
> ? ? ? ?}
>
> I don't see any regressions, what do you think about that?
>
> Regards, Pavel
>

Hi Pavel!

Sorry for the delay, for some reason I didn't see this reply right away...

Yes, I was thinking something along the lines, since I doubt that LAF
really care about this specific property.

Would you like to commit this or do you want me to prepare a formal patch?

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From pavel.porvatov at oracle.com  Mon Apr 16 12:28:22 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 16 Apr 2012 16:28:22 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
	<CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
Message-ID: <4F8C1066.2080708@oracle.com>

Hi Mario,
> 2012/4/2 Pavel Porvatov<pavel.porvatov at oracle.com>:
>> Hi Mario,
>>
>> I'd suggest to change the javax.swing.JPopupMenu#getPopup method:
>>
>>         if (isLightWeightPopupEnabled()) {
>>             popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
>>         }
>>         else {
>>             popupFactory.setPopupType(PopupFactory.HEAVY_WEIGHT_POPUP); //
>> Replaced MEDIUM_WEIGHT_POPUP
>>         }
>>
>> I don't see any regressions, what do you think about that?
>>
>> Regards, Pavel
>>
> Hi Pavel!
>
> Sorry for the delay, for some reason I didn't see this reply right away...
>
> Yes, I was thinking something along the lines, since I doubt that LAF
> really care about this specific property.
Which property do you mean? If isLightWeightPopupEnabled property is set 
to false we can set HEAVY_WEIGHT_POPUP (I don't know reasons why we 
can't do that)
>
> Would you like to commit this or do you want me to prepare a formal patch?
I need a patch with a test of the fix. But at first you should read the 
following doc
http://openjdk.java.net/contribute/

Regards, Pavel


From pavel.porvatov at oracle.com  Mon Apr 16 14:18:09 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 16 Apr 2012 18:18:09 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
	<CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
Message-ID: <4F8C2A21.5010604@oracle.com>

Hi Mario,
> 2012/4/16 Pavel Porvatov<pavel.porvatov at oracle.com>:
>> Hi Mario,
> Hi Pavel,
>
>> Which property do you mean? If isLightWeightPopupEnabled property is set to
>> false we can set HEAVY_WEIGHT_POPUP (I don't know reasons why we can't do
>> that)
>>
>>> Would you like to commit this or do you want me to prepare a formal patch?
> I just meant to provide a fallback for the "old" MEDIUM_WEIGHT_POPUP
> code, but as I said I doubt is needed.
>
>> I need a patch with a test of the fix. But at first you should read the
>> following doc
>> http://openjdk.java.net/contribute/
> Yep, I'm familiar with this.
>
> Should I reuse this bug ID right?
Yes, I think in this situation that's possible
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6800513
>
> About the test, I'm not sure if you need something more specific, but
> I was thinking to simply test if when isLightWeightPopupEnabled is set
> we create an heavy or lightweight popup, any other ideas?
That's a good way I think

Regards, Pavel


From littlee at linux.vnet.ibm.com  Tue Apr 17 05:32:37 2012
From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com)
Date: Tue, 17 Apr 2012 05:32:37 +0000
Subject: <Swing Dev> hg: jdk8/swing/jdk: 7129742: Unable to view focus in
	Non-Editable	TextArea
Message-ID: <20120417053304.9727447112@hg.openjdk.java.net>

Changeset: 4828ffa1f5ee
Author:    zhouyx
Date:      2012-04-17 13:31 +0800
URL:       http://hg.openjdk.java.net/jdk8/swing/jdk/rev/4828ffa1f5ee

7129742: Unable to view focus in Non-Editable TextArea
Summary: Make sure the cursor is visible by setVisible(true)
Reviewed-by: rupashka, alexp

! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
+ test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java



From littlee at linux.vnet.ibm.com  Tue Apr 17 05:36:30 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Tue, 17 Apr 2012 13:36:30 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
	<CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
Message-ID: <4F8D015E.30004@linux.vnet.ibm.com>

On 04/16/2012 12:33 PM, Sean Chou wrote:
> Hi Pavel,
>
>     Modified and tested on windows and linux.
>
> webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.07/>
>
>
>
> On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>>     Hi Pavel,
>>
>>         I modified the testcase according to your comments. The
>>     webrev is http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.06/>  .
>>      Please take a look again.
>     And now when fastreturn is true the test doesn't stop.
>
>     Regards, Pavel
>
>>
>>     On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Sean,
>>
>>         The fix looks good, but I have several comments about the test:
>>         1. You shouldn't use Swing components on non-EDT threads, so
>>         frame.dispose() should be done on the EDT
>>
>>     I made a really stupid mistake... When I was checking the
>>     testcase and found frame.dispose() in main method, I added a
>>     volatile to the frame variable...
>>
>>         2. "These exceptions mean the implementation of XTextAreaPeer
>>         is changed" - I think is XTextAreaPeer is changed, then the
>>         test should be fixed as well or removed (if the test become
>>         inapplicable. Therefore in that situation the test should
>>         fail but not skipped
>>
>>         Regards, Pavel
>>
>>
>>>         Hi Pavel,
>>>
>>>             As awt team has committed the related
>>>         bug(http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b),
>>>         I prepared the webrev for this bug(7129742
>>>         <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>) again.
>>>
>>>
>>>             The new webrev:
>>>         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/
>>>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.05/>  .
>>>
>>>         The sunbug:
>>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
>>>         Previous discussion:
>>>         http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>>>
>>>
>>>             Please take a look once more, thank you.
>>>
>>>         On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov
>>>         <pavel.porvatov at oracle.com
>>>         <mailto:pavel.porvatov at oracle.com>> wrote:
>>>
>>>             Hi Sean,
>>>>
>>>>             Hi Pavel,
>>>>
>>>>                Thanks for your comments.
>>>>
>>>>             About the 1st question, I modified the testcase a
>>>>             little to demonstrate the problem, testcase is pasted
>>>>             at the end.
>>>>
>>>>             If textArea.setEditable(true) is executed, the frame
>>>>             disposes, but application doesn't exit.
>>>>             If textArea.setEditable(false), the application exits
>>>>             as normal.
>>>>
>>>>             java 1.7.0_01 and latest java8 code are tested.  And
>>>>             TextField contains this problem as well. I'll add it to
>>>>             fix later.
>>>>             Shall I report a separate bug for it ?
>>>             Yes. I think it will be better if you fix the described
>>>             above problem as a separate bug. Note that it should be
>>>             reviewed by the AWT team...
>>>
>>>>
>>>>
>>>>             About the 2nd question, I was driven by the comment "//
>>>>             TODO : fix this duplicate code". Is there any strong
>>>>             reason to keep it ?
>>>             I'm absolutely agree with removing duplicate code. My
>>>             second question was about added by you
>>>             "jtext.getCaret().setVisible(false)" in the
>>>             XTextAreaPeer.java class. I wrote:
>>>             2. Why don't we need the same code in the XTextFieldPeer
>>>             class?
>>>
>>>             As I can see you've noticed that XTextFieldPeer should
>>>             be fixed as well (in a separate fix with XTextAreaPeer)
>>>
>>>             Regards, Pavel
>>>
>>>>
>>>>
>>>>             ///////////////////////////////////  a testcase
>>>>              ////////////////////////////////////////////////////////////
>>>>             /*
>>>>              * Copyright (c) 2012 Oracle and/or its affiliates. All
>>>>             rights reserved.
>>>>              * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS
>>>>             FILE HEADER.
>>>>              *
>>>>              * This code is free software; you can redistribute it
>>>>             and/or modify it
>>>>              * under the terms of the GNU General Public License
>>>>             version 2 only, as
>>>>              * published by the Free Software Foundation.
>>>>              *
>>>>              * This code is distributed in the hope that it will be
>>>>             useful, but WITHOUT
>>>>              * ANY WARRANTY; without even the implied warranty of
>>>>             MERCHANTABILITY or
>>>>              * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>>             General Public License
>>>>              * version 2 for more details (a copy is included in
>>>>             the LICENSE file that
>>>>              * accompanied this code).
>>>>              *
>>>>              * You should have received a copy of the GNU General
>>>>             Public License version
>>>>              * 2 along with this work; if not, write to the Free
>>>>             Software Foundation,
>>>>              * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>>>>             02110-1301 USA.
>>>>              *
>>>>              * Please contact Oracle, 500 Oracle Parkway, Redwood
>>>>             Shores, CA 94065 USA
>>>>              * or visit www.oracle.com <http://www.oracle.com> if
>>>>             you need additional information or have any
>>>>              * questions.
>>>>              */
>>>>
>>>>             /*
>>>>              * Portions Copyright (c) 2012 IBM Corporation
>>>>              */
>>>>
>>>>             /* @test
>>>>              * @bug
>>>>              * @summary editable TextArea blocks gui app from dispose.
>>>>              * @author Sean Chou
>>>>              */
>>>>
>>>>             import java.awt.FlowLayout;
>>>>             import java.awt.Frame;
>>>>             import java.awt.TextArea;
>>>>             import java.awt.Toolkit;
>>>>             import java.lang.reflect.Field;
>>>>
>>>>             import javax.swing.JFrame;
>>>>             import javax.swing.JTextArea;
>>>>             import javax.swing.SwingUtilities;
>>>>             import javax.swing.text.DefaultCaret;
>>>>
>>>>             import sun.awt.SunToolkit;
>>>>
>>>>             public class TextAreaDisposeBug {
>>>>                 public static volatile boolean passed = false;
>>>>
>>>>                 public static Frame frame = null;
>>>>                 public static TextArea textArea = null;
>>>>
>>>>                 public static DefaultCaret caret = null;
>>>>                 public static Class XTextAreaPeerClzz = null;
>>>>
>>>>                 public static void main(String[] args) throws
>>>>             Exception {
>>>>                     SunToolkit toolkit = (SunToolkit)
>>>>             Toolkit.getDefaultToolkit();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame = new JFrame("Test");
>>>>                             textArea = new TextArea("editable
>>>>             textArea");
>>>>                             textArea.setEditable(true);
>>>>             //                textArea.setEditable(false);
>>>>
>>>>                             frame.setLayout(new FlowLayout());
>>>>                             frame.add(textArea);
>>>>
>>>>                             frame.pack();
>>>>                             frame.setVisible(true);
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame.dispose();
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                 }
>>>>
>>>>             }
>>>>
>>>>
>>>>             //////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>>             /*
>>>>              * Copyright (c) 2012 Oracle and/or its affiliates. All
>>>>             rights reserved.
>>>>              * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS
>>>>             FILE HEADER.
>>>>              *
>>>>              * This code is free software; you can redistribute it
>>>>             and/or modify it
>>>>              * under the terms of the GNU General Public License
>>>>             version 2 only, as
>>>>              * published by the Free Software Foundation.
>>>>              *
>>>>              * This code is distributed in the hope that it will be
>>>>             useful, but WITHOUT
>>>>              * ANY WARRANTY; without even the implied warranty of
>>>>             MERCHANTABILITY or
>>>>              * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>>             General Public License
>>>>              * version 2 for more details (a copy is included in
>>>>             the LICENSE file that
>>>>              * accompanied this code).
>>>>              *
>>>>              * You should have received a copy of the GNU General
>>>>             Public License version
>>>>              * 2 along with this work; if not, write to the Free
>>>>             Software Foundation,
>>>>              * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>>>>             02110-1301 USA.
>>>>              *
>>>>              * Please contact Oracle, 500 Oracle Parkway, Redwood
>>>>             Shores, CA 94065 USA
>>>>              * or visit www.oracle.com <http://www.oracle.com> if
>>>>             you need additional information or have any
>>>>              * questions.
>>>>              */
>>>>
>>>>             /*
>>>>              * Portions Copyright (c) 2012 IBM Corporation
>>>>              */
>>>>
>>>>
>>>>             /* @test
>>>>              * @bug
>>>>              * @summary editable TextField blocks gui app from dispose.
>>>>              * @author Sean Chou
>>>>              */
>>>>
>>>>             import java.awt.FlowLayout;
>>>>             import java.awt.Frame;
>>>>             import java.awt.TextField;
>>>>             import java.awt.Toolkit;
>>>>             import java.lang.reflect.Field;
>>>>
>>>>             import javax.swing.JFrame;
>>>>             import javax.swing.JTextArea;
>>>>             import javax.swing.SwingUtilities;
>>>>             import javax.swing.text.DefaultCaret;
>>>>
>>>>             import sun.awt.SunToolkit;
>>>>
>>>>             public class TextFieldDisposeBug {
>>>>                 public static volatile boolean passed = false;
>>>>
>>>>                 public static Frame frame = null;
>>>>                 public static TextField textField = null;
>>>>
>>>>                 public static DefaultCaret caret = null;
>>>>                 public static Class XTextAreaPeerClzz = null;
>>>>
>>>>                 public static void main(String[] args) throws
>>>>             Exception {
>>>>                     SunToolkit toolkit = (SunToolkit)
>>>>             Toolkit.getDefaultToolkit();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame = new JFrame("Test");
>>>>                             textField = new TextField("editable
>>>>             textArea");
>>>>             //                textField.setEditable(true);
>>>>                             textField.setEditable(false);
>>>>
>>>>                             frame.setLayout(new FlowLayout());
>>>>                             frame.add(textField);
>>>>
>>>>                             frame.pack();
>>>>                             frame.setVisible(true);
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                     SwingUtilities.invokeAndWait(new Runnable() {
>>>>                         @Override
>>>>                         public void run() {
>>>>                             frame.dispose();
>>>>                         }
>>>>                     });
>>>>                     toolkit.realSync();
>>>>                 }
>>>>
>>>>             }
>>>>
>>>>
>>>>             On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov
>>>>             <pavel.porvatov at oracle.com
>>>>             <mailto:pavel.porvatov at oracle.com>> wrote:
>>>>
>>>>                 Hi Sean,
>>>>
>>>>                 I have a couple questions about the following code
>>>>                 in the XTextAreaPeer.java class
>>>>                 +        // visible caret has a timer thread, which
>>>>                 must be stopped
>>>>                 +        jtext.getCaret().setVisible(false);
>>>>
>>>>                 1. Why this code wasn't needed before your fix,
>>>>                 when caret was visible for enabled text area?
>>>>                 2. Why don't we need the same code in the
>>>>                 XTextFieldPeer class?
>>>>
>>>>                 About the bug7129742 test:
>>>>                 Because of the passed field is used from different
>>>>                 threads you must use synchronization or mark the
>>>>                 field as a volatile.
>>>>
>>>>                 Regards, Pavel
>>>>
>>>>
>>>>>                 Hi Alexander,
>>>>>
>>>>>                     XTextFieldPeer and   XTextAreaPeer have a same
>>>>>                 inner class XAWTCaret, and in 
>>>>>                 XTextAreaPeer  there is also a comment:
>>>>>                 "// TODO : fix this duplicate code " 
>>>>>                  before XAWTCaret . So I removed the XAWTCaret
>>>>>                 in XTextFieldPeer and changed the
>>>>>                 XAWTCaret  into a static class,
>>>>>                 so XTextFieldPeer can
>>>>>                 use XAWTCaret from XTextAreaPeer  .
>>>>>
>>>>>                     As XAWTCaret is only used in the following
>>>>>                 method  in both XTextAreaPeer and  XTextFieldPeer .
>>>>>                 protected Caret createCaret() {
>>>>>                  return new XAWTCaret();
>>>>>                  }
>>>>>                     I think this modification should not bring
>>>>>                 side effect.
>>>>>
>>>>>                 On Mon, Mar 12, 2012 at 1:27 AM, Alexander
>>>>>                 Potochkin <Alexander.Potochkin at oracle.com
>>>>>                 <mailto:Alexander.Potochkin at oracle.com>> wrote:
>>>>>
>>>>>                     Hello Sean
>>>>>
>>>>>                     Could you give more details about your changes
>>>>>                     in XTextFieldPeer?
>>>>>
>>>>>                     Thanks
>>>>>                     alexp
>>>>>
>>>>>                         Hi all,
>>>>>
>>>>>                           I updated the patch to as suggested and
>>>>>                         simplified the testcase .
>>>>>                         Would anyone like to take a look again ?
>>>>>                         Thanks.
>>>>>
>>>>>                          The webrev is at :
>>>>>                         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/
>>>>>                         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>                         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>
>>>>>
>>>>>
>>>>>                          Previous discussion at :
>>>>>                         http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>>
>>>>>                         -- 
>>>>>                         Best Regards,
>>>>>                         Sean Chou
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Best Regards,
>>>>>                 Sean Chou
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Best Regards,
>>>>             Sean Chou
>>>>
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Best Regards,
>>>         Sean Chou
>>>
>>
>>
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>
Hi Sean,

The patch is committed @

Changeset: 4828ffa1f5ee
Author:    zhouyx
Date:      2012-04-17 13:31 +0800
URL:http://hg.openjdk.java.net/jdk8/swing/jdk/rev/4828ffa1f5ee

7129742: Unable to view focus in Non-Editable TextArea
Summary: Make sure the cursor is visible by setVisible(true)
Reviewed-by: rupashka, alexp


Please verify it and thanks all for reviewing the patch.

-- 
Yours Charles

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

From zhouyx at linux.vnet.ibm.com  Tue Apr 17 08:22:49 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 17 Apr 2012 16:22:49 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F8C0C2A.6040602@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
	<CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
	<4F8C0C2A.6040602@oracle.com>
Message-ID: <CAOo=rxUWa48mVvSs_oDZqQyfoDAO-A2T6YauXsOuiPRvUD5jqg@mail.gmail.com>

Hi Pavel,

    Thank you very much.

On Mon, Apr 16, 2012 at 8:10 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean
>
>
> The fix looks good for me
>
> Regards, Pavel
>
>
> Hi Pavel,
>
>      Modified and tested on windows and linux.
>
>  webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/
>
>
>
> On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov <pavel.porvatov at oracle.com
> > wrote:
>
>>  Hi Sean,
>>
>> Hi Pavel,
>>
>>      I modified the testcase according to your comments. The webrev is
>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/  .  Please take a
>> look again.
>>
>>  And now when fastreturn is true the test doesn't stop.
>>
>> Regards, Pavel
>>
>>
>> On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov <
>> pavel.porvatov at oracle.com> wrote:
>>
>>>  Hi Sean,
>>>
>>> The fix looks good, but I have several comments about the test:
>>> 1. You shouldn't use Swing components on non-EDT threads, so
>>> frame.dispose() should be done on the EDT
>>>
>> I made a really stupid mistake... When I was checking the testcase and
>> found frame.dispose() in main method, I added a volatile to the frame
>> variable...
>>
>>
>>>  2. "These exceptions mean the implementation of XTextAreaPeer is
>>> changed" - I think is XTextAreaPeer is changed, then the test should be
>>> fixed as well or removed (if the test become inapplicable. Therefore in
>>> that situation the test should fail but not skipped
>>>
>>> Regards, Pavel
>>>
>>>
>>>  Hi Pavel,
>>>
>>>      As awt team has committed the related bug(
>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I prepared
>>> the webrev for this bug(7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>)
>>> again.
>>>
>>>      The new webrev:
>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/  .
>>>
>>>  The sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
>>> Previous discussion:
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>>>
>>>      Please take a look once more, thank you.
>>>
>>> On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov <
>>> pavel.porvatov at oracle.com> wrote:
>>>
>>>>  Hi Sean,
>>>>
>>>>
>>>>  Hi Pavel,
>>>>
>>>>     Thanks for your comments.
>>>>
>>>>  About the 1st question, I modified the testcase a little to
>>>> demonstrate the problem, testcase is pasted at the end.
>>>>
>>>>  If textArea.setEditable(true) is executed, the frame disposes, but
>>>> application doesn't exit.
>>>> If textArea.setEditable(false), the application exits as normal.
>>>>
>>>>  java 1.7.0_01 and latest java8 code are tested.  And TextField
>>>> contains this problem as well. I'll add it to fix later.
>>>> Shall I report a separate bug for it ?
>>>>
>>>>  Yes. I think it will be better if you fix the described above problem
>>>> as a separate bug. Note that it should be reviewed by the AWT team...
>>>>
>>>>
>>>>
>>>>  About the 2nd question, I was driven by the comment "// TODO : fix
>>>> this duplicate code". Is there any strong reason to keep it ?
>>>>
>>>>  I'm absolutely agree with removing duplicate code. My second question
>>>> was about added by you "jtext.getCaret().setVisible(false)" in the
>>>> XTextAreaPeer.java class. I wrote:
>>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>>
>>>>  As I can see you've noticed that XTextFieldPeer should be fixed as
>>>> well (in a separate fix with XTextAreaPeer)
>>>>
>>>> Regards, Pavel
>>>>
>>>>
>>>>
>>>>  ///////////////////////////////////  a testcase
>>>>  ////////////////////////////////////////////////////////////
>>>>  /*
>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>  *
>>>>  * This code is free software; you can redistribute it and/or modify it
>>>>  * under the terms of the GNU General Public License version 2 only, as
>>>>  * published by the Free Software Foundation.
>>>>  *
>>>>  * This code is distributed in the hope that it will be useful, but
>>>> WITHOUT
>>>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>  * version 2 for more details (a copy is included in the LICENSE file
>>>> that
>>>>  * accompanied this code).
>>>>  *
>>>>   * You should have received a copy of the GNU General Public License
>>>> version
>>>>  * 2 along with this work; if not, write to the Free Software
>>>> Foundation,
>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>  *
>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065
>>>> USA
>>>>  * or visit www.oracle.com if you need additional information or have
>>>> any
>>>>   * questions.
>>>>  */
>>>>
>>>>  /*
>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>  */
>>>>
>>>>  /* @test
>>>>  * @bug
>>>>  * @summary editable TextArea blocks gui app from dispose.
>>>>  * @author Sean Chou
>>>>  */
>>>>
>>>>  import java.awt.FlowLayout;
>>>> import java.awt.Frame;
>>>> import java.awt.TextArea;
>>>> import java.awt.Toolkit;
>>>> import java.lang.reflect.Field;
>>>>
>>>>  import javax.swing.JFrame;
>>>> import javax.swing.JTextArea;
>>>> import javax.swing.SwingUtilities;
>>>> import javax.swing.text.DefaultCaret;
>>>>
>>>>  import sun.awt.SunToolkit;
>>>>
>>>>  public class TextAreaDisposeBug {
>>>>     public static volatile boolean passed = false;
>>>>
>>>>      public static Frame frame = null;
>>>>     public static TextArea textArea = null;
>>>>
>>>>      public static DefaultCaret caret = null;
>>>>     public static Class XTextAreaPeerClzz = null;
>>>>
>>>>      public static void main(String[] args) throws Exception {
>>>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame = new JFrame("Test");
>>>>
>>>>                 textArea = new TextArea("editable textArea");
>>>>                 textArea.setEditable(true);
>>>> //                textArea.setEditable(false);
>>>>
>>>>                  frame.setLayout(new FlowLayout());
>>>>                 frame.add(textArea);
>>>>
>>>>                  frame.pack();
>>>>                 frame.setVisible(true);
>>>>
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame.dispose();
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>     }
>>>>
>>>>  }
>>>>
>>>>
>>>>
>>>> //////////////////////////////////////////////////////////////////////////////////////////
>>>>  /*
>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>  *
>>>>  * This code is free software; you can redistribute it and/or modify it
>>>>  * under the terms of the GNU General Public License version 2 only, as
>>>>  * published by the Free Software Foundation.
>>>>  *
>>>>  * This code is distributed in the hope that it will be useful, but
>>>> WITHOUT
>>>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>  * version 2 for more details (a copy is included in the LICENSE file
>>>> that
>>>>  * accompanied this code).
>>>>  *
>>>>   * You should have received a copy of the GNU General Public License
>>>> version
>>>>  * 2 along with this work; if not, write to the Free Software
>>>> Foundation,
>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>  *
>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065
>>>> USA
>>>>  * or visit www.oracle.com if you need additional information or have
>>>> any
>>>>   * questions.
>>>>  */
>>>>
>>>>  /*
>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>  */
>>>>
>>>>
>>>>  /* @test
>>>>  * @bug
>>>>  * @summary editable TextField blocks gui app from dispose.
>>>>  * @author Sean Chou
>>>>  */
>>>>
>>>>  import java.awt.FlowLayout;
>>>> import java.awt.Frame;
>>>> import java.awt.TextField;
>>>> import java.awt.Toolkit;
>>>> import java.lang.reflect.Field;
>>>>
>>>>  import javax.swing.JFrame;
>>>> import javax.swing.JTextArea;
>>>> import javax.swing.SwingUtilities;
>>>> import javax.swing.text.DefaultCaret;
>>>>
>>>>  import sun.awt.SunToolkit;
>>>>
>>>>  public class TextFieldDisposeBug {
>>>>     public static volatile boolean passed = false;
>>>>
>>>>      public static Frame frame = null;
>>>>     public static TextField textField = null;
>>>>
>>>>      public static DefaultCaret caret = null;
>>>>     public static Class XTextAreaPeerClzz = null;
>>>>
>>>>      public static void main(String[] args) throws Exception {
>>>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame = new JFrame("Test");
>>>>
>>>>                 textField = new TextField("editable textArea");
>>>> //                textField.setEditable(true);
>>>>                 textField.setEditable(false);
>>>>
>>>>                  frame.setLayout(new FlowLayout());
>>>>                 frame.add(textField);
>>>>
>>>>                  frame.pack();
>>>>                 frame.setVisible(true);
>>>>
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame.dispose();
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>     }
>>>>
>>>>  }
>>>>
>>>>
>>>>  On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov <
>>>> pavel.porvatov at oracle.com> wrote:
>>>>
>>>>>  Hi Sean,
>>>>>
>>>>> I have a couple questions about the following code in the
>>>>> XTextAreaPeer.java class
>>>>> +        // visible caret has a timer thread, which must be stopped
>>>>> +        jtext.getCaret().setVisible(false);
>>>>>
>>>>> 1. Why this code wasn't needed before your fix, when caret was visible
>>>>> for enabled text area?
>>>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>>>
>>>>> About the bug7129742 test:
>>>>> Because of the passed field is used from different threads you must
>>>>> use synchronization or mark the field as a volatile.
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>>
>>>>> Hi Alexander,
>>>>>
>>>>>      XTextFieldPeer and   XTextAreaPeer have a same inner
>>>>> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
>>>>> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
>>>>> the XAWTCaret in XTextFieldPeer and changed the
>>>>> XAWTCaret  into a static class, so XTextFieldPeer can
>>>>> use XAWTCaret from XTextAreaPeer  .
>>>>>
>>>>>      As XAWTCaret is only used in the following
>>>>> method  in both XTextAreaPeer and  XTextFieldPeer .
>>>>> protected Caret createCaret() {
>>>>>  return new XAWTCaret();
>>>>>  }
>>>>>      I think this modification should not bring side effect.
>>>>>
>>>>>  On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
>>>>> Alexander.Potochkin at oracle.com> wrote:
>>>>>
>>>>>> Hello Sean
>>>>>>
>>>>>> Could you give more details about your changes in XTextFieldPeer?
>>>>>>
>>>>>> Thanks
>>>>>> alexp
>>>>>>
>>>>>>  Hi all,
>>>>>>>
>>>>>>>   I updated the patch to as suggested and simplified the testcase .
>>>>>>> Would anyone like to take a look again ? Thanks.
>>>>>>>
>>>>>>>   The webrev is at :
>>>>>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <
>>>>>>> http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>>>
>>>>>>>
>>>>>>>  Previous discussion at :
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>> Sean Chou
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Best Regards,
>>>>> Sean Chou
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>>>
>>
>>
>>  --
>> 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/20120417/85e540e1/attachment.html>

From zhouyx at linux.vnet.ibm.com  Tue Apr 17 08:23:14 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 17 Apr 2012 16:23:14 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F8D015E.30004@linux.vnet.ibm.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
	<CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
	<4F8D015E.30004@linux.vnet.ibm.com>
Message-ID: <CAOo=rxXDqo=t+Ci98ceu-LZM7RwxHqHQixkLCt0XU0hQR_4C0Q@mail.gmail.com>

Hi Charles,

    Verified, thank you.

On Tue, Apr 17, 2012 at 1:36 PM, Charles Lee <littlee at linux.vnet.ibm.com>wrote:

> **
> On 04/16/2012 12:33 PM, Sean Chou wrote:
>
> Hi Pavel,
>
>      Modified and tested on windows and linux.
>
>  webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/
>
>
>
> On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov <pavel.porvatov at oracle.com
> > wrote:
>
>>  Hi Sean,
>>
>> Hi Pavel,
>>
>>      I modified the testcase according to your comments. The webrev is
>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/  .  Please take a
>> look again.
>>
>>  And now when fastreturn is true the test doesn't stop.
>>
>> Regards, Pavel
>>
>>
>> On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov <
>> pavel.porvatov at oracle.com> wrote:
>>
>>>  Hi Sean,
>>>
>>> The fix looks good, but I have several comments about the test:
>>> 1. You shouldn't use Swing components on non-EDT threads, so
>>> frame.dispose() should be done on the EDT
>>>
>> I made a really stupid mistake... When I was checking the testcase and
>> found frame.dispose() in main method, I added a volatile to the frame
>> variable...
>>
>>
>>>  2. "These exceptions mean the implementation of XTextAreaPeer is
>>> changed" - I think is XTextAreaPeer is changed, then the test should be
>>> fixed as well or removed (if the test become inapplicable. Therefore in
>>> that situation the test should fail but not skipped
>>>
>>> Regards, Pavel
>>>
>>>
>>>  Hi Pavel,
>>>
>>>      As awt team has committed the related bug(
>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b), I prepared
>>> the webrev for this bug(7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>)
>>> again.
>>>
>>>      The new webrev:
>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.05/  .
>>>
>>>  The sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742
>>> Previous discussion:
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-March/001923.html
>>>
>>>      Please take a look once more, thank you.
>>>
>>> On Thu, Mar 15, 2012 at 8:57 PM, Pavel Porvatov <
>>> pavel.porvatov at oracle.com> wrote:
>>>
>>>>  Hi Sean,
>>>>
>>>>
>>>>  Hi Pavel,
>>>>
>>>>     Thanks for your comments.
>>>>
>>>>  About the 1st question, I modified the testcase a little to
>>>> demonstrate the problem, testcase is pasted at the end.
>>>>
>>>>  If textArea.setEditable(true) is executed, the frame disposes, but
>>>> application doesn't exit.
>>>> If textArea.setEditable(false), the application exits as normal.
>>>>
>>>>  java 1.7.0_01 and latest java8 code are tested.  And TextField
>>>> contains this problem as well. I'll add it to fix later.
>>>> Shall I report a separate bug for it ?
>>>>
>>>>  Yes. I think it will be better if you fix the described above problem
>>>> as a separate bug. Note that it should be reviewed by the AWT team...
>>>>
>>>>
>>>>
>>>>  About the 2nd question, I was driven by the comment "// TODO : fix
>>>> this duplicate code". Is there any strong reason to keep it ?
>>>>
>>>>  I'm absolutely agree with removing duplicate code. My second question
>>>> was about added by you "jtext.getCaret().setVisible(false)" in the
>>>> XTextAreaPeer.java class. I wrote:
>>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>>
>>>>  As I can see you've noticed that XTextFieldPeer should be fixed as
>>>> well (in a separate fix with XTextAreaPeer)
>>>>
>>>> Regards, Pavel
>>>>
>>>>
>>>>
>>>>  ///////////////////////////////////  a testcase
>>>>  ////////////////////////////////////////////////////////////
>>>>  /*
>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>  *
>>>>  * This code is free software; you can redistribute it and/or modify it
>>>>  * under the terms of the GNU General Public License version 2 only, as
>>>>  * published by the Free Software Foundation.
>>>>  *
>>>>  * This code is distributed in the hope that it will be useful, but
>>>> WITHOUT
>>>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>  * version 2 for more details (a copy is included in the LICENSE file
>>>> that
>>>>  * accompanied this code).
>>>>  *
>>>>   * You should have received a copy of the GNU General Public License
>>>> version
>>>>  * 2 along with this work; if not, write to the Free Software
>>>> Foundation,
>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>  *
>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065
>>>> USA
>>>>  * or visit www.oracle.com if you need additional information or have
>>>> any
>>>>   * questions.
>>>>  */
>>>>
>>>>  /*
>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>  */
>>>>
>>>>  /* @test
>>>>  * @bug
>>>>  * @summary editable TextArea blocks gui app from dispose.
>>>>  * @author Sean Chou
>>>>  */
>>>>
>>>>  import java.awt.FlowLayout;
>>>> import java.awt.Frame;
>>>> import java.awt.TextArea;
>>>> import java.awt.Toolkit;
>>>> import java.lang.reflect.Field;
>>>>
>>>>  import javax.swing.JFrame;
>>>> import javax.swing.JTextArea;
>>>> import javax.swing.SwingUtilities;
>>>> import javax.swing.text.DefaultCaret;
>>>>
>>>>  import sun.awt.SunToolkit;
>>>>
>>>>  public class TextAreaDisposeBug {
>>>>     public static volatile boolean passed = false;
>>>>
>>>>      public static Frame frame = null;
>>>>     public static TextArea textArea = null;
>>>>
>>>>      public static DefaultCaret caret = null;
>>>>     public static Class XTextAreaPeerClzz = null;
>>>>
>>>>      public static void main(String[] args) throws Exception {
>>>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame = new JFrame("Test");
>>>>
>>>>                 textArea = new TextArea("editable textArea");
>>>>                 textArea.setEditable(true);
>>>> //                textArea.setEditable(false);
>>>>
>>>>                  frame.setLayout(new FlowLayout());
>>>>                 frame.add(textArea);
>>>>
>>>>                  frame.pack();
>>>>                 frame.setVisible(true);
>>>>
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame.dispose();
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>     }
>>>>
>>>>  }
>>>>
>>>>
>>>>
>>>> //////////////////////////////////////////////////////////////////////////////////////////
>>>>  /*
>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>  *
>>>>  * This code is free software; you can redistribute it and/or modify it
>>>>  * under the terms of the GNU General Public License version 2 only, as
>>>>  * published by the Free Software Foundation.
>>>>  *
>>>>  * This code is distributed in the hope that it will be useful, but
>>>> WITHOUT
>>>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>  * version 2 for more details (a copy is included in the LICENSE file
>>>> that
>>>>  * accompanied this code).
>>>>  *
>>>>   * You should have received a copy of the GNU General Public License
>>>> version
>>>>  * 2 along with this work; if not, write to the Free Software
>>>> Foundation,
>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>  *
>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065
>>>> USA
>>>>  * or visit www.oracle.com if you need additional information or have
>>>> any
>>>>   * questions.
>>>>  */
>>>>
>>>>  /*
>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>  */
>>>>
>>>>
>>>>  /* @test
>>>>  * @bug
>>>>  * @summary editable TextField blocks gui app from dispose.
>>>>  * @author Sean Chou
>>>>  */
>>>>
>>>>  import java.awt.FlowLayout;
>>>> import java.awt.Frame;
>>>> import java.awt.TextField;
>>>> import java.awt.Toolkit;
>>>> import java.lang.reflect.Field;
>>>>
>>>>  import javax.swing.JFrame;
>>>> import javax.swing.JTextArea;
>>>> import javax.swing.SwingUtilities;
>>>> import javax.swing.text.DefaultCaret;
>>>>
>>>>  import sun.awt.SunToolkit;
>>>>
>>>>  public class TextFieldDisposeBug {
>>>>     public static volatile boolean passed = false;
>>>>
>>>>      public static Frame frame = null;
>>>>     public static TextField textField = null;
>>>>
>>>>      public static DefaultCaret caret = null;
>>>>     public static Class XTextAreaPeerClzz = null;
>>>>
>>>>      public static void main(String[] args) throws Exception {
>>>>          SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame = new JFrame("Test");
>>>>
>>>>                 textField = new TextField("editable textArea");
>>>> //                textField.setEditable(true);
>>>>                 textField.setEditable(false);
>>>>
>>>>                  frame.setLayout(new FlowLayout());
>>>>                 frame.add(textField);
>>>>
>>>>                  frame.pack();
>>>>                 frame.setVisible(true);
>>>>
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>
>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>             @Override
>>>>             public void run() {
>>>>                 frame.dispose();
>>>>             }
>>>>         });
>>>>         toolkit.realSync();
>>>>     }
>>>>
>>>>  }
>>>>
>>>>
>>>>  On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov <
>>>> pavel.porvatov at oracle.com> wrote:
>>>>
>>>>>  Hi Sean,
>>>>>
>>>>> I have a couple questions about the following code in the
>>>>> XTextAreaPeer.java class
>>>>> +        // visible caret has a timer thread, which must be stopped
>>>>> +        jtext.getCaret().setVisible(false);
>>>>>
>>>>> 1. Why this code wasn't needed before your fix, when caret was visible
>>>>> for enabled text area?
>>>>> 2. Why don't we need the same code in the XTextFieldPeer class?
>>>>>
>>>>> About the bug7129742 test:
>>>>> Because of the passed field is used from different threads you must
>>>>> use synchronization or mark the field as a volatile.
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>>
>>>>> Hi Alexander,
>>>>>
>>>>>      XTextFieldPeer and   XTextAreaPeer have a same inner
>>>>> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
>>>>> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
>>>>> the XAWTCaret in XTextFieldPeer and changed the
>>>>> XAWTCaret  into a static class, so XTextFieldPeer can
>>>>> use XAWTCaret from XTextAreaPeer  .
>>>>>
>>>>>      As XAWTCaret is only used in the following
>>>>> method  in both XTextAreaPeer and  XTextFieldPeer .
>>>>> protected Caret createCaret() {
>>>>>  return new XAWTCaret();
>>>>>  }
>>>>>      I think this modification should not bring side effect.
>>>>>
>>>>>  On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
>>>>> Alexander.Potochkin at oracle.com> wrote:
>>>>>
>>>>>> Hello Sean
>>>>>>
>>>>>> Could you give more details about your changes in XTextFieldPeer?
>>>>>>
>>>>>> Thanks
>>>>>> alexp
>>>>>>
>>>>>>  Hi all,
>>>>>>>
>>>>>>>   I updated the patch to as suggested and simplified the testcase .
>>>>>>> Would anyone like to take a look again ? Thanks.
>>>>>>>
>>>>>>>   The webrev is at :
>>>>>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <
>>>>>>> http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>>>>>
>>>>>>>
>>>>>>>  Previous discussion at :
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>> Sean Chou
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Best Regards,
>>>>> Sean Chou
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>>>
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>  Hi Sean,
>
> The patch is committed @
>
> Changeset: 4828ffa1f5ee
> Author:    zhouyx
> Date:      2012-04-17 13:31 +0800
> URL:       http://hg.openjdk.java.net/jdk8/swing/jdk/rev/4828ffa1f5ee
>
> 7129742: Unable to view focus in Non-Editable TextArea
> Summary: Make sure the cursor is visible by setVisible(true)
> Reviewed-by: rupashka, alexp
>
>
> Please verify it and thanks all for reviewing the patch.
>
> --
> Yours Charles
>
>


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

From neugens.limasoftware at gmail.com  Tue Apr 17 14:59:15 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Tue, 17 Apr 2012 16:59:15 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4F8C2A21.5010604@oracle.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
	<CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
Message-ID: <CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>

2012/4/16 Pavel Porvatov <pavel.porvatov at oracle.com>:

Hello Pavel,

>> About the test, I'm not sure if you need something more specific, but
>> I was thinking to simply test if when isLightWeightPopupEnabled is set
>> we create an heavy or lightweight popup, any other ideas?
>
> That's a good way I think

Here is the webrev:

http://cr.openjdk.java.net/~neugens/6800513/

Note that MEDIUM_WEIGHT is still used in some cases (PopupFactory.getPopup):

        if (owner == null || invokerInHeavyWeightPopup(owner)) {
            popupType = HEAVY_WEIGHT_POPUP;
        }
        else if (popupType == LIGHT_WEIGHT_POPUP &&
                 !(contents instanceof JToolTip) &&
                 !(contents instanceof JPopupMenu)) {
            popupType = MEDIUM_WEIGHT_POPUP;
        }

I'm not sure if we want to replace this as well with full HW (I would
do it, in fact).

Also I was thinking to have a very small optimization, if we are using
an HW popups, there's no need to do this check:

        // Check if the parent component is an option pane.  If so we need to
        // force a heavy weight popup in order to have event dispatching work
        // correctly.
        Component c = owner;
        while (c != null) {
            if (c instanceof JComponent) {
                if (((JComponent)c).getClientProperty(
                            PopupFactory_FORCE_HEAVYWEIGHT_POPUP) ==
Boolean.TRUE) {
                    popupType = HEAVY_WEIGHT_POPUP;
                    break;
                }
            } else if (c instanceof Window) {
                Window w = (Window) c;
                if (!w.isOpaque() || w.getOpacity() < 1 ||
w.getShape() != null) {
                    popupType = HEAVY_WEIGHT_POPUP;
                    break;
                }
            }
            c = c.getParent();
        }

We can save a loop and a couple of instanceof checks (although I
remember we proved with Jim and Phil that instanceof don't really
introduce any speed penalization).

What do you think?

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From luchsh at linux.vnet.ibm.com  Thu Apr 19 03:24:42 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 19 Apr 2012 11:24:42 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8C07A8.7020509@oracle.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
Message-ID: <4F8F857A.4090007@linux.vnet.ibm.com>

Hi Pavel,

After a simple grep, I did not see any invokeOnEDT method from swing or 
2d repository, has it been committed yet?

Thanks and best regards!
- Jonathan

On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Pavel,
>>
>> Thanks for reviewing, here's the webrev patch and automatic test. 
>> Could you please help to take another look?
>> http://cr.openjdk.java.net/~luchsh/7055065/
> The fix looks good. Could you please fix few minor changes:
>
> 1. Don't use full class names like javax.swing.SwingUtilities when 
> possible. I didn't find such rule in our Code Conventions but we 
> follow this rule.
>
> 2. Swap two lines please
>   frame.setVisible(true);
>   frame.setLocation(0, 0);
> That's not critical for the test but we shouldn't provide bad examples
>
> 3. I've recently introduced the Util#invokeOnEDT method. It can 
> simplify your test and the getHeaderClickPoint and getCellClickPoint 
> methods can be removed.
>
> Regards, Pavel
>>
>> Thanks & regards!
>> - Jonathan
>>
>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>
>>> The fix looks good. Could you please write an automatic test, put it 
>>> into an appropriate place of repository and make a webrev with fix 
>>> and test?
>>>
>>> Regards, Pavel
>>>> Hello swing-dev,
>>>>
>>>> I've got a patch for bug 7055065, can anybody please help to take a 
>>>> look?
>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>>
>>>> And also a simple test case for this issue here.
>>>>
>>>> /*
>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>>> reserved.
>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>  *
>>>>  * This code is free software; you can redistribute it and/or 
>>>> modify it
>>>>  * under the terms of the GNU General Public License version 2 
>>>> only, as
>>>>  * published by the Free Software Foundation.
>>>>  *
>>>>  * This code is distributed in the hope that it will be useful, but 
>>>> WITHOUT
>>>>  * ANY WARRANTY; without even the implied warranty of 
>>>> MERCHANTABILITY or
>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>>> License
>>>>  * version 2 for more details (a copy is included in the LICENSE 
>>>> file that
>>>>  * accompanied this code).
>>>>  *
>>>>  * You should have received a copy of the GNU General Public 
>>>> License version
>>>>  * 2 along with this work; if not, write to the Free Software 
>>>> Foundation,
>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>  *
>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>>> 94065 USA
>>>>  * or visit www.oracle.com if you need additional information or 
>>>> have any
>>>>  * questions.
>>>>  */
>>>>
>>>> /*
>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>  */
>>>>
>>>> import javax.swing.JFrame;
>>>> import javax.swing.JPanel;
>>>> import javax.swing.JScrollPane;
>>>> import javax.swing.JTable;
>>>> import javax.swing.table.AbstractTableModel;
>>>> import javax.swing.table.TableModel;
>>>> import javax.swing.table.TableRowSorter;
>>>> import java.awt.Dimension;
>>>> import java.awt.GridLayout;
>>>>
>>>> public class TableDemo extends JPanel {
>>>>
>>>>     public TableDemo() {
>>>>         super(new GridLayout(1, 0));
>>>>
>>>>         final String[] columnNames = { "String", "Number" };
>>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>>                 { "bbbb", new Integer(3) }, { "cccc", new 
>>>> Integer(2) },
>>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>>> Integer(10) } };
>>>>         final JTable table = new JTable(data, columnNames);
>>>>
>>>>         table.setPreferredScrollableViewportSize(new Dimension(500, 
>>>> 400));
>>>>         table.setFillsViewportHeight(true);
>>>>         TableModel dataModel = new AbstractTableModel() {
>>>>
>>>>             public int getColumnCount() {
>>>>                 return columnNames.length;
>>>>             }
>>>>             public int getRowCount() {
>>>>                 return data.length;
>>>>             }
>>>>             public Object getValueAt(int row, int col) {
>>>>                 return data[row][col];
>>>>             }
>>>>             public String getColumnName(int column) {
>>>>                 return columnNames[column];
>>>>             }
>>>>             public Class<?> getColumnClass(int c) {
>>>>                 return getValueAt(0, c).getClass();
>>>>             }
>>>>             public boolean isCellEditable(int row, int col) {
>>>>                 return col != 5;
>>>>             }
>>>>             public void setValueAt(Object aValue, int row, int 
>>>> column) {
>>>>                 data[row][column] = aValue;
>>>>             }
>>>>         };
>>>>         table.setModel(dataModel);
>>>>         TableRowSorter<TableModel> sorter = new 
>>>> TableRowSorter<TableModel>(
>>>>                 dataModel);
>>>>         table.setRowSorter(sorter);
>>>>
>>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>>         add(scrollPane);
>>>>     }
>>>>
>>>>     public static void main(String[] args) throws Exception {
>>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>>             public void run() {
>>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>
>>>>                 TableDemo newContentPane = new TableDemo();
>>>>                 newContentPane.setOpaque(true);
>>>>                 frame.setContentPane(newContentPane);
>>>>
>>>>                 frame.pack();
>>>>                 frame.setVisible(true);
>>>>             }
>>>>         });
>>>>     }
>>>> }
>>>>
>>>> To reproduce the problem,
>>>> please click on one cell from the "Number" column, delete all the 
>>>> content but do not press enter to quit editing status, then click 
>>>> the column title of "Number" column to sort, NPE will be thrown.
>>>>
>>>> The cause of this problem is when trying to quit editing with empty 
>>>> content of a cell  and also try to accept the partially edited 
>>>> value using stopCellEditing(), following two actions will be taken.
>>>> 1, the cellEditor of current table will be set to null.
>>>> 2, the value type of this column does not have a constructor to 
>>>> accept "Object[]" parameter, false will be returned.
>>>> Then swing will try to cancel edition without accepting the 
>>>> partially edited value using cancelCellEditing() which will get 
>>>> null for the value of cellEditor thus lead to this NPE.
>>>>
>>>> The patch is trying to return earlier before the type compatibility 
>>>> check of partially edited values when empty cell values encountered.
>>>>
>>>> Cheers!
>>>> - Jonathan
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Thu Apr 19 09:58:14 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 19 Apr 2012 13:58:14 +0400
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8F857A.4090007@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com>
Message-ID: <4F8FE1B6.3020808@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> After a simple grep, I did not see any invokeOnEDT method from swing 
> or 2d repository, has it been committed yet?
That's because you are using incorrect  repository. See here:
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8fe9b93e2474

Swing and AWT teams use awt repository.

Regards, Pavel
>
> Thanks and best regards!
> - Jonathan
>
> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> Thanks for reviewing, here's the webrev patch and automatic test. 
>>> Could you please help to take another look?
>>> http://cr.openjdk.java.net/~luchsh/7055065/
>> The fix looks good. Could you please fix few minor changes:
>>
>> 1. Don't use full class names like javax.swing.SwingUtilities when 
>> possible. I didn't find such rule in our Code Conventions but we 
>> follow this rule.
>>
>> 2. Swap two lines please
>>   frame.setVisible(true);
>>   frame.setLocation(0, 0);
>> That's not critical for the test but we shouldn't provide bad examples
>>
>> 3. I've recently introduced the Util#invokeOnEDT method. It can 
>> simplify your test and the getHeaderClickPoint and getCellClickPoint 
>> methods can be removed.
>>
>> Regards, Pavel
>>>
>>> Thanks & regards!
>>> - Jonathan
>>>
>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>
>>>> The fix looks good. Could you please write an automatic test, put 
>>>> it into an appropriate place of repository and make a webrev with 
>>>> fix and test?
>>>>
>>>> Regards, Pavel
>>>>> Hello swing-dev,
>>>>>
>>>>> I've got a patch for bug 7055065, can anybody please help to take 
>>>>> a look?
>>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>>>
>>>>> And also a simple test case for this issue here.
>>>>>
>>>>> /*
>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>>>> reserved.
>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>  *
>>>>>  * This code is free software; you can redistribute it and/or 
>>>>> modify it
>>>>>  * under the terms of the GNU General Public License version 2 
>>>>> only, as
>>>>>  * published by the Free Software Foundation.
>>>>>  *
>>>>>  * This code is distributed in the hope that it will be useful, 
>>>>> but WITHOUT
>>>>>  * ANY WARRANTY; without even the implied warranty of 
>>>>> MERCHANTABILITY or
>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>>>> License
>>>>>  * version 2 for more details (a copy is included in the LICENSE 
>>>>> file that
>>>>>  * accompanied this code).
>>>>>  *
>>>>>  * You should have received a copy of the GNU General Public 
>>>>> License version
>>>>>  * 2 along with this work; if not, write to the Free Software 
>>>>> Foundation,
>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>  *
>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>>>> 94065 USA
>>>>>  * or visit www.oracle.com if you need additional information or 
>>>>> have any
>>>>>  * questions.
>>>>>  */
>>>>>
>>>>> /*
>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>  */
>>>>>
>>>>> import javax.swing.JFrame;
>>>>> import javax.swing.JPanel;
>>>>> import javax.swing.JScrollPane;
>>>>> import javax.swing.JTable;
>>>>> import javax.swing.table.AbstractTableModel;
>>>>> import javax.swing.table.TableModel;
>>>>> import javax.swing.table.TableRowSorter;
>>>>> import java.awt.Dimension;
>>>>> import java.awt.GridLayout;
>>>>>
>>>>> public class TableDemo extends JPanel {
>>>>>
>>>>>     public TableDemo() {
>>>>>         super(new GridLayout(1, 0));
>>>>>
>>>>>         final String[] columnNames = { "String", "Number" };
>>>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>                 { "bbbb", new Integer(3) }, { "cccc", new 
>>>>> Integer(2) },
>>>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>>>> Integer(10) } };
>>>>>         final JTable table = new JTable(data, columnNames);
>>>>>
>>>>>         table.setPreferredScrollableViewportSize(new 
>>>>> Dimension(500, 400));
>>>>>         table.setFillsViewportHeight(true);
>>>>>         TableModel dataModel = new AbstractTableModel() {
>>>>>
>>>>>             public int getColumnCount() {
>>>>>                 return columnNames.length;
>>>>>             }
>>>>>             public int getRowCount() {
>>>>>                 return data.length;
>>>>>             }
>>>>>             public Object getValueAt(int row, int col) {
>>>>>                 return data[row][col];
>>>>>             }
>>>>>             public String getColumnName(int column) {
>>>>>                 return columnNames[column];
>>>>>             }
>>>>>             public Class<?> getColumnClass(int c) {
>>>>>                 return getValueAt(0, c).getClass();
>>>>>             }
>>>>>             public boolean isCellEditable(int row, int col) {
>>>>>                 return col != 5;
>>>>>             }
>>>>>             public void setValueAt(Object aValue, int row, int 
>>>>> column) {
>>>>>                 data[row][column] = aValue;
>>>>>             }
>>>>>         };
>>>>>         table.setModel(dataModel);
>>>>>         TableRowSorter<TableModel> sorter = new 
>>>>> TableRowSorter<TableModel>(
>>>>>                 dataModel);
>>>>>         table.setRowSorter(sorter);
>>>>>
>>>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>>>         add(scrollPane);
>>>>>     }
>>>>>
>>>>>     public static void main(String[] args) throws Exception {
>>>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>>>             public void run() {
>>>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>>>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>
>>>>>                 TableDemo newContentPane = new TableDemo();
>>>>>                 newContentPane.setOpaque(true);
>>>>>                 frame.setContentPane(newContentPane);
>>>>>
>>>>>                 frame.pack();
>>>>>                 frame.setVisible(true);
>>>>>             }
>>>>>         });
>>>>>     }
>>>>> }
>>>>>
>>>>> To reproduce the problem,
>>>>> please click on one cell from the "Number" column, delete all the 
>>>>> content but do not press enter to quit editing status, then click 
>>>>> the column title of "Number" column to sort, NPE will be thrown.
>>>>>
>>>>> The cause of this problem is when trying to quit editing with 
>>>>> empty content of a cell  and also try to accept the partially 
>>>>> edited value using stopCellEditing(), following two actions will 
>>>>> be taken.
>>>>> 1, the cellEditor of current table will be set to null.
>>>>> 2, the value type of this column does not have a constructor to 
>>>>> accept "Object[]" parameter, false will be returned.
>>>>> Then swing will try to cancel edition without accepting the 
>>>>> partially edited value using cancelCellEditing() which will get 
>>>>> null for the value of cellEditor thus lead to this NPE.
>>>>>
>>>>> The patch is trying to return earlier before the type 
>>>>> compatibility check of partially edited values when empty cell 
>>>>> values encountered.
>>>>>
>>>>> Cheers!
>>>>> - Jonathan
>>>>>
>>>>
>>>
>>
>

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

From luchsh at linux.vnet.ibm.com  Thu Apr 19 09:51:42 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 19 Apr 2012 17:51:42 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8F857A.4090007@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com>
Message-ID: <4F8FE02E.7070806@linux.vnet.ibm.com>

Hi Pavel,

I found Util.invokeOnEDT in awt repository, and have updated the test 
case, could you please take another look?
http://cr.openjdk.java.net/~luchsh/7055065_2/

It indeed confused me when found the change in awt repository, will it 
be merged to swing repository or is it a special change for testing 
infrastructure so went to awt repository?

Thanks and best regards!
- Jonathan

On 04/19/2012 11:24 AM, Jonathan Lu wrote:
> Hi Pavel,
>
> After a simple grep, I did not see any invokeOnEDT method from swing 
> or 2d repository, has it been committed yet?
>
> Thanks and best regards!
> - Jonathan
>
> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> Thanks for reviewing, here's the webrev patch and automatic test. 
>>> Could you please help to take another look?
>>> http://cr.openjdk.java.net/~luchsh/7055065/
>> The fix looks good. Could you please fix few minor changes:
>>
>> 1. Don't use full class names like javax.swing.SwingUtilities when 
>> possible. I didn't find such rule in our Code Conventions but we 
>> follow this rule.
>>
>> 2. Swap two lines please
>>   frame.setVisible(true);
>>   frame.setLocation(0, 0);
>> That's not critical for the test but we shouldn't provide bad examples
>>
>> 3. I've recently introduced the Util#invokeOnEDT method. It can 
>> simplify your test and the getHeaderClickPoint and getCellClickPoint 
>> methods can be removed.
>>
>> Regards, Pavel
>>>
>>> Thanks & regards!
>>> - Jonathan
>>>
>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>
>>>> The fix looks good. Could you please write an automatic test, put 
>>>> it into an appropriate place of repository and make a webrev with 
>>>> fix and test?
>>>>
>>>> Regards, Pavel
>>>>> Hello swing-dev,
>>>>>
>>>>> I've got a patch for bug 7055065, can anybody please help to take 
>>>>> a look?
>>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>>>
>>>>> And also a simple test case for this issue here.
>>>>>
>>>>> /*
>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>>>> reserved.
>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>  *
>>>>>  * This code is free software; you can redistribute it and/or 
>>>>> modify it
>>>>>  * under the terms of the GNU General Public License version 2 
>>>>> only, as
>>>>>  * published by the Free Software Foundation.
>>>>>  *
>>>>>  * This code is distributed in the hope that it will be useful, 
>>>>> but WITHOUT
>>>>>  * ANY WARRANTY; without even the implied warranty of 
>>>>> MERCHANTABILITY or
>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>>>> License
>>>>>  * version 2 for more details (a copy is included in the LICENSE 
>>>>> file that
>>>>>  * accompanied this code).
>>>>>  *
>>>>>  * You should have received a copy of the GNU General Public 
>>>>> License version
>>>>>  * 2 along with this work; if not, write to the Free Software 
>>>>> Foundation,
>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>  *
>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>>>> 94065 USA
>>>>>  * or visit www.oracle.com if you need additional information or 
>>>>> have any
>>>>>  * questions.
>>>>>  */
>>>>>
>>>>> /*
>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>  */
>>>>>
>>>>> import javax.swing.JFrame;
>>>>> import javax.swing.JPanel;
>>>>> import javax.swing.JScrollPane;
>>>>> import javax.swing.JTable;
>>>>> import javax.swing.table.AbstractTableModel;
>>>>> import javax.swing.table.TableModel;
>>>>> import javax.swing.table.TableRowSorter;
>>>>> import java.awt.Dimension;
>>>>> import java.awt.GridLayout;
>>>>>
>>>>> public class TableDemo extends JPanel {
>>>>>
>>>>>     public TableDemo() {
>>>>>         super(new GridLayout(1, 0));
>>>>>
>>>>>         final String[] columnNames = { "String", "Number" };
>>>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>                 { "bbbb", new Integer(3) }, { "cccc", new 
>>>>> Integer(2) },
>>>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>>>> Integer(10) } };
>>>>>         final JTable table = new JTable(data, columnNames);
>>>>>
>>>>>         table.setPreferredScrollableViewportSize(new 
>>>>> Dimension(500, 400));
>>>>>         table.setFillsViewportHeight(true);
>>>>>         TableModel dataModel = new AbstractTableModel() {
>>>>>
>>>>>             public int getColumnCount() {
>>>>>                 return columnNames.length;
>>>>>             }
>>>>>             public int getRowCount() {
>>>>>                 return data.length;
>>>>>             }
>>>>>             public Object getValueAt(int row, int col) {
>>>>>                 return data[row][col];
>>>>>             }
>>>>>             public String getColumnName(int column) {
>>>>>                 return columnNames[column];
>>>>>             }
>>>>>             public Class<?> getColumnClass(int c) {
>>>>>                 return getValueAt(0, c).getClass();
>>>>>             }
>>>>>             public boolean isCellEditable(int row, int col) {
>>>>>                 return col != 5;
>>>>>             }
>>>>>             public void setValueAt(Object aValue, int row, int 
>>>>> column) {
>>>>>                 data[row][column] = aValue;
>>>>>             }
>>>>>         };
>>>>>         table.setModel(dataModel);
>>>>>         TableRowSorter<TableModel> sorter = new 
>>>>> TableRowSorter<TableModel>(
>>>>>                 dataModel);
>>>>>         table.setRowSorter(sorter);
>>>>>
>>>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>>>         add(scrollPane);
>>>>>     }
>>>>>
>>>>>     public static void main(String[] args) throws Exception {
>>>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>>>             public void run() {
>>>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>>>                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>
>>>>>                 TableDemo newContentPane = new TableDemo();
>>>>>                 newContentPane.setOpaque(true);
>>>>>                 frame.setContentPane(newContentPane);
>>>>>
>>>>>                 frame.pack();
>>>>>                 frame.setVisible(true);
>>>>>             }
>>>>>         });
>>>>>     }
>>>>> }
>>>>>
>>>>> To reproduce the problem,
>>>>> please click on one cell from the "Number" column, delete all the 
>>>>> content but do not press enter to quit editing status, then click 
>>>>> the column title of "Number" column to sort, NPE will be thrown.
>>>>>
>>>>> The cause of this problem is when trying to quit editing with 
>>>>> empty content of a cell  and also try to accept the partially 
>>>>> edited value using stopCellEditing(), following two actions will 
>>>>> be taken.
>>>>> 1, the cellEditor of current table will be set to null.
>>>>> 2, the value type of this column does not have a constructor to 
>>>>> accept "Object[]" parameter, false will be returned.
>>>>> Then swing will try to cancel edition without accepting the 
>>>>> partially edited value using cancelCellEditing() which will get 
>>>>> null for the value of cellEditor thus lead to this NPE.
>>>>>
>>>>> The patch is trying to return earlier before the type 
>>>>> compatibility check of partially edited values when empty cell 
>>>>> values encountered.
>>>>>
>>>>> Cheers!
>>>>> - Jonathan
>>>>>
>>>>
>>>
>>
>



From luchsh at linux.vnet.ibm.com  Thu Apr 19 14:16:23 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 19 Apr 2012 22:16:23 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8FE1B6.3020808@oracle.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com> <4F8FE1B6.3020808@oracle.com>
Message-ID: <4F901E37.1080408@linux.vnet.ibm.com>

Hi Pavel,

On 04/19/2012 05:58 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Pavel,
>>
>> After a simple grep, I did not see any invokeOnEDT method from swing 
>> or 2d repository, has it been committed yet?
> That's because you are using incorrect  repository. See here:
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8fe9b93e2474
>
> Swing and AWT teams use awt repository.

I realized that in my later mail and the patch has been updated and 
posted along with my mail, could you please take a look?

>
> Regards, Pavel
>>
>> Thanks and best regards!
>> - Jonathan
>>
>> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> Thanks for reviewing, here's the webrev patch and automatic test. 
>>>> Could you please help to take another look?
>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>> The fix looks good. Could you please fix few minor changes:
>>>
>>> 1. Don't use full class names like javax.swing.SwingUtilities when 
>>> possible. I didn't find such rule in our Code Conventions but we 
>>> follow this rule.
>>>
>>> 2. Swap two lines please
>>>   frame.setVisible(true);
>>>   frame.setLocation(0, 0);
>>> That's not critical for the test but we shouldn't provide bad examples
>>>
>>> 3. I've recently introduced the Util#invokeOnEDT method. It can 
>>> simplify your test and the getHeaderClickPoint and getCellClickPoint 
>>> methods can be removed.
>>>
>>> Regards, Pavel
>>>>
>>>> Thanks & regards!
>>>> - Jonathan
>>>>
>>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> The fix looks good. Could you please write an automatic test, put 
>>>>> it into an appropriate place of repository and make a webrev with 
>>>>> fix and test?
>>>>>
>>>>> Regards, Pavel
>>>>>> Hello swing-dev,
>>>>>>
>>>>>> I've got a patch for bug 7055065, can anybody please help to take 
>>>>>> a look?
>>>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>>>>
>>>>>> And also a simple test case for this issue here.
>>>>>>
>>>>>> /*
>>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>>>>> reserved.
>>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>>  *
>>>>>>  * This code is free software; you can redistribute it and/or 
>>>>>> modify it
>>>>>>  * under the terms of the GNU General Public License version 2 
>>>>>> only, as
>>>>>>  * published by the Free Software Foundation.
>>>>>>  *
>>>>>>  * This code is distributed in the hope that it will be useful, 
>>>>>> but WITHOUT
>>>>>>  * ANY WARRANTY; without even the implied warranty of 
>>>>>> MERCHANTABILITY or
>>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>>>>> License
>>>>>>  * version 2 for more details (a copy is included in the LICENSE 
>>>>>> file that
>>>>>>  * accompanied this code).
>>>>>>  *
>>>>>>  * You should have received a copy of the GNU General Public 
>>>>>> License version
>>>>>>  * 2 along with this work; if not, write to the Free Software 
>>>>>> Foundation,
>>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>>  *
>>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>>>>> 94065 USA
>>>>>>  * or visit www.oracle.com if you need additional information or 
>>>>>> have any
>>>>>>  * questions.
>>>>>>  */
>>>>>>
>>>>>> /*
>>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>>  */
>>>>>>
>>>>>> import javax.swing.JFrame;
>>>>>> import javax.swing.JPanel;
>>>>>> import javax.swing.JScrollPane;
>>>>>> import javax.swing.JTable;
>>>>>> import javax.swing.table.AbstractTableModel;
>>>>>> import javax.swing.table.TableModel;
>>>>>> import javax.swing.table.TableRowSorter;
>>>>>> import java.awt.Dimension;
>>>>>> import java.awt.GridLayout;
>>>>>>
>>>>>> public class TableDemo extends JPanel {
>>>>>>
>>>>>>     public TableDemo() {
>>>>>>         super(new GridLayout(1, 0));
>>>>>>
>>>>>>         final String[] columnNames = { "String", "Number" };
>>>>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>>                 { "bbbb", new Integer(3) }, { "cccc", new 
>>>>>> Integer(2) },
>>>>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>>>>> Integer(10) } };
>>>>>>         final JTable table = new JTable(data, columnNames);
>>>>>>
>>>>>>         table.setPreferredScrollableViewportSize(new 
>>>>>> Dimension(500, 400));
>>>>>>         table.setFillsViewportHeight(true);
>>>>>>         TableModel dataModel = new AbstractTableModel() {
>>>>>>
>>>>>>             public int getColumnCount() {
>>>>>>                 return columnNames.length;
>>>>>>             }
>>>>>>             public int getRowCount() {
>>>>>>                 return data.length;
>>>>>>             }
>>>>>>             public Object getValueAt(int row, int col) {
>>>>>>                 return data[row][col];
>>>>>>             }
>>>>>>             public String getColumnName(int column) {
>>>>>>                 return columnNames[column];
>>>>>>             }
>>>>>>             public Class<?> getColumnClass(int c) {
>>>>>>                 return getValueAt(0, c).getClass();
>>>>>>             }
>>>>>>             public boolean isCellEditable(int row, int col) {
>>>>>>                 return col != 5;
>>>>>>             }
>>>>>>             public void setValueAt(Object aValue, int row, int 
>>>>>> column) {
>>>>>>                 data[row][column] = aValue;
>>>>>>             }
>>>>>>         };
>>>>>>         table.setModel(dataModel);
>>>>>>         TableRowSorter<TableModel> sorter = new 
>>>>>> TableRowSorter<TableModel>(
>>>>>>                 dataModel);
>>>>>>         table.setRowSorter(sorter);
>>>>>>
>>>>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>>>>         add(scrollPane);
>>>>>>     }
>>>>>>
>>>>>>     public static void main(String[] args) throws Exception {
>>>>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>>>>             public void run() {
>>>>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>>>>                 
>>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>>
>>>>>>                 TableDemo newContentPane = new TableDemo();
>>>>>>                 newContentPane.setOpaque(true);
>>>>>>                 frame.setContentPane(newContentPane);
>>>>>>
>>>>>>                 frame.pack();
>>>>>>                 frame.setVisible(true);
>>>>>>             }
>>>>>>         });
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> To reproduce the problem,
>>>>>> please click on one cell from the "Number" column, delete all the 
>>>>>> content but do not press enter to quit editing status, then click 
>>>>>> the column title of "Number" column to sort, NPE will be thrown.
>>>>>>
>>>>>> The cause of this problem is when trying to quit editing with 
>>>>>> empty content of a cell  and also try to accept the partially 
>>>>>> edited value using stopCellEditing(), following two actions will 
>>>>>> be taken.
>>>>>> 1, the cellEditor of current table will be set to null.
>>>>>> 2, the value type of this column does not have a constructor to 
>>>>>> accept "Object[]" parameter, false will be returned.
>>>>>> Then swing will try to cancel edition without accepting the 
>>>>>> partially edited value using cancelCellEditing() which will get 
>>>>>> null for the value of cellEditor thus lead to this NPE.
>>>>>>
>>>>>> The patch is trying to return earlier before the type 
>>>>>> compatibility check of partially edited values when empty cell 
>>>>>> values encountered.
>>>>>>
>>>>>> Cheers!
>>>>>> - Jonathan
>>>>>>
>>>>>
>>>>
>>>
>>
>
Thanks!
- Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120419/2972017f/attachment.html>

From neugens.limasoftware at gmail.com  Thu Apr 19 14:46:30 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 19 Apr 2012 16:46:30 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
	<CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
Message-ID: <CAGUMyaSkXVSpKUJAaRkTi39RmaumODp_K71CP-yEEw=B2wfNOA@mail.gmail.com>

Hi Pavel,

Did you had any chance to review this?

Thanks,
Mario

2012/4/17 Mario Torre <neugens.limasoftware at gmail.com>:
> 2012/4/16 Pavel Porvatov <pavel.porvatov at oracle.com>:
>
> Hello Pavel,
>
>>> About the test, I'm not sure if you need something more specific, but
>>> I was thinking to simply test if when isLightWeightPopupEnabled is set
>>> we create an heavy or lightweight popup, any other ideas?
>>
>> That's a good way I think
>
> Here is the webrev:
>
> http://cr.openjdk.java.net/~neugens/6800513/
>
> Note that MEDIUM_WEIGHT is still used in some cases (PopupFactory.getPopup):
>
> ? ? ? ?if (owner == null || invokerInHeavyWeightPopup(owner)) {
> ? ? ? ? ? ?popupType = HEAVY_WEIGHT_POPUP;
> ? ? ? ?}
> ? ? ? ?else if (popupType == LIGHT_WEIGHT_POPUP &&
> ? ? ? ? ? ? ? ? !(contents instanceof JToolTip) &&
> ? ? ? ? ? ? ? ? !(contents instanceof JPopupMenu)) {
> ? ? ? ? ? ?popupType = MEDIUM_WEIGHT_POPUP;
> ? ? ? ?}
>
> I'm not sure if we want to replace this as well with full HW (I would
> do it, in fact).
>
> Also I was thinking to have a very small optimization, if we are using
> an HW popups, there's no need to do this check:
>
> ? ? ? ?// Check if the parent component is an option pane. ?If so we need to
> ? ? ? ?// force a heavy weight popup in order to have event dispatching work
> ? ? ? ?// correctly.
> ? ? ? ?Component c = owner;
> ? ? ? ?while (c != null) {
> ? ? ? ? ? ?if (c instanceof JComponent) {
> ? ? ? ? ? ? ? ?if (((JComponent)c).getClientProperty(
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?PopupFactory_FORCE_HEAVYWEIGHT_POPUP) ==
> Boolean.TRUE) {
> ? ? ? ? ? ? ? ? ? ?popupType = HEAVY_WEIGHT_POPUP;
> ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ?} else if (c instanceof Window) {
> ? ? ? ? ? ? ? ?Window w = (Window) c;
> ? ? ? ? ? ? ? ?if (!w.isOpaque() || w.getOpacity() < 1 ||
> w.getShape() != null) {
> ? ? ? ? ? ? ? ? ? ?popupType = HEAVY_WEIGHT_POPUP;
> ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ?}
> ? ? ? ? ? ?c = c.getParent();
> ? ? ? ?}
>
> We can save a loop and a couple of instanceof checks (although I
> remember we proved with Jim and Phil that instanceof don't really
> introduce any speed penalization).
>
> What do you think?
>
> Cheers,
> Mario
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF
>
> IcedRobot: www.icedrobot.org
> Proud GNU Classpath developer: http://www.classpath.org/
> Read About us at: http://planet.classpath.org
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From pavel.porvatov at oracle.com  Thu Apr 19 15:27:26 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 19 Apr 2012 19:27:26 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaSkXVSpKUJAaRkTi39RmaumODp_K71CP-yEEw=B2wfNOA@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
	<CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<CAGUMyaSkXVSpKUJAaRkTi39RmaumODp_K71CP-yEEw=B2wfNOA@mail.gmail.com>
Message-ID: <4F902EDE.1020805@oracle.com>

Hi Mario,
> Hi Pavel,
>
> Did you had any chance to review this?
No, I didn't. I remember about your fix and I'll review the fix.

Regards, Pavel
>
> Thanks,
> Mario
>
> 2012/4/17 Mario Torre<neugens.limasoftware at gmail.com>:
>> 2012/4/16 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>
>> Hello Pavel,
>>
>>>> About the test, I'm not sure if you need something more specific, but
>>>> I was thinking to simply test if when isLightWeightPopupEnabled is set
>>>> we create an heavy or lightweight popup, any other ideas?
>>> That's a good way I think
>> Here is the webrev:
>>
>> http://cr.openjdk.java.net/~neugens/6800513/
>>
>> Note that MEDIUM_WEIGHT is still used in some cases (PopupFactory.getPopup):
>>
>>         if (owner == null || invokerInHeavyWeightPopup(owner)) {
>>             popupType = HEAVY_WEIGHT_POPUP;
>>         }
>>         else if (popupType == LIGHT_WEIGHT_POPUP&&
>>                  !(contents instanceof JToolTip)&&
>>                  !(contents instanceof JPopupMenu)) {
>>             popupType = MEDIUM_WEIGHT_POPUP;
>>         }
>>
>> I'm not sure if we want to replace this as well with full HW (I would
>> do it, in fact).
>>
>> Also I was thinking to have a very small optimization, if we are using
>> an HW popups, there's no need to do this check:
>>
>>         // Check if the parent component is an option pane.  If so we need to
>>         // force a heavy weight popup in order to have event dispatching work
>>         // correctly.
>>         Component c = owner;
>>         while (c != null) {
>>             if (c instanceof JComponent) {
>>                 if (((JComponent)c).getClientProperty(
>>                             PopupFactory_FORCE_HEAVYWEIGHT_POPUP) ==
>> Boolean.TRUE) {
>>                     popupType = HEAVY_WEIGHT_POPUP;
>>                     break;
>>                 }
>>             } else if (c instanceof Window) {
>>                 Window w = (Window) c;
>>                 if (!w.isOpaque() || w.getOpacity()<  1 ||
>> w.getShape() != null) {
>>                     popupType = HEAVY_WEIGHT_POPUP;
>>                     break;
>>                 }
>>             }
>>             c = c.getParent();
>>         }
>>
>> We can save a loop and a couple of instanceof checks (although I
>> remember we proved with Jim and Phil that instanceof don't really
>> introduce any speed penalization).
>>
>> What do you think?
>>
>> Cheers,
>> Mario
>> --
>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
>> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>>
>> IcedRobot: www.icedrobot.org
>> Proud GNU Classpath developer: http://www.classpath.org/
>> Read About us at: http://planet.classpath.org
>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>>
>> Please, support open standards:
>> http://endsoftpatents.org/
>
>



From pavel.porvatov at oracle.com  Thu Apr 19 15:52:54 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 19 Apr 2012 19:52:54 +0400
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8FE02E.7070806@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com>
	<4F8FE02E.7070806@linux.vnet.ibm.com>
Message-ID: <4F9034D6.2040305@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> I found Util.invokeOnEDT in awt repository, and have updated the test 
> case, could you please take another look?
> http://cr.openjdk.java.net/~luchsh/7055065_2/
The fix looks good. I approve it.
>
> It indeed confused me when found the change in awt repository, will it 
> be merged to swing repository or is it a special change for testing 
> infrastructure so went to awt repository?
Swing repository is a legacy one and it's not used. I hope it will be 
removed soon to avoid such confusion.

Regards, Pavel
>
> Thanks and best regards!
> - Jonathan
>
> On 04/19/2012 11:24 AM, Jonathan Lu wrote:
>> Hi Pavel,
>>
>> After a simple grep, I did not see any invokeOnEDT method from swing 
>> or 2d repository, has it been committed yet?
>>
>> Thanks and best regards!
>> - Jonathan
>>
>> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> Thanks for reviewing, here's the webrev patch and automatic test. 
>>>> Could you please help to take another look?
>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>> The fix looks good. Could you please fix few minor changes:
>>>
>>> 1. Don't use full class names like javax.swing.SwingUtilities when 
>>> possible. I didn't find such rule in our Code Conventions but we 
>>> follow this rule.
>>>
>>> 2. Swap two lines please
>>>   frame.setVisible(true);
>>>   frame.setLocation(0, 0);
>>> That's not critical for the test but we shouldn't provide bad examples
>>>
>>> 3. I've recently introduced the Util#invokeOnEDT method. It can 
>>> simplify your test and the getHeaderClickPoint and getCellClickPoint 
>>> methods can be removed.
>>>
>>> Regards, Pavel
>>>>
>>>> Thanks & regards!
>>>> - Jonathan
>>>>
>>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> The fix looks good. Could you please write an automatic test, put 
>>>>> it into an appropriate place of repository and make a webrev with 
>>>>> fix and test?
>>>>>
>>>>> Regards, Pavel
>>>>>> Hello swing-dev,
>>>>>>
>>>>>> I've got a patch for bug 7055065, can anybody please help to take 
>>>>>> a look?
>>>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>>>>
>>>>>> And also a simple test case for this issue here.
>>>>>>
>>>>>> /*
>>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>>>>> reserved.
>>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>>  *
>>>>>>  * This code is free software; you can redistribute it and/or 
>>>>>> modify it
>>>>>>  * under the terms of the GNU General Public License version 2 
>>>>>> only, as
>>>>>>  * published by the Free Software Foundation.
>>>>>>  *
>>>>>>  * This code is distributed in the hope that it will be useful, 
>>>>>> but WITHOUT
>>>>>>  * ANY WARRANTY; without even the implied warranty of 
>>>>>> MERCHANTABILITY or
>>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>>>>> License
>>>>>>  * version 2 for more details (a copy is included in the LICENSE 
>>>>>> file that
>>>>>>  * accompanied this code).
>>>>>>  *
>>>>>>  * You should have received a copy of the GNU General Public 
>>>>>> License version
>>>>>>  * 2 along with this work; if not, write to the Free Software 
>>>>>> Foundation,
>>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>>  *
>>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>>>>> 94065 USA
>>>>>>  * or visit www.oracle.com if you need additional information or 
>>>>>> have any
>>>>>>  * questions.
>>>>>>  */
>>>>>>
>>>>>> /*
>>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>>  */
>>>>>>
>>>>>> import javax.swing.JFrame;
>>>>>> import javax.swing.JPanel;
>>>>>> import javax.swing.JScrollPane;
>>>>>> import javax.swing.JTable;
>>>>>> import javax.swing.table.AbstractTableModel;
>>>>>> import javax.swing.table.TableModel;
>>>>>> import javax.swing.table.TableRowSorter;
>>>>>> import java.awt.Dimension;
>>>>>> import java.awt.GridLayout;
>>>>>>
>>>>>> public class TableDemo extends JPanel {
>>>>>>
>>>>>>     public TableDemo() {
>>>>>>         super(new GridLayout(1, 0));
>>>>>>
>>>>>>         final String[] columnNames = { "String", "Number" };
>>>>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>>                 { "bbbb", new Integer(3) }, { "cccc", new 
>>>>>> Integer(2) },
>>>>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>>>>> Integer(10) } };
>>>>>>         final JTable table = new JTable(data, columnNames);
>>>>>>
>>>>>>         table.setPreferredScrollableViewportSize(new 
>>>>>> Dimension(500, 400));
>>>>>>         table.setFillsViewportHeight(true);
>>>>>>         TableModel dataModel = new AbstractTableModel() {
>>>>>>
>>>>>>             public int getColumnCount() {
>>>>>>                 return columnNames.length;
>>>>>>             }
>>>>>>             public int getRowCount() {
>>>>>>                 return data.length;
>>>>>>             }
>>>>>>             public Object getValueAt(int row, int col) {
>>>>>>                 return data[row][col];
>>>>>>             }
>>>>>>             public String getColumnName(int column) {
>>>>>>                 return columnNames[column];
>>>>>>             }
>>>>>>             public Class<?> getColumnClass(int c) {
>>>>>>                 return getValueAt(0, c).getClass();
>>>>>>             }
>>>>>>             public boolean isCellEditable(int row, int col) {
>>>>>>                 return col != 5;
>>>>>>             }
>>>>>>             public void setValueAt(Object aValue, int row, int 
>>>>>> column) {
>>>>>>                 data[row][column] = aValue;
>>>>>>             }
>>>>>>         };
>>>>>>         table.setModel(dataModel);
>>>>>>         TableRowSorter<TableModel> sorter = new 
>>>>>> TableRowSorter<TableModel>(
>>>>>>                 dataModel);
>>>>>>         table.setRowSorter(sorter);
>>>>>>
>>>>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>>>>         add(scrollPane);
>>>>>>     }
>>>>>>
>>>>>>     public static void main(String[] args) throws Exception {
>>>>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>>>>             public void run() {
>>>>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>>>>                 
>>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>>
>>>>>>                 TableDemo newContentPane = new TableDemo();
>>>>>>                 newContentPane.setOpaque(true);
>>>>>>                 frame.setContentPane(newContentPane);
>>>>>>
>>>>>>                 frame.pack();
>>>>>>                 frame.setVisible(true);
>>>>>>             }
>>>>>>         });
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> To reproduce the problem,
>>>>>> please click on one cell from the "Number" column, delete all the 
>>>>>> content but do not press enter to quit editing status, then click 
>>>>>> the column title of "Number" column to sort, NPE will be thrown.
>>>>>>
>>>>>> The cause of this problem is when trying to quit editing with 
>>>>>> empty content of a cell  and also try to accept the partially 
>>>>>> edited value using stopCellEditing(), following two actions will 
>>>>>> be taken.
>>>>>> 1, the cellEditor of current table will be set to null.
>>>>>> 2, the value type of this column does not have a constructor to 
>>>>>> accept "Object[]" parameter, false will be returned.
>>>>>> Then swing will try to cancel edition without accepting the 
>>>>>> partially edited value using cancelCellEditing() which will get 
>>>>>> null for the value of cellEditor thus lead to this NPE.
>>>>>>
>>>>>> The patch is trying to return earlier before the type 
>>>>>> compatibility check of partially edited values when empty cell 
>>>>>> values encountered.
>>>>>>
>>>>>> Cheers!
>>>>>> - Jonathan
>>>>>>
>>>>>
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Thu Apr 19 15:57:40 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 19 Apr 2012 19:57:40 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F8D015E.30004@linux.vnet.ibm.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
	<CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
	<4F8D015E.30004@linux.vnet.ibm.com>
Message-ID: <4F9035F4.7050908@oracle.com>

Hi Charles,

See my comment at the end...
> On 04/16/2012 12:33 PM, Sean Chou wrote:
>> Hi Pavel,
>>
>>     Modified and tested on windows and linux.
>>
>> webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/ 
>> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.07/>
>>
>>
>>
>> On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov 
>> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>     Hi Sean,
>>>     Hi Pavel,
>>>
>>>         I modified the testcase according to your comments. The
>>>     webrev is http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/
>>>     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.06/>  .
>>>      Please take a look again.
>>     And now when fastreturn is true the test doesn't stop.
>>
>>     Regards, Pavel
>>
>>>
>>>     On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov
>>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>>
>>>     wrote:
>>>
>>>         Hi Sean,
>>>
>>>         The fix looks good, but I have several comments about the test:
>>>         1. You shouldn't use Swing components on non-EDT threads, so
>>>         frame.dispose() should be done on the EDT
>>>
>>>     I made a really stupid mistake... When I was checking the
>>>     testcase and found frame.dispose() in main method, I added a
>>>     volatile to the frame variable...
>>>
>>>         2. "These exceptions mean the implementation of
>>>         XTextAreaPeer is changed" - I think is XTextAreaPeer is
>>>         changed, then the test should be fixed as well or removed
>>>         (if the test become inapplicable. Therefore in that
>>>         situation the test should fail but not skipped
>>>
>>>         Regards, Pavel
>>>
>>>
>>>
>>>
>>>     -- 
>>>     Best Regards,
>>>     Sean Chou
>>>
>>
>>
>>
>>
>> -- 
>> Best Regards,
>> Sean Chou
>>
> Hi Sean,
>
> The patch is committed @
> Changeset: 4828ffa1f5ee
> Author:    zhouyx
> Date:      2012-04-17 13:31 +0800
> URL:http://hg.openjdk.java.net/jdk8/swing/jdk/rev/4828ffa1f5ee
>
> 7129742: Unable to view focus in Non-Editable TextArea
> Summary: Make sure the cursor is visible by setVisible(true)
> Reviewed-by: rupashka, alexp
>
> Please verify it and thanks all for reviewing the patch.
Unfortunately you put the change in a legacy repository. You must use 
awt repository for Swing and AWT fixes. Could you please re-push the fix 
in the http://hg.openjdk.java.net/jdk8/awt/jdk repository?

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120419/0b70f9a9/attachment.html>

From luchsh at linux.vnet.ibm.com  Thu Apr 19 16:10:27 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 20 Apr 2012 00:10:27 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F880273.3080704@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com>
Message-ID: <4F9038F3.5000703@linux.vnet.ibm.com>

Hi Pavel,

see my comments below,

On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Pavel,
>>
>> Here's another updated patch.
>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>
>> My comments are inlined.
> See below
>>
>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> Here's the update patch,
>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>
>>> Could you please explain one change in the JComponent.java:
>>>
>>> +    public void hide() {
>>> +        if (isVisible()) {
>>> +            super.hide();
>>>
>>> I think super.hide() should be invoked always. You must also add a 
>>> javadoc to the new hide method (see {@inheritDoc} for details)
>>
>> Yes, the old patch may cause Component.isPacked not to be set 
>> correctly, so moved super.hide() up.
> Ok. The next question: I think we should use in "if (isVisible())" 
> isShowing instead of isVisible. What do you think about that?

I do not think so, since the problem here is that the repaining work is 
not done after hiding a visible component, but the fields' status of 
this hidden component have been correct, so has its parent. And 
isShowing() 's implementation is just checking those fields in similar 
way as isVisible() except for additional checks for the parent, whose 
status also cannot reflect the visual picture from user's eyes. So in my 
opinion, isShowing does not help with this case better than isVisible 
but introduces more efforts of checking and branching. Pls fix me if 
anything wrong with my understanding.

BTW, there's a stupid bug in previous patch caused by my local testing 
cache was not cleaned up completely, terribly sorry for that and here's 
the updated patch. http://cr.openjdk.java.net/~luchsh/7154030_6/

>>
>>>
>>>
>>>
>>>>> 3. Could you please follow our code conventions?  (see 
>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>
>>>> Sorry for this problem, I was trying to keeping aligned with the 
>>>> original style of JComponent.java, which I later realized to be 
>>>> inappropriate. In the updated patch, code has been well formatted.
>>>>
>>>>> 4. Your test is not automatic one. I think you could use 
>>>>> java.awt.Robot#createScreenCapture and analyze result of hide method.
>>>>
>>>> See the link, it should be automatic now.
>>> The test should be corrected:
>>> 1. All Swing components must be accessed from the EDT thread
>> Updated in the new test.
>>> 2. What is the reason to introduce the MyButton class? I think the 
>>> test can be simplified, if you will use the 
>>> Util#compareBufferedImages (see 
>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>> screen-shots between show/hide and compare them
>>
>> The reason of introducing MyButton class is to test the show/hide of 
>> non-opaque component.
> Why can't we use something like following:
>                 button.setOpaque(false);
>                 button.setBackground(new Color(255, 0, 0, 128));
updated in new patch.
>
>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>
>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>> SunToolkit#realSync method (many existing tests uses it)
>>>
>> Updated in new test.
> Looks good. Could you please remove unnecessary "volatile" modifiers?
done in the new patch.
>
> Regards, Pavel

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

From littlee at linux.vnet.ibm.com  Fri Apr 20 05:20:47 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 20 Apr 2012 13:20:47 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F9035F4.7050908@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
	<4F61E737.7010201@oracle.com>
	<CAOo=rxXEPk5eMH7rvnqRe+SacfRouLL6G2o388ng4mrm2uf1Pg@mail.gmail.com>
	<4F86E596.1080701@oracle.com>
	<CAOo=rxWQcyD8ZAD+GHKmM+dfmmLKYmYmipgfewDHS3sveG_bKQ@mail.gmail.com>
	<4F8A955A.5010605@oracle.com>
	<CAOo=rxVHXK3PRuTEu+s8ofDzLpX41WrtAGmbtv-J_qv2o+D4Fw@mail.gmail.com>
	<4F8D015E.30004@linux.vnet.ibm.com> <4F9035F4.7050908@oracle.com>
Message-ID: <4F90F22F.3030705@linux.vnet.ibm.com>

On 04/19/2012 11:57 PM, Pavel Porvatov wrote:
> Hi Charles,
>
> See my comment at the end...
>> On 04/16/2012 12:33 PM, Sean Chou wrote:
>>> Hi Pavel,
>>>
>>>     Modified and tested on windows and linux.
>>>
>>> webrev at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.07/ 
>>> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.07/>
>>>
>>>
>>>
>>> On Sun, Apr 15, 2012 at 5:31 PM, Pavel Porvatov 
>>> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>>
>>>     Hi Sean,
>>>>     Hi Pavel,
>>>>
>>>>         I modified the testcase according to your comments. The
>>>>     webrev is http://cr.openjdk.java.net/~zhouyx/7129742/webrev.06/
>>>>     <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.06/>  .
>>>>      Please take a look again.
>>>     And now when fastreturn is true the test doesn't stop.
>>>
>>>     Regards, Pavel
>>>
>>>>
>>>>     On Thu, Apr 12, 2012 at 10:24 PM, Pavel Porvatov
>>>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>>
>>>>     wrote:
>>>>
>>>>         Hi Sean,
>>>>
>>>>         The fix looks good, but I have several comments about the test:
>>>>         1. You shouldn't use Swing components on non-EDT threads,
>>>>         so frame.dispose() should be done on the EDT
>>>>
>>>>     I made a really stupid mistake... When I was checking the
>>>>     testcase and found frame.dispose() in main method, I added a
>>>>     volatile to the frame variable...
>>>>
>>>>         2. "These exceptions mean the implementation of
>>>>         XTextAreaPeer is changed" - I think is XTextAreaPeer is
>>>>         changed, then the test should be fixed as well or removed
>>>>         (if the test become inapplicable. Therefore in that
>>>>         situation the test should fail but not skipped
>>>>
>>>>         Regards, Pavel
>>>>
>>>>
>>>>
>>>>
>>>>     -- 
>>>>     Best Regards,
>>>>     Sean Chou
>>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Best Regards,
>>> Sean Chou
>>>
>> Hi Sean,
>>
>> The patch is committed @
>> Changeset: 4828ffa1f5ee
>> Author:    zhouyx
>> Date:      2012-04-17 13:31 +0800
>> URL:http://hg.openjdk.java.net/jdk8/swing/jdk/rev/4828ffa1f5ee
>>
>> 7129742: Unable to view focus in Non-Editable TextArea
>> Summary: Make sure the cursor is visible by setVisible(true)
>> Reviewed-by: rupashka, alexp
>>
>> Please verify it and thanks all for reviewing the patch.
> Unfortunately you put the change in a legacy repository. You must use 
> awt repository for Swing and AWT fixes. Could you please re-push the 
> fix in the http://hg.openjdk.java.net/jdk8/awt/jdk repository?
>
> Regards, Pavel
Hi Pavel,

I have recommit the patch @

Changeset: 44beb8a52aec
Author:    zhouyx
Date:      2012-04-20 10:34 +0800
URL:http://hg.openjdk.java.net/jdk8/awt/jdk/rev/44beb8a52aec

7129742: Unable to view focus in Non-Editable TextArea
Summary: Make sure the cursor is visible by setVisible(true)
Reviewed-by: rupashka, alexp


Thank you very much.

-- 
Yours Charles

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

From littlee at linux.vnet.ibm.com  Fri Apr 20 05:25:05 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 20 Apr 2012 13:25:05 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F8FE02E.7070806@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com>
	<4F87F8F5.3000406@oracle.com>	<4F8BD09E.6020209@linux.vnet.ibm.com>
	<4F8C07A8.7020509@oracle.com>	<4F8F857A.4090007@linux.vnet.ibm.com>
	<4F8FE02E.7070806@linux.vnet.ibm.com>
Message-ID: <4F90F331.7070407@linux.vnet.ibm.com>

Hi Jonathan,

The patch is committed @

Changeset: dfa2ea47257d
Author:    luchsh
Date:      2012-04-20 13:13 +0800
URL:http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d

7055065: NullPointerException when sorting JTable with empty cell
Reviewed-by: rupashka


Please verify it.

Thanks Pavel for reviewing it.

On 04/19/2012 05:51 PM, Jonathan Lu wrote:
> Hi Pavel,
>
> I found Util.invokeOnEDT in awt repository, and have updated the test 
> case, could you please take another look?
> http://cr.openjdk.java.net/~luchsh/7055065_2/
>
> It indeed confused me when found the change in awt repository, will it 
> be merged to swing repository or is it a special change for testing 
> infrastructure so went to awt repository?
>
> Thanks and best regards!
> - Jonathan
>
> On 04/19/2012 11:24 AM, Jonathan Lu wrote:
>> Hi Pavel,
>>
>> After a simple grep, I did not see any invokeOnEDT method from swing 
>> or 2d repository, has it been committed yet?
>>
>> Thanks and best regards!
>> - Jonathan
>>
>> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> Thanks for reviewing, here's the webrev patch and automatic test. 
>>>> Could you please help to take another look?
>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>> The fix looks good. Could you please fix few minor changes:
>>>
>>> 1. Don't use full class names like javax.swing.SwingUtilities when 
>>> possible. I didn't find such rule in our Code Conventions but we 
>>> follow this rule.
>>>
>>> 2. Swap two lines please
>>>   frame.setVisible(true);
>>>   frame.setLocation(0, 0);
>>> That's not critical for the test but we shouldn't provide bad examples
>>>
>>> 3. I've recently introduced the Util#invokeOnEDT method. It can 
>>> simplify your test and the getHeaderClickPoint and getCellClickPoint 
>>> methods can be removed.
>>>
>>> Regards, Pavel
>>>>
>>>> Thanks & regards!
>>>> - Jonathan
>>>>
>>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> The fix looks good. Could you please write an automatic test, put 
>>>>> it into an appropriate place of repository and make a webrev with 
>>>>> fix and test?
>>>>>
>>>>> Regards, Pavel
>>>>>> Hello swing-dev,
>>>>>>
>>>>>> I've got a patch for bug 7055065, can anybody please help to take 
>>>>>> a look?
>>>>>> http://cr.openjdk.java.net/~luchsh/7055065/
>>>>>>
>>>>>> And also a simple test case for this issue here.
>>>>>>
>>>>>> /*
>>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights 
>>>>>> reserved.
>>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>>  *
>>>>>>  * This code is free software; you can redistribute it and/or 
>>>>>> modify it
>>>>>>  * under the terms of the GNU General Public License version 2 
>>>>>> only, as
>>>>>>  * published by the Free Software Foundation.
>>>>>>  *
>>>>>>  * This code is distributed in the hope that it will be useful, 
>>>>>> but WITHOUT
>>>>>>  * ANY WARRANTY; without even the implied warranty of 
>>>>>> MERCHANTABILITY or
>>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
>>>>>> License
>>>>>>  * version 2 for more details (a copy is included in the LICENSE 
>>>>>> file that
>>>>>>  * accompanied this code).
>>>>>>  *
>>>>>>  * You should have received a copy of the GNU General Public 
>>>>>> License version
>>>>>>  * 2 along with this work; if not, write to the Free Software 
>>>>>> Foundation,
>>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>>  *
>>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>>>>>> 94065 USA
>>>>>>  * or visit www.oracle.com if you need additional information or 
>>>>>> have any
>>>>>>  * questions.
>>>>>>  */
>>>>>>
>>>>>> /*
>>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>>  */
>>>>>>
>>>>>> import javax.swing.JFrame;
>>>>>> import javax.swing.JPanel;
>>>>>> import javax.swing.JScrollPane;
>>>>>> import javax.swing.JTable;
>>>>>> import javax.swing.table.AbstractTableModel;
>>>>>> import javax.swing.table.TableModel;
>>>>>> import javax.swing.table.TableRowSorter;
>>>>>> import java.awt.Dimension;
>>>>>> import java.awt.GridLayout;
>>>>>>
>>>>>> public class TableDemo extends JPanel {
>>>>>>
>>>>>>     public TableDemo() {
>>>>>>         super(new GridLayout(1, 0));
>>>>>>
>>>>>>         final String[] columnNames = { "String", "Number" };
>>>>>>         final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>>                 { "bbbb", new Integer(3) }, { "cccc", new 
>>>>>> Integer(2) },
>>>>>>                 { "dddd", new Integer(20) }, { "eeee", new 
>>>>>> Integer(10) } };
>>>>>>         final JTable table = new JTable(data, columnNames);
>>>>>>
>>>>>>         table.setPreferredScrollableViewportSize(new 
>>>>>> Dimension(500, 400));
>>>>>>         table.setFillsViewportHeight(true);
>>>>>>         TableModel dataModel = new AbstractTableModel() {
>>>>>>
>>>>>>             public int getColumnCount() {
>>>>>>                 return columnNames.length;
>>>>>>             }
>>>>>>             public int getRowCount() {
>>>>>>                 return data.length;
>>>>>>             }
>>>>>>             public Object getValueAt(int row, int col) {
>>>>>>                 return data[row][col];
>>>>>>             }
>>>>>>             public String getColumnName(int column) {
>>>>>>                 return columnNames[column];
>>>>>>             }
>>>>>>             public Class<?> getColumnClass(int c) {
>>>>>>                 return getValueAt(0, c).getClass();
>>>>>>             }
>>>>>>             public boolean isCellEditable(int row, int col) {
>>>>>>                 return col != 5;
>>>>>>             }
>>>>>>             public void setValueAt(Object aValue, int row, int 
>>>>>> column) {
>>>>>>                 data[row][column] = aValue;
>>>>>>             }
>>>>>>         };
>>>>>>         table.setModel(dataModel);
>>>>>>         TableRowSorter<TableModel> sorter = new 
>>>>>> TableRowSorter<TableModel>(
>>>>>>                 dataModel);
>>>>>>         table.setRowSorter(sorter);
>>>>>>
>>>>>>         JScrollPane scrollPane = new JScrollPane(table);
>>>>>>         add(scrollPane);
>>>>>>     }
>>>>>>
>>>>>>     public static void main(String[] args) throws Exception {
>>>>>>         javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
>>>>>>             public void run() {
>>>>>>                 JFrame frame = new JFrame("SimpleTableDemo");
>>>>>>                 
>>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>>
>>>>>>                 TableDemo newContentPane = new TableDemo();
>>>>>>                 newContentPane.setOpaque(true);
>>>>>>                 frame.setContentPane(newContentPane);
>>>>>>
>>>>>>                 frame.pack();
>>>>>>                 frame.setVisible(true);
>>>>>>             }
>>>>>>         });
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> To reproduce the problem,
>>>>>> please click on one cell from the "Number" column, delete all the 
>>>>>> content but do not press enter to quit editing status, then click 
>>>>>> the column title of "Number" column to sort, NPE will be thrown.
>>>>>>
>>>>>> The cause of this problem is when trying to quit editing with 
>>>>>> empty content of a cell  and also try to accept the partially 
>>>>>> edited value using stopCellEditing(), following two actions will 
>>>>>> be taken.
>>>>>> 1, the cellEditor of current table will be set to null.
>>>>>> 2, the value type of this column does not have a constructor to 
>>>>>> accept "Object[]" parameter, false will be returned.
>>>>>> Then swing will try to cancel edition without accepting the 
>>>>>> partially edited value using cancelCellEditing() which will get 
>>>>>> null for the value of cellEditor thus lead to this NPE.
>>>>>>
>>>>>> The patch is trying to return earlier before the type 
>>>>>> compatibility check of partially edited values when empty cell 
>>>>>> values encountered.
>>>>>>
>>>>>> Cheers!
>>>>>> - Jonathan
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Yours Charles



From luchsh at linux.vnet.ibm.com  Fri Apr 20 10:56:15 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 20 Apr 2012 18:56:15 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F90F331.7070407@linux.vnet.ibm.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com>
	<4F8FE02E.7070806@linux.vnet.ibm.com>
	<4F90F331.7070407@linux.vnet.ibm.com>
Message-ID: <CAC-GWLc4+ZcGJOajrPV99LvL-x3HJqC6gjq90SNKJsZQu6RiZQ@mail.gmail.com>

Verified.

Thanks, Charles!

- Jonathan

2012/4/20 Charles Lee <littlee at linux.vnet.ibm.com>

> Hi Jonathan,
>
> The patch is committed @
>
> Changeset: dfa2ea47257d
> Author:    luchsh
> Date:      2012-04-20 13:13 +0800
> URL:http://hg.openjdk.java.**net/jdk8/awt/jdk/rev/**dfa2ea47257d<http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d>
>
> 7055065: NullPointerException when sorting JTable with empty cell
> Reviewed-by: rupashka
>
>
> Please verify it.
>
> Thanks Pavel for reviewing it.
>
>
> On 04/19/2012 05:51 PM, Jonathan Lu wrote:
>
>> Hi Pavel,
>>
>> I found Util.invokeOnEDT in awt repository, and have updated the test
>> case, could you please take another look?
>> http://cr.openjdk.java.net/~**luchsh/7055065_2/<http://cr.openjdk.java.net/%7Eluchsh/7055065_2/>
>>
>> It indeed confused me when found the change in awt repository, will it be
>> merged to swing repository or is it a special change for testing
>> infrastructure so went to awt repository?
>>
>> Thanks and best regards!
>> - Jonathan
>>
>> On 04/19/2012 11:24 AM, Jonathan Lu wrote:
>>
>>> Hi Pavel,
>>>
>>> After a simple grep, I did not see any invokeOnEDT method from swing or
>>> 2d repository, has it been committed yet?
>>>
>>> Thanks and best regards!
>>> - Jonathan
>>>
>>> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>>>
>>>> Hi Jonathan,
>>>>
>>>>> Hi Pavel,
>>>>>
>>>>> Thanks for reviewing, here's the webrev patch and automatic test.
>>>>> Could you please help to take another look?
>>>>> http://cr.openjdk.java.net/~**luchsh/7055065/<http://cr.openjdk.java.net/%7Eluchsh/7055065/>
>>>>>
>>>> The fix looks good. Could you please fix few minor changes:
>>>>
>>>> 1. Don't use full class names like javax.swing.SwingUtilities when
>>>> possible. I didn't find such rule in our Code Conventions but we follow
>>>> this rule.
>>>>
>>>> 2. Swap two lines please
>>>>  frame.setVisible(true);
>>>>  frame.setLocation(0, 0);
>>>> That's not critical for the test but we shouldn't provide bad examples
>>>>
>>>> 3. I've recently introduced the Util#invokeOnEDT method. It can
>>>> simplify your test and the getHeaderClickPoint and getCellClickPoint
>>>> methods can be removed.
>>>>
>>>> Regards, Pavel
>>>>
>>>>>
>>>>> Thanks & regards!
>>>>> - Jonathan
>>>>>
>>>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>>>
>>>>>> Hi Jonathan,
>>>>>>
>>>>>> The fix looks good. Could you please write an automatic test, put it
>>>>>> into an appropriate place of repository and make a webrev with fix and test?
>>>>>>
>>>>>> Regards, Pavel
>>>>>>
>>>>>>> Hello swing-dev,
>>>>>>>
>>>>>>> I've got a patch for bug 7055065, can anybody please help to take a
>>>>>>> look?
>>>>>>> http://cr.openjdk.java.net/~**luchsh/7055065/<http://cr.openjdk.java.net/%7Eluchsh/7055065/>
>>>>>>>
>>>>>>> And also a simple test case for this issue here.
>>>>>>>
>>>>>>> /*
>>>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>>>>>>> reserved.
>>>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>>>  *
>>>>>>>  * This code is free software; you can redistribute it and/or modify
>>>>>>> it
>>>>>>>  * under the terms of the GNU General Public License version 2 only,
>>>>>>> as
>>>>>>>  * published by the Free Software Foundation.
>>>>>>>  *
>>>>>>>  * This code is distributed in the hope that it will be useful, but
>>>>>>> WITHOUT
>>>>>>>  * ANY WARRANTY; without even the implied warranty of
>>>>>>> MERCHANTABILITY or
>>>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>>>>>>> License
>>>>>>>  * version 2 for more details (a copy is included in the LICENSE
>>>>>>> file that
>>>>>>>  * accompanied this code).
>>>>>>>  *
>>>>>>>  * You should have received a copy of the GNU General Public License
>>>>>>> version
>>>>>>>  * 2 along with this work; if not, write to the Free Software
>>>>>>> Foundation,
>>>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>>>  *
>>>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
>>>>>>> 94065 USA
>>>>>>>  * or visit www.oracle.com if you need additional information or
>>>>>>> have any
>>>>>>>  * questions.
>>>>>>>  */
>>>>>>>
>>>>>>> /*
>>>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>>>  */
>>>>>>>
>>>>>>> import javax.swing.JFrame;
>>>>>>> import javax.swing.JPanel;
>>>>>>> import javax.swing.JScrollPane;
>>>>>>> import javax.swing.JTable;
>>>>>>> import javax.swing.table.**AbstractTableModel;
>>>>>>> import javax.swing.table.TableModel;
>>>>>>> import javax.swing.table.**TableRowSorter;
>>>>>>> import java.awt.Dimension;
>>>>>>> import java.awt.GridLayout;
>>>>>>>
>>>>>>> public class TableDemo extends JPanel {
>>>>>>>
>>>>>>>    public TableDemo() {
>>>>>>>        super(new GridLayout(1, 0));
>>>>>>>
>>>>>>>        final String[] columnNames = { "String", "Number" };
>>>>>>>        final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>>>                { "bbbb", new Integer(3) }, { "cccc", new Integer(2)
>>>>>>> },
>>>>>>>                { "dddd", new Integer(20) }, { "eeee", new
>>>>>>> Integer(10) } };
>>>>>>>        final JTable table = new JTable(data, columnNames);
>>>>>>>
>>>>>>>        table.**setPreferredScrollableViewport**Size(new
>>>>>>> Dimension(500, 400));
>>>>>>>        table.setFillsViewportHeight(**true);
>>>>>>>        TableModel dataModel = new AbstractTableModel() {
>>>>>>>
>>>>>>>            public int getColumnCount() {
>>>>>>>                return columnNames.length;
>>>>>>>            }
>>>>>>>            public int getRowCount() {
>>>>>>>                return data.length;
>>>>>>>            }
>>>>>>>            public Object getValueAt(int row, int col) {
>>>>>>>                return data[row][col];
>>>>>>>            }
>>>>>>>            public String getColumnName(int column) {
>>>>>>>                return columnNames[column];
>>>>>>>            }
>>>>>>>            public Class<?> getColumnClass(int c) {
>>>>>>>                return getValueAt(0, c).getClass();
>>>>>>>            }
>>>>>>>            public boolean isCellEditable(int row, int col) {
>>>>>>>                return col != 5;
>>>>>>>            }
>>>>>>>            public void setValueAt(Object aValue, int row, int
>>>>>>> column) {
>>>>>>>                data[row][column] = aValue;
>>>>>>>            }
>>>>>>>        };
>>>>>>>        table.setModel(dataModel);
>>>>>>>        TableRowSorter<TableModel> sorter = new
>>>>>>> TableRowSorter<TableModel>(
>>>>>>>                dataModel);
>>>>>>>        table.setRowSorter(sorter);
>>>>>>>
>>>>>>>        JScrollPane scrollPane = new JScrollPane(table);
>>>>>>>        add(scrollPane);
>>>>>>>    }
>>>>>>>
>>>>>>>    public static void main(String[] args) throws Exception {
>>>>>>>        javax.swing.SwingUtilities.**invokeAndWait(new Runnable() {
>>>>>>>            public void run() {
>>>>>>>                JFrame frame = new JFrame("SimpleTableDemo");
>>>>>>>                frame.**setDefaultCloseOperation(**
>>>>>>> JFrame.EXIT_ON_CLOSE);
>>>>>>>
>>>>>>>                TableDemo newContentPane = new TableDemo();
>>>>>>>                newContentPane.setOpaque(true)**;
>>>>>>>                frame.setContentPane(**newContentPane);
>>>>>>>
>>>>>>>                frame.pack();
>>>>>>>                frame.setVisible(true);
>>>>>>>            }
>>>>>>>        });
>>>>>>>    }
>>>>>>> }
>>>>>>>
>>>>>>> To reproduce the problem,
>>>>>>> please click on one cell from the "Number" column, delete all the
>>>>>>> content but do not press enter to quit editing status, then click the
>>>>>>> column title of "Number" column to sort, NPE will be thrown.
>>>>>>>
>>>>>>> The cause of this problem is when trying to quit editing with empty
>>>>>>> content of a cell  and also try to accept the partially edited value using
>>>>>>> stopCellEditing(), following two actions will be taken.
>>>>>>> 1, the cellEditor of current table will be set to null.
>>>>>>> 2, the value type of this column does not have a constructor to
>>>>>>> accept "Object[]" parameter, false will be returned.
>>>>>>> Then swing will try to cancel edition without accepting the
>>>>>>> partially edited value using cancelCellEditing() which will get null for
>>>>>>> the value of cellEditor thus lead to this NPE.
>>>>>>>
>>>>>>> The patch is trying to return earlier before the type compatibility
>>>>>>> check of partially edited values when empty cell values encountered.
>>>>>>>
>>>>>>> Cheers!
>>>>>>> - Jonathan
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> Yours Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120420/a1656195/attachment.html>

From luchsh at linux.vnet.ibm.com  Fri Apr 20 10:57:25 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 20 Apr 2012 18:57:25 +0800
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <4F9034D6.2040305@oracle.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com>
	<4F8FE02E.7070806@linux.vnet.ibm.com> <4F9034D6.2040305@oracle.com>
Message-ID: <CAC-GWLdCzrDK9iRF5eO9Y+O2z7cRq=y9_ZE9rOhcvVYBmNmDxA@mail.gmail.com>

Hi Pavel,

Thanks a lot for review.

Best regards!
- Jonathan

2012/4/19 Pavel Porvatov <pavel.porvatov at oracle.com>

> Hi Jonathan,
>
>  Hi Pavel,
>>
>> I found Util.invokeOnEDT in awt repository, and have updated the test
>> case, could you please take another look?
>> http://cr.openjdk.java.net/~**luchsh/7055065_2/<http://cr.openjdk.java.net/%7Eluchsh/7055065_2/>
>>
> The fix looks good. I approve it.
>
>
>> It indeed confused me when found the change in awt repository, will it be
>> merged to swing repository or is it a special change for testing
>> infrastructure so went to awt repository?
>>
> Swing repository is a legacy one and it's not used. I hope it will be
> removed soon to avoid such confusion.
>
> Regards, Pavel
>
>
>> Thanks and best regards!
>> - Jonathan
>>
>> On 04/19/2012 11:24 AM, Jonathan Lu wrote:
>>
>>> Hi Pavel,
>>>
>>> After a simple grep, I did not see any invokeOnEDT method from swing or
>>> 2d repository, has it been committed yet?
>>>
>>> Thanks and best regards!
>>> - Jonathan
>>>
>>> On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>>>
>>>> Hi Jonathan,
>>>>
>>>>> Hi Pavel,
>>>>>
>>>>> Thanks for reviewing, here's the webrev patch and automatic test.
>>>>> Could you please help to take another look?
>>>>> http://cr.openjdk.java.net/~**luchsh/7055065/<http://cr.openjdk.java.net/%7Eluchsh/7055065/>
>>>>>
>>>> The fix looks good. Could you please fix few minor changes:
>>>>
>>>> 1. Don't use full class names like javax.swing.SwingUtilities when
>>>> possible. I didn't find such rule in our Code Conventions but we follow
>>>> this rule.
>>>>
>>>> 2. Swap two lines please
>>>>  frame.setVisible(true);
>>>>  frame.setLocation(0, 0);
>>>> That's not critical for the test but we shouldn't provide bad examples
>>>>
>>>> 3. I've recently introduced the Util#invokeOnEDT method. It can
>>>> simplify your test and the getHeaderClickPoint and getCellClickPoint
>>>> methods can be removed.
>>>>
>>>> Regards, Pavel
>>>>
>>>>>
>>>>> Thanks & regards!
>>>>> - Jonathan
>>>>>
>>>>> On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>>>>>
>>>>>> Hi Jonathan,
>>>>>>
>>>>>> The fix looks good. Could you please write an automatic test, put it
>>>>>> into an appropriate place of repository and make a webrev with fix and test?
>>>>>>
>>>>>> Regards, Pavel
>>>>>>
>>>>>>> Hello swing-dev,
>>>>>>>
>>>>>>> I've got a patch for bug 7055065, can anybody please help to take a
>>>>>>> look?
>>>>>>> http://cr.openjdk.java.net/~**luchsh/7055065/<http://cr.openjdk.java.net/%7Eluchsh/7055065/>
>>>>>>>
>>>>>>> And also a simple test case for this issue here.
>>>>>>>
>>>>>>> /*
>>>>>>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>>>>>>> reserved.
>>>>>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>>>  *
>>>>>>>  * This code is free software; you can redistribute it and/or modify
>>>>>>> it
>>>>>>>  * under the terms of the GNU General Public License version 2 only,
>>>>>>> as
>>>>>>>  * published by the Free Software Foundation.
>>>>>>>  *
>>>>>>>  * This code is distributed in the hope that it will be useful, but
>>>>>>> WITHOUT
>>>>>>>  * ANY WARRANTY; without even the implied warranty of
>>>>>>> MERCHANTABILITY or
>>>>>>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>>>>>>> License
>>>>>>>  * version 2 for more details (a copy is included in the LICENSE
>>>>>>> file that
>>>>>>>  * accompanied this code).
>>>>>>>  *
>>>>>>>  * You should have received a copy of the GNU General Public License
>>>>>>> version
>>>>>>>  * 2 along with this work; if not, write to the Free Software
>>>>>>> Foundation,
>>>>>>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>>>  *
>>>>>>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
>>>>>>> 94065 USA
>>>>>>>  * or visit www.oracle.com if you need additional information or
>>>>>>> have any
>>>>>>>  * questions.
>>>>>>>  */
>>>>>>>
>>>>>>> /*
>>>>>>>  * Portions Copyright (c) 2012 IBM Corporation
>>>>>>>  */
>>>>>>>
>>>>>>> import javax.swing.JFrame;
>>>>>>> import javax.swing.JPanel;
>>>>>>> import javax.swing.JScrollPane;
>>>>>>> import javax.swing.JTable;
>>>>>>> import javax.swing.table.**AbstractTableModel;
>>>>>>> import javax.swing.table.TableModel;
>>>>>>> import javax.swing.table.**TableRowSorter;
>>>>>>> import java.awt.Dimension;
>>>>>>> import java.awt.GridLayout;
>>>>>>>
>>>>>>> public class TableDemo extends JPanel {
>>>>>>>
>>>>>>>    public TableDemo() {
>>>>>>>        super(new GridLayout(1, 0));
>>>>>>>
>>>>>>>        final String[] columnNames = { "String", "Number" };
>>>>>>>        final Object[][] data = { { "aaaa", new Integer(5) },
>>>>>>>                { "bbbb", new Integer(3) }, { "cccc", new Integer(2)
>>>>>>> },
>>>>>>>                { "dddd", new Integer(20) }, { "eeee", new
>>>>>>> Integer(10) } };
>>>>>>>        final JTable table = new JTable(data, columnNames);
>>>>>>>
>>>>>>>        table.**setPreferredScrollableViewport**Size(new
>>>>>>> Dimension(500, 400));
>>>>>>>        table.setFillsViewportHeight(**true);
>>>>>>>        TableModel dataModel = new AbstractTableModel() {
>>>>>>>
>>>>>>>            public int getColumnCount() {
>>>>>>>                return columnNames.length;
>>>>>>>            }
>>>>>>>            public int getRowCount() {
>>>>>>>                return data.length;
>>>>>>>            }
>>>>>>>            public Object getValueAt(int row, int col) {
>>>>>>>                return data[row][col];
>>>>>>>            }
>>>>>>>            public String getColumnName(int column) {
>>>>>>>                return columnNames[column];
>>>>>>>            }
>>>>>>>            public Class<?> getColumnClass(int c) {
>>>>>>>                return getValueAt(0, c).getClass();
>>>>>>>            }
>>>>>>>            public boolean isCellEditable(int row, int col) {
>>>>>>>                return col != 5;
>>>>>>>            }
>>>>>>>            public void setValueAt(Object aValue, int row, int
>>>>>>> column) {
>>>>>>>                data[row][column] = aValue;
>>>>>>>            }
>>>>>>>        };
>>>>>>>        table.setModel(dataModel);
>>>>>>>        TableRowSorter<TableModel> sorter = new
>>>>>>> TableRowSorter<TableModel>(
>>>>>>>                dataModel);
>>>>>>>        table.setRowSorter(sorter);
>>>>>>>
>>>>>>>        JScrollPane scrollPane = new JScrollPane(table);
>>>>>>>        add(scrollPane);
>>>>>>>    }
>>>>>>>
>>>>>>>    public static void main(String[] args) throws Exception {
>>>>>>>        javax.swing.SwingUtilities.**invokeAndWait(new Runnable() {
>>>>>>>            public void run() {
>>>>>>>                JFrame frame = new JFrame("SimpleTableDemo");
>>>>>>>                frame.**setDefaultCloseOperation(**
>>>>>>> JFrame.EXIT_ON_CLOSE);
>>>>>>>
>>>>>>>                TableDemo newContentPane = new TableDemo();
>>>>>>>                newContentPane.setOpaque(true)**;
>>>>>>>                frame.setContentPane(**newContentPane);
>>>>>>>
>>>>>>>                frame.pack();
>>>>>>>                frame.setVisible(true);
>>>>>>>            }
>>>>>>>        });
>>>>>>>    }
>>>>>>> }
>>>>>>>
>>>>>>> To reproduce the problem,
>>>>>>> please click on one cell from the "Number" column, delete all the
>>>>>>> content but do not press enter to quit editing status, then click the
>>>>>>> column title of "Number" column to sort, NPE will be thrown.
>>>>>>>
>>>>>>> The cause of this problem is when trying to quit editing with empty
>>>>>>> content of a cell  and also try to accept the partially edited value using
>>>>>>> stopCellEditing(), following two actions will be taken.
>>>>>>> 1, the cellEditor of current table will be set to null.
>>>>>>> 2, the value type of this column does not have a constructor to
>>>>>>> accept "Object[]" parameter, false will be returned.
>>>>>>> Then swing will try to cancel edition without accepting the
>>>>>>> partially edited value using cancelCellEditing() which will get null for
>>>>>>> the value of cellEditor thus lead to this NPE.
>>>>>>>
>>>>>>> The patch is trying to return earlier before the type compatibility
>>>>>>> check of partially edited values when empty cell values encountered.
>>>>>>>
>>>>>>> Cheers!
>>>>>>> - Jonathan
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120420/fd7ef6f5/attachment.html>

From pavel.porvatov at oracle.com  Fri Apr 20 13:40:02 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 20 Apr 2012 17:40:02 +0400
Subject: <Swing Dev> Review rquest for 7055065,
 NPE from JTable when quit editing with empty value in number culumns
In-Reply-To: <CAC-GWLdCzrDK9iRF5eO9Y+O2z7cRq=y9_ZE9rOhcvVYBmNmDxA@mail.gmail.com>
References: <4F86BE68.1010706@linux.vnet.ibm.com> <4F87F8F5.3000406@oracle.com>
	<4F8BD09E.6020209@linux.vnet.ibm.com> <4F8C07A8.7020509@oracle.com>
	<4F8F857A.4090007@linux.vnet.ibm.com>
	<4F8FE02E.7070806@linux.vnet.ibm.com> <4F9034D6.2040305@oracle.com>
	<CAC-GWLdCzrDK9iRF5eO9Y+O2z7cRq=y9_ZE9rOhcvVYBmNmDxA@mail.gmail.com>
Message-ID: <4F916732.3070408@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> Thanks a lot for review.
You are welcome! I marked bug 7055065 as "Fix Available". Not that on
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7055065
status will be updated later on.

Regards, Pavel
>
> Best regards!
> - Jonathan
>
> 2012/4/19 Pavel Porvatov <pavel.porvatov at oracle.com 
> <mailto:pavel.porvatov at oracle.com>>
>
>     Hi Jonathan,
>
>         Hi Pavel,
>
>         I found Util.invokeOnEDT in awt repository, and have updated
>         the test case, could you please take another look?
>         http://cr.openjdk.java.net/~luchsh/7055065_2/
>         <http://cr.openjdk.java.net/%7Eluchsh/7055065_2/>
>
>     The fix looks good. I approve it.
>
>
>         It indeed confused me when found the change in awt repository,
>         will it be merged to swing repository or is it a special
>         change for testing infrastructure so went to awt repository?
>
>     Swing repository is a legacy one and it's not used. I hope it will
>     be removed soon to avoid such confusion.
>
>     Regards, Pavel
>
>
>         Thanks and best regards!
>         - Jonathan
>
>         On 04/19/2012 11:24 AM, Jonathan Lu wrote:
>
>             Hi Pavel,
>
>             After a simple grep, I did not see any invokeOnEDT method
>             from swing or 2d repository, has it been committed yet?
>
>             Thanks and best regards!
>             - Jonathan
>
>             On 04/16/2012 07:51 PM, Pavel Porvatov wrote:
>
>                 Hi Jonathan,
>
>                     Hi Pavel,
>
>                     Thanks for reviewing, here's the webrev patch and
>                     automatic test. Could you please help to take
>                     another look?
>                     http://cr.openjdk.java.net/~luchsh/7055065/
>                     <http://cr.openjdk.java.net/%7Eluchsh/7055065/>
>
>                 The fix looks good. Could you please fix few minor
>                 changes:
>
>                 1. Don't use full class names like
>                 javax.swing.SwingUtilities when possible. I didn't
>                 find such rule in our Code Conventions but we follow
>                 this rule.
>
>                 2. Swap two lines please
>                  frame.setVisible(true);
>                  frame.setLocation(0, 0);
>                 That's not critical for the test but we shouldn't
>                 provide bad examples
>
>                 3. I've recently introduced the Util#invokeOnEDT
>                 method. It can simplify your test and the
>                 getHeaderClickPoint and getCellClickPoint methods can
>                 be removed.
>
>                 Regards, Pavel
>
>
>                     Thanks & regards!
>                     - Jonathan
>
>                     On 04/13/2012 05:59 PM, Pavel Porvatov wrote:
>
>                         Hi Jonathan,
>
>                         The fix looks good. Could you please write an
>                         automatic test, put it into an appropriate
>                         place of repository and make a webrev with fix
>                         and test?
>
>                         Regards, Pavel
>
>                             Hello swing-dev,
>
>                             I've got a patch for bug 7055065, can
>                             anybody please help to take a look?
>                             http://cr.openjdk.java.net/~luchsh/7055065/ <http://cr.openjdk.java.net/%7Eluchsh/7055065/>
>
>                             And also a simple test case for this issue
>                             here.
>
>                             /*
>                              * Copyright (c) 2012 Oracle and/or its
>                             affiliates. All rights reserved.
>                              * DO NOT ALTER OR REMOVE COPYRIGHT
>                             NOTICES OR THIS FILE HEADER.
>                              *
>                              * This code is free software; you can
>                             redistribute it and/or modify it
>                              * under the terms of the GNU General
>                             Public License version 2 only, as
>                              * published by the Free Software Foundation.
>                              *
>                              * This code is distributed in the hope
>                             that it will be useful, but WITHOUT
>                              * ANY WARRANTY; without even the implied
>                             warranty of MERCHANTABILITY or
>                              * FITNESS FOR A PARTICULAR PURPOSE.  See
>                             the GNU General Public License
>                              * version 2 for more details (a copy is
>                             included in the LICENSE file that
>                              * accompanied this code).
>                              *
>                              * You should have received a copy of the
>                             GNU General Public License version
>                              * 2 along with this work; if not, write
>                             to the Free Software Foundation,
>                              * Inc., 51 Franklin St, Fifth Floor,
>                             Boston, MA 02110-1301 USA.
>                              *
>                              * Please contact Oracle, 500 Oracle
>                             Parkway, Redwood Shores, CA 94065 USA
>                              * or visit www.oracle.com
>                             <http://www.oracle.com> if you need
>                             additional information or have any
>                              * questions.
>                              */
>
>                             /*
>                              * Portions Copyright (c) 2012 IBM Corporation
>                              */
>
>                             import javax.swing.JFrame;
>                             import javax.swing.JPanel;
>                             import javax.swing.JScrollPane;
>                             import javax.swing.JTable;
>                             import javax.swing.table.AbstractTableModel;
>                             import javax.swing.table.TableModel;
>                             import javax.swing.table.TableRowSorter;
>                             import java.awt.Dimension;
>                             import java.awt.GridLayout;
>
>                             public class TableDemo extends JPanel {
>
>                                public TableDemo() {
>                                    super(new GridLayout(1, 0));
>
>                                    final String[] columnNames = {
>                             "String", "Number" };
>                                    final Object[][] data = { { "aaaa",
>                             new Integer(5) },
>                                            { "bbbb", new Integer(3) },
>                             { "cccc", new Integer(2) },
>                                            { "dddd", new Integer(20)
>                             }, { "eeee", new Integer(10) } };
>                                    final JTable table = new
>                             JTable(data, columnNames);
>
>                                  
>                              table.setPreferredScrollableViewportSize(new
>                             Dimension(500, 400));
>                                    table.setFillsViewportHeight(true);
>                                    TableModel dataModel = new
>                             AbstractTableModel() {
>
>                                        public int getColumnCount() {
>                                            return columnNames.length;
>                                        }
>                                        public int getRowCount() {
>                                            return data.length;
>                                        }
>                                        public Object getValueAt(int
>                             row, int col) {
>                                            return data[row][col];
>                                        }
>                                        public String getColumnName(int
>                             column) {
>                                            return columnNames[column];
>                                        }
>                                        public Class<?>
>                             getColumnClass(int c) {
>                                            return getValueAt(0,
>                             c).getClass();
>                                        }
>                                        public boolean
>                             isCellEditable(int row, int col) {
>                                            return col != 5;
>                                        }
>                                        public void setValueAt(Object
>                             aValue, int row, int column) {
>                                            data[row][column] = aValue;
>                                        }
>                                    };
>                                    table.setModel(dataModel);
>                                    TableRowSorter<TableModel> sorter =
>                             new TableRowSorter<TableModel>(
>                                            dataModel);
>                                    table.setRowSorter(sorter);
>
>                                    JScrollPane scrollPane = new
>                             JScrollPane(table);
>                                    add(scrollPane);
>                                }
>
>                                public static void main(String[] args)
>                             throws Exception {
>                                  
>                              javax.swing.SwingUtilities.invokeAndWait(new
>                             Runnable() {
>                                        public void run() {
>                                            JFrame frame = new
>                             JFrame("SimpleTableDemo");
>                                          
>                              frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>
>                                            TableDemo newContentPane =
>                             new TableDemo();
>                                            newContentPane.setOpaque(true);
>                                          
>                              frame.setContentPane(newContentPane);
>
>                                            frame.pack();
>                                            frame.setVisible(true);
>                                        }
>                                    });
>                                }
>                             }
>
>                             To reproduce the problem,
>                             please click on one cell from the "Number"
>                             column, delete all the content but do not
>                             press enter to quit editing status, then
>                             click the column title of "Number" column
>                             to sort, NPE will be thrown.
>
>                             The cause of this problem is when trying
>                             to quit editing with empty content of a
>                             cell  and also try to accept the partially
>                             edited value using stopCellEditing(),
>                             following two actions will be taken.
>                             1, the cellEditor of current table will be
>                             set to null.
>                             2, the value type of this column does not
>                             have a constructor to accept "Object[]"
>                             parameter, false will be returned.
>                             Then swing will try to cancel edition
>                             without accepting the partially edited
>                             value using cancelCellEditing() which will
>                             get null for the value of cellEditor thus
>                             lead to this NPE.
>
>                             The patch is trying to return earlier
>                             before the type compatibility check of
>                             partially edited values when empty cell
>                             values encountered.
>
>                             Cheers!
>                             - Jonathan
>
>
>
>
>
>
>
>

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

From pavel.porvatov at oracle.com  Sat Apr 21 15:53:14 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 21 Apr 2012 19:53:14 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F79B601.8050905@oracle.com>
	<CAGUMyaToDYE1N7yvH=WUQFz25GJM0ARw590LbLM6QbtJCd=zJA@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
Message-ID: <4F92D7EA.6090504@oracle.com>

Hi Mario,

See comments below...
> 2012/4/16 Pavel Porvatov<pavel.porvatov at oracle.com>:
>
> Hello Pavel,
>
>>> About the test, I'm not sure if you need something more specific, but
>>> I was thinking to simply test if when isLightWeightPopupEnabled is set
>>> we create an heavy or lightweight popup, any other ideas?
>> That's a good way I think
> Here is the webrev:
>
> http://cr.openjdk.java.net/~neugens/6800513/
>
> Note that MEDIUM_WEIGHT is still used in some cases (PopupFactory.getPopup):
>
>          if (owner == null || invokerInHeavyWeightPopup(owner)) {
>              popupType = HEAVY_WEIGHT_POPUP;
>          }
>          else if (popupType == LIGHT_WEIGHT_POPUP&&
>                   !(contents instanceof JToolTip)&&
>                   !(contents instanceof JPopupMenu)) {
>              popupType = MEDIUM_WEIGHT_POPUP;
>          }
Yes, ToolTipManager uses MEDIUM_WEIGHT as well
> I'm not sure if we want to replace this as well with full HW (I would
> do it, in fact).
Actually we can't use HEAVY_WEIGHT always because there are some tricky 
usages. E.g. you can create a frame with some transparency. After that 
HEAVY_WEIGHT popups will be opaque, but LIGHT_WEIGHT will have the same 
transparency...
>
> Also I was thinking to have a very small optimization, if we are using
> an HW popups, there's no need to do this check:
>
>          // Check if the parent component is an option pane.  If so we need to
>          // force a heavy weight popup in order to have event dispatching work
>          // correctly.
>          Component c = owner;
>          while (c != null) {
>              if (c instanceof JComponent) {
>                  if (((JComponent)c).getClientProperty(
>                              PopupFactory_FORCE_HEAVYWEIGHT_POPUP) ==
> Boolean.TRUE) {
>                      popupType = HEAVY_WEIGHT_POPUP;
>                      break;
>                  }
>              } else if (c instanceof Window) {
>                  Window w = (Window) c;
>                  if (!w.isOpaque() || w.getOpacity()<  1 ||
> w.getShape() != null) {
>                      popupType = HEAVY_WEIGHT_POPUP;
>                      break;
>                  }
>              }
>              c = c.getParent();
>          }
>
> We can save a loop and a couple of instanceof checks (although I
> remember we proved with Jim and Phil that instanceof don't really
> introduce any speed penalization).
>
> What do you think?
I didn't catch details of your optimization. Note that we are not going 
to remove lightweight popups because of the described above transparency 
example. I see another optimization: because of the 
PopupFactory#getPopupType only "increases" weight we can replace all 
"popupType = HEAVY_WEIGHT_POPUP" by "return HEAVY_WEIGHT_POPUP". But I'd 
preffer don't touch code that doesn't relative to the fix

About the test:
1. Now is 2012 :)
2. You must access to Swing components only from the EDT (see 
clickOnComponent(final Component comp) and other methods)
3. Don't use long lines please
4. Could you please use simplest constractions when possible. E.g.
a.
frame.setMinimumSize(new Dimension(500, 500));
frame.pack();

can be replaced by
frame.setSize(...)

b.
loop
         final Map<String, Boolean> tests = new HashMap<>();
         tests.put("javax.swing.PopupFactory$HeavyWeightPopup", false);
         tests.put("javax.swing.PopupFactory$LightWeightPopup", true);

         for (final String test : tests.keySet()) {
can be replaced by two simple invocations

c. NoSuchFieldException, SecurityException, IllegalArgumentException, 
IllegalAccessException can be replaced by Exception

d.
robot.delay(50);
robot.mousePress(InputEvent.BUTTON1_MASK);
robot.delay(50);
Just use Robot#setAutoDelay

etc.

5. latch must be volitile. After test rewriting I think this variable 
can be removed at all

Note that tests should be readable and simplest as far as possible

Regards, Pavel


From pavel.porvatov at oracle.com  Sat Apr 21 16:23:04 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 21 Apr 2012 20:23:04 +0400
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F9038F3.5000703@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com> <4F9038F3.5000703@linux.vnet.ibm.com>
Message-ID: <4F92DEE8.9080800@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> see my comments below,
>
> On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> Here's another updated patch.
>>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>>
>>> My comments are inlined.
>> See below
>>>
>>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>> Hi Pavel,
>>>>>
>>>>> Here's the update patch,
>>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>>
>>>> Could you please explain one change in the JComponent.java:
>>>>
>>>> +    public void hide() {
>>>> +        if (isVisible()) {
>>>> +            super.hide();
>>>>
>>>> I think super.hide() should be invoked always. You must also add a 
>>>> javadoc to the new hide method (see {@inheritDoc} for details)
>>>
>>> Yes, the old patch may cause Component.isPacked not to be set 
>>> correctly, so moved super.hide() up.
>> Ok. The next question: I think we should use in "if (isVisible())" 
>> isShowing instead of isVisible. What do you think about that?
>
> I do not think so, since the problem here is that the repaining work 
> is not done after hiding a visible component, but the fields' status 
> of this hidden component have been correct, so has its parent. And 
> isShowing() 's implementation is just checking those fields in similar 
> way as isVisible() except for additional checks for the parent, whose 
> status also cannot reflect the visual picture from user's eyes. So in 
> my opinion, isShowing does not help with this case better than 
> isVisible but introduces more efforts of checking and branching. Pls 
> fix me if anything wrong with my understanding.
The java.awt.Component#isVisible method just returns value of the 
"visible" field, but isShowing reflects visible component on screen or 
not. E.g. almost all created components returns isVisible true, even if 
they were not showed on screen...

Regards, Pavel
>
> BTW, there's a stupid bug in previous patch caused by my local testing 
> cache was not cleaned up completely, terribly sorry for that and 
> here's the updated patch. http://cr.openjdk.java.net/~luchsh/7154030_6/
>
>>>
>>>>
>>>>
>>>>
>>>>>> 3. Could you please follow our code conventions?  (see 
>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>>
>>>>> Sorry for this problem, I was trying to keeping aligned with the 
>>>>> original style of JComponent.java, which I later realized to be 
>>>>> inappropriate. In the updated patch, code has been well formatted.
>>>>>
>>>>>> 4. Your test is not automatic one. I think you could use 
>>>>>> java.awt.Robot#createScreenCapture and analyze result of hide method.
>>>>>
>>>>> See the link, it should be automatic now.
>>>> The test should be corrected:
>>>> 1. All Swing components must be accessed from the EDT thread
>>> Updated in the new test.
>>>> 2. What is the reason to introduce the MyButton class? I think the 
>>>> test can be simplified, if you will use the 
>>>> Util#compareBufferedImages (see 
>>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>>> screen-shots between show/hide and compare them
>>>
>>> The reason of introducing MyButton class is to test the show/hide of 
>>> non-opaque component.
>> Why can't we use something like following:
>>                 button.setOpaque(false);
>>                 button.setBackground(new Color(255, 0, 0, 128));
> updated in new patch.
>>
>>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>>
>>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>>> SunToolkit#realSync method (many existing tests uses it)
>>>>
>>> Updated in new test.
>> Looks good. Could you please remove unnecessary "volatile" modifiers?
> done in the new patch.
>>
>> Regards, Pavel
>
> Regards
> - Jonathan

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

From luchsh at linux.vnet.ibm.com  Tue Apr 24 01:51:27 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 24 Apr 2012 09:51:27 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F7EA17D.1000902@linux.vnet.ibm.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com>
	<4F71D2AF.80307@oracle.com> <4F77C886.10507@linux.vnet.ibm.com>
	<4F7AE2BC.1080601@oracle.com> <4F7EA17D.1000902@linux.vnet.ibm.com>
Message-ID: <4F96071F.70304@linux.vnet.ibm.com>

Hi Pavel,

What do you think of this issue?

Regards!
- Jonathan

On 04/06/2012 03:55 PM, Jonathan Lu wrote:
> Hi Pavel
>
> On 04/03/2012 07:45 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>
>> I have several comments:
>> 1. containerParent instanceof JComboBox && containerParent != null
>> it is not necessary to check "containerParent != null" here
>>
>
> Yes, the null checking is not necessary here.
>
>> 2.
>> -            if (!interiorFocus && (state & SynthConstants.FOCUSED) 
>> != 0) {
>> +
>>                  focusSize = style.getClassSpecificIntValue(context,
>>                          "focus-line-width",1);
>> +            if (!interiorFocus && (state & SynthConstants.FOCUSED) 
>> != 0) {
>> I don't see here any changes
>>
>
> There is indeed some changes, please refer to following link of raw 
> text patch,
> http://cr.openjdk.java.net/~luchsh/7154030_3/jdk.patch
>
> The statement of retrieving focus-line-width property has been moved up.
>
>> 3. Could you please explain the following changes?
>> -            if (focusSize > 0) {
>> +            if (focusSize > 0 && (state & SynthConstants.FOCUSED) != 
>> 0) {
>> +                if (interiorFocus) {
>> +                    x += focusSize;
>> +                    y += focusSize;
>> +                    w -= 2 * focusSize;
>> +                    h -= 2 * focusSize;
>> +                } else {
>>
>
> I found the explanation of GTK geometry from following link
> http://svn.gnome.org/viewvc/gtk%2B/trunk/docs/widget_geometry.txt?view=markup 
>
>
> And above piece of code is trying to render interior focus separately 
> from exterior focus in the same way as 
> GTKPainter.paintButtonBackgroundImpl(), (GTKPainter.java: 363).
>
>>
>> I applied the patch and observe that focused JComboBox looks strange 
>> (see attachments):
>> a. Native focus uses solid line
> The patch only changed the size and position of focus rectangle not 
> the style, so it is using the unchanged focus style.
>> b. Native focused JComboBox paints focus rectangle across whole 
>> JComboBox
> It depends on the GTK version and ComboBox's 'style'.
>
> I made a simple native program for questions b.
>
> /*
>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but 
> WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file 
> that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License 
> version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 
> USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
>
> /*
>  * Portions Copyright (c) 2012 IBM Corporation
>  */
>
> #include <gtk/gtk.h>
>
> static gboolean delete_event(GtkWidget *widget, GdkEvent *event, 
> gpointer data ) {
>     return FALSE;
> }
>
> static void destroy(GtkWidget *widget, gpointer   data ) {
>     gtk_main_quit ();
> }
>
> int main(int argc, char *argv[]) {
>     GtkWidget *window;
>     GtkWidget *comboText;
>     GtkWidget *fixed;
>     GtkWidget *button;
>     GtkWidget *combo;
>     GtkWidget *comboEntry;
>     GList *glist = NULL;
>
>     gtk_init (&argc, &argv);
>
>     // init
>     window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
>     g_signal_connect (window, "delete-event", G_CALLBACK 
> (delete_event), NULL);
>     g_signal_connect (window, "destroy", G_CALLBACK (destroy), NULL);
>     gtk_container_set_border_width (GTK_CONTAINER (window), 10);
>
>     fixed = gtk_fixed_new();
>     gtk_container_add (GTK_CONTAINER (window), fixed);
>
>     //Button
>     button = gtk_button_new_with_label("GTK button");
>
>     // ComboBox using combo box text new()
>     comboText = gtk_combo_box_text_new();
>     gtk_combo_box_append_text(GTK_COMBO_BOX(comboText), "aaaaa");
>     gtk_combo_box_append_text(GTK_COMBO_BOX(comboText), 
> "GtkComboBoxText");
>     gtk_combo_box_set_active(GTK_COMBO_BOX(comboText), TRUE);
>
>     // ComboBox using deprecated combo
>     combo = gtk_combo_new();
>     glist = g_list_append (glist, "GtkCombo");
>     glist = g_list_append (glist, "GTK");
>     glist = g_list_append (glist, "theme");
>     gtk_combo_set_popdown_strings (GTK_COMBO (combo), glist);
>
>     // ComboBox using combo box entry new()
>     GtkTreeIter iter;
>     GtkTreeModel *list_store = gtk_list_store_new(1, G_TYPE_STRING);
>     gtk_list_store_clear(list_store);
>     gtk_list_store_append(GTK_LIST_STORE(list_store), &iter);
>     gtk_list_store_set(GTK_LIST_STORE(list_store), &iter, 
> G_TYPE_STRING, "123", -1);
>     comboEntry = gtk_combo_box_entry_new_with_model(list_store, 0);
>     gtk_combo_box_set_active(GTK_COMBO_BOX(comboEntry), TRUE);
>
>     // pack & show
>     gtk_fixed_put(GTK_FIXED(fixed), button, 0, 0);
>     gtk_fixed_put(GTK_FIXED(fixed), comboText, 0, 30);
>     gtk_fixed_put(GTK_FIXED(fixed), comboEntry, 0, 60);
>     gtk_fixed_put(GTK_FIXED(fixed), combo, 0, 90);
>
>     gtk_widget_show(button);
>     gtk_widget_show(comboText);
>     gtk_widget_show(combo);
>     gtk_widget_show(comboEntry);
>
>     gtk_widget_show (fixed);
>     gtk_widget_show (window);
>     gtk_main ();
>
>     // clean up
>     g_list_free(glist);
>
>     return 0;
> }
>
> Compile above code using following command and run the binary,
> gcc -Wall comboboxtest.c -o comboboxtest `pkg-config --cflags 
> gtk+-2.0` `pkg-config --libs gtk+-2.0`
>
> So far as I see from the docs and above demo, there're several ways 
> for native GTK application to create a ComboBox component,
> 1), gtk_combo_box_text_new() way will draw focus rectangle accross the 
> whole ComboBox component;
> 2), gtk_combo_box_entry_new_with_model() way will have two focus 
> points and draw the rectangle for each of them.
> 3), gtk_combo_new() way will draw focus rectangle on the text area 
> only not on the whole ComboBox.
>
> I think current swing's ComboBox is trying to follow condition 3), 
> right? if so, the focus size problem may not be a inconsistency 
> problem, does that make sense?
>
>> Regards, Pavel
>>> Hi Pavel,
>>>
>>> Here's the updated patch, including proposed solution for interior 
>>> focus.
>>> http://cr.openjdk.java.net/~luchsh/7155887_3/
>>>
>>> In the orginal code as I understood, focus is only paint when 
>>> !interiorFocus, in which case the background shadow and flatBox will 
>>> shrink a bit to corperate with the outer focus whose size is same as 
>>> the original component. My proposed solution is to shirink focus 
>>> line for interior focus, but keep the same way of !interorFocus.
>>>
>>> could you pls take a look?
>>>
>>> On 03/27/2012 10:46 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>
>>>> What do you think about another solution: can we set component 
>>>> state as SynthConstants.FOCUSED before paintTextBackground is 
>>>> invoked. Another solution is to set state as "focused" for ComboBox 
>>>> renderer like the following:
>>>>
>>>>         if ("ComboBox.renderer".equals(c.getName())) {
>>>>             for (Component comboBoxParent = c.getParent(); 
>>>> comboBoxParent != null; comboBoxParent = comboBoxParent.getParent()) {
>>>>                 if (comboBoxParent instanceof JComboBox){
>>>>                     if(comboBoxParent.hasFocus()){
>>>>                         state |= SynthConstants.FOCUSED;
>>>>                     }
>>>>                     break;
>>>>                 }
>>>>             }
>>>>         }
>>>> without other changes in GTKPainter.java (actually there is some 
>>>> problem with "interiorFocus", but it could be resolved....)
>>>>
>>>> See also my answers below.
>>>>> Hi Pavel,
>>>>>
>>>>> Thanks for review, here's the new patch and my answers are inlined.
>>>>> http://cr.openjdk.java.net/~luchsh/7155887_2/
>>>>>
>>>>> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>>>>>> Hi Jonathan,
>>>>>>> Hi Swing-dev,
>>>>>>>
>>>>>>> ComboBox on linux GTK L&F does not works as gtk native 
>>>>>>> applications, when get focused, the apperance of Java ComboBox 
>>>>>>> remains unchanged but native GTK ComboBox control will have a 
>>>>>>> outline to indicate it has got focused.
>>>>>>>
>>>>>>> The problem seems similar to bug
>>>>>>> 6947671 ( 
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>>>>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>>>>>> another bug
>>>>>>> 7155887 
>>>>>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>>>>>> was created for this issue,
>>>>>>>
>>>>>>> And here's the proposed patch to fix this problem,
>>>>>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>>>>>
>>>>>>> Could anybody please help to take a look?
>>>>>> I have several comments about the patch:
>>>>>>
>>>>>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get 
>>>>>> NPE here
>>>>> Yes, I've changed it to
>>>>>
>>>>> "ComboBox.renderer".equals(c.getName())
>>>>>
>>>>>>
>>>>>> 2.
>>>>>> +            for (Component comboBoxParent = c.getParent(); 
>>>>>> comboBoxParent != null; comboBoxParent = comboBoxParent
>>>>>> +                    .getParent()) {
>>>>>> +                if (comboBoxParent instanceof JComboBox
>>>>>> + && comboBoxParent.hasFocus()) {
>>>>>> +                    comboBoxFocused = true;
>>>>>> +                }
>>>>>> +            }
>>>>>>
>>>>>> I'm not sure we should do such deep parent investigation. Why 
>>>>>> don't you check first parent only?
>>>>>>
>>>>> javax.swing.CellRendererPane is inserted between the component and 
>>>>> renderer, so if check only the first parent, it will retrieve a 
>>>>> CellRendererPane object instead of JComboBox component. In the new 
>>>>> patch, I added a break when JComboBox is encounterred so to make 
>>>>> the effect similar to the first-parent-only approach.
>>>> I found out the following code (see 
>>>> com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
>>>>         if (c instanceof ListCellRenderer &&
>>>>                  container != null &&
>>>>                  container.getParent() instanceof JComboBox ) {
>>>>             ...
>>>>         }
>>>> I think we should use the same pattern
>>>>>
>>>>>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>>>>>> !comboBoxFocused)"
>>>>>> If you are going to ignore ENGINE.paintCachedImage when 
>>>>>> comboBoxFocused, then there is no need to invoke it at all
>>>>>>
>>>>> yes, in the new patch I've changed the order of these two checks.
>>>>>> 4. "if (comboBoxFocused || focusSize > 0)"
>>>>>> I'm not sure we should paint focus if focusSize == 0
>>>>>>
>>>>> I think there's no need to paint the focus if focusSize ==0, since 
>>>>> the focus width and height arguements passed to JNI method 
>>>>> native_paint_focus() will both be zero.
>>>> That's what I meant! (may be my phrase was not clear enough)
>>>> Your condition "if (comboBoxFocused || focusSize > 0)" allows to 
>>>> paint focus even if focusSize == 0...
>>>>
>>> Oh, sorry for my misunderstanding, the previous patch indeed got 
>>> such a problem, but it may not be in the new patch.
>>>> Regards, Pavel
>>>
>>> Thanks and best regards!
>>>
>>> - Jonathan
>>>
>>
>
> Thanks and best regards!
>
> - Jonathan
>



From luchsh at linux.vnet.ibm.com  Tue Apr 24 07:50:29 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 24 Apr 2012 15:50:29 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F92DEE8.9080800@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com> <4F9038F3.5000703@linux.vnet.ibm.com>
	<4F92DEE8.9080800@oracle.com>
Message-ID: <4F965B45.5080900@linux.vnet.ibm.com>

Hi Pavel,

Thanks for the explanation, I've updated the patch accordingly, could 
you please take a look?
http://cr.openjdk.java.net/~luchsh/7154030_7/

Best regards
-Jonathan

On 04/22/2012 12:23 AM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Pavel,
>>
>> see my comments below,
>>
>> On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> Here's another updated patch.
>>>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>>>
>>>> My comments are inlined.
>>> See below
>>>>
>>>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>> Hi Pavel,
>>>>>>
>>>>>> Here's the update patch,
>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>>>
>>>>> Could you please explain one change in the JComponent.java:
>>>>>
>>>>> +    public void hide() {
>>>>> +        if (isVisible()) {
>>>>> +            super.hide();
>>>>>
>>>>> I think super.hide() should be invoked always. You must also add a 
>>>>> javadoc to the new hide method (see {@inheritDoc} for details)
>>>>
>>>> Yes, the old patch may cause Component.isPacked not to be set 
>>>> correctly, so moved super.hide() up.
>>> Ok. The next question: I think we should use in "if (isVisible())" 
>>> isShowing instead of isVisible. What do you think about that?
>>
>> I do not think so, since the problem here is that the repaining work 
>> is not done after hiding a visible component, but the fields' status 
>> of this hidden component have been correct, so has its parent. And 
>> isShowing() 's implementation is just checking those fields in 
>> similar way as isVisible() except for additional checks for the 
>> parent, whose status also cannot reflect the visual picture from 
>> user's eyes. So in my opinion, isShowing does not help with this case 
>> better than isVisible but introduces more efforts of checking and 
>> branching. Pls fix me if anything wrong with my understanding.
> The java.awt.Component#isVisible method just returns value of the 
> "visible" field, but isShowing reflects visible component on screen or 
> not. E.g. almost all created components returns isVisible true, even 
> if they were not showed on screen...
>
> Regards, Pavel
>>
>> BTW, there's a stupid bug in previous patch caused by my local 
>> testing cache was not cleaned up completely, terribly sorry for that 
>> and here's the updated patch. 
>> http://cr.openjdk.java.net/~luchsh/7154030_6/
>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> 3. Could you please follow our code conventions?  (see 
>>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>>>
>>>>>> Sorry for this problem, I was trying to keeping aligned with the 
>>>>>> original style of JComponent.java, which I later realized to be 
>>>>>> inappropriate. In the updated patch, code has been well formatted.
>>>>>>
>>>>>>> 4. Your test is not automatic one. I think you could use 
>>>>>>> java.awt.Robot#createScreenCapture and analyze result of hide 
>>>>>>> method.
>>>>>>
>>>>>> See the link, it should be automatic now.
>>>>> The test should be corrected:
>>>>> 1. All Swing components must be accessed from the EDT thread
>>>> Updated in the new test.
>>>>> 2. What is the reason to introduce the MyButton class? I think the 
>>>>> test can be simplified, if you will use the 
>>>>> Util#compareBufferedImages (see 
>>>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>>>> screen-shots between show/hide and compare them
>>>>
>>>> The reason of introducing MyButton class is to test the show/hide 
>>>> of non-opaque component.
>>> Why can't we use something like following:
>>>                 button.setOpaque(false);
>>>                 button.setBackground(new Color(255, 0, 0, 128));
>> updated in new patch.
>>>
>>>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>>>
>>>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>>>> SunToolkit#realSync method (many existing tests uses it)
>>>>>
>>>> Updated in new test.
>>> Looks good. Could you please remove unnecessary "volatile" modifiers?
>> done in the new patch.
>>>
>>> Regards, Pavel
>>
>> Regards
>> - Jonathan
>


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

From pavel.porvatov at oracle.com  Tue Apr 24 08:31:12 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 24 Apr 2012 12:31:12 +0400
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F96071F.70304@linux.vnet.ibm.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com>
	<4F71D2AF.80307@oracle.com> <4F77C886.10507@linux.vnet.ibm.com>
	<4F7AE2BC.1080601@oracle.com> <4F7EA17D.1000902@linux.vnet.ibm.com>
	<4F96071F.70304@linux.vnet.ibm.com>
Message-ID: <4F9664D0.5040601@oracle.com>

Hi Jonathan,

I remember about that and I need some additional time for the review.

Regards, Pavel
> Hi Pavel,
>
> What do you think of this issue?
>
> Regards!
> - Jonathan
>
> On 04/06/2012 03:55 PM, Jonathan Lu wrote:
>> Hi Pavel
>>
>> On 04/03/2012 07:45 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>
>>> I have several comments:
>>> 1. containerParent instanceof JComboBox && containerParent != null
>>> it is not necessary to check "containerParent != null" here
>>>
>>
>> Yes, the null checking is not necessary here.
>>
>>> 2.
>>> -            if (!interiorFocus && (state & SynthConstants.FOCUSED) 
>>> != 0) {
>>> +
>>>                  focusSize = style.getClassSpecificIntValue(context,
>>>                          "focus-line-width",1);
>>> +            if (!interiorFocus && (state & SynthConstants.FOCUSED) 
>>> != 0) {
>>> I don't see here any changes
>>>
>>
>> There is indeed some changes, please refer to following link of raw 
>> text patch,
>> http://cr.openjdk.java.net/~luchsh/7154030_3/jdk.patch
>>
>> The statement of retrieving focus-line-width property has been moved up.
>>
>>> 3. Could you please explain the following changes?
>>> -            if (focusSize > 0) {
>>> +            if (focusSize > 0 && (state & SynthConstants.FOCUSED) 
>>> != 0) {
>>> +                if (interiorFocus) {
>>> +                    x += focusSize;
>>> +                    y += focusSize;
>>> +                    w -= 2 * focusSize;
>>> +                    h -= 2 * focusSize;
>>> +                } else {
>>>
>>
>> I found the explanation of GTK geometry from following link
>> http://svn.gnome.org/viewvc/gtk%2B/trunk/docs/widget_geometry.txt?view=markup 
>>
>>
>> And above piece of code is trying to render interior focus separately 
>> from exterior focus in the same way as 
>> GTKPainter.paintButtonBackgroundImpl(), (GTKPainter.java: 363).
>>
>>>
>>> I applied the patch and observe that focused JComboBox looks strange 
>>> (see attachments):
>>> a. Native focus uses solid line
>> The patch only changed the size and position of focus rectangle not 
>> the style, so it is using the unchanged focus style.
>>> b. Native focused JComboBox paints focus rectangle across whole 
>>> JComboBox
>> It depends on the GTK version and ComboBox's 'style'.
>>
>> I made a simple native program for questions b.
>>
>> /*
>>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but 
>> WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file 
>> that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License 
>> version
>>  * 2 along with this work; if not, write to the Free Software 
>> Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
>> 94065 USA
>>  * or visit www.oracle.com if you need additional information or have 
>> any
>>  * questions.
>>  */
>>
>> /*
>>  * Portions Copyright (c) 2012 IBM Corporation
>>  */
>>
>> #include <gtk/gtk.h>
>>
>> static gboolean delete_event(GtkWidget *widget, GdkEvent *event, 
>> gpointer data ) {
>>     return FALSE;
>> }
>>
>> static void destroy(GtkWidget *widget, gpointer   data ) {
>>     gtk_main_quit ();
>> }
>>
>> int main(int argc, char *argv[]) {
>>     GtkWidget *window;
>>     GtkWidget *comboText;
>>     GtkWidget *fixed;
>>     GtkWidget *button;
>>     GtkWidget *combo;
>>     GtkWidget *comboEntry;
>>     GList *glist = NULL;
>>
>>     gtk_init (&argc, &argv);
>>
>>     // init
>>     window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
>>     g_signal_connect (window, "delete-event", G_CALLBACK 
>> (delete_event), NULL);
>>     g_signal_connect (window, "destroy", G_CALLBACK (destroy), NULL);
>>     gtk_container_set_border_width (GTK_CONTAINER (window), 10);
>>
>>     fixed = gtk_fixed_new();
>>     gtk_container_add (GTK_CONTAINER (window), fixed);
>>
>>     //Button
>>     button = gtk_button_new_with_label("GTK button");
>>
>>     // ComboBox using combo box text new()
>>     comboText = gtk_combo_box_text_new();
>>     gtk_combo_box_append_text(GTK_COMBO_BOX(comboText), "aaaaa");
>>     gtk_combo_box_append_text(GTK_COMBO_BOX(comboText), 
>> "GtkComboBoxText");
>>     gtk_combo_box_set_active(GTK_COMBO_BOX(comboText), TRUE);
>>
>>     // ComboBox using deprecated combo
>>     combo = gtk_combo_new();
>>     glist = g_list_append (glist, "GtkCombo");
>>     glist = g_list_append (glist, "GTK");
>>     glist = g_list_append (glist, "theme");
>>     gtk_combo_set_popdown_strings (GTK_COMBO (combo), glist);
>>
>>     // ComboBox using combo box entry new()
>>     GtkTreeIter iter;
>>     GtkTreeModel *list_store = gtk_list_store_new(1, G_TYPE_STRING);
>>     gtk_list_store_clear(list_store);
>>     gtk_list_store_append(GTK_LIST_STORE(list_store), &iter);
>>     gtk_list_store_set(GTK_LIST_STORE(list_store), &iter, 
>> G_TYPE_STRING, "123", -1);
>>     comboEntry = gtk_combo_box_entry_new_with_model(list_store, 0);
>>     gtk_combo_box_set_active(GTK_COMBO_BOX(comboEntry), TRUE);
>>
>>     // pack & show
>>     gtk_fixed_put(GTK_FIXED(fixed), button, 0, 0);
>>     gtk_fixed_put(GTK_FIXED(fixed), comboText, 0, 30);
>>     gtk_fixed_put(GTK_FIXED(fixed), comboEntry, 0, 60);
>>     gtk_fixed_put(GTK_FIXED(fixed), combo, 0, 90);
>>
>>     gtk_widget_show(button);
>>     gtk_widget_show(comboText);
>>     gtk_widget_show(combo);
>>     gtk_widget_show(comboEntry);
>>
>>     gtk_widget_show (fixed);
>>     gtk_widget_show (window);
>>     gtk_main ();
>>
>>     // clean up
>>     g_list_free(glist);
>>
>>     return 0;
>> }
>>
>> Compile above code using following command and run the binary,
>> gcc -Wall comboboxtest.c -o comboboxtest `pkg-config --cflags 
>> gtk+-2.0` `pkg-config --libs gtk+-2.0`
>>
>> So far as I see from the docs and above demo, there're several ways 
>> for native GTK application to create a ComboBox component,
>> 1), gtk_combo_box_text_new() way will draw focus rectangle accross 
>> the whole ComboBox component;
>> 2), gtk_combo_box_entry_new_with_model() way will have two focus 
>> points and draw the rectangle for each of them.
>> 3), gtk_combo_new() way will draw focus rectangle on the text area 
>> only not on the whole ComboBox.
>>
>> I think current swing's ComboBox is trying to follow condition 3), 
>> right? if so, the focus size problem may not be a inconsistency 
>> problem, does that make sense?
>>
>>> Regards, Pavel
>>>> Hi Pavel,
>>>>
>>>> Here's the updated patch, including proposed solution for interior 
>>>> focus.
>>>> http://cr.openjdk.java.net/~luchsh/7155887_3/
>>>>
>>>> In the orginal code as I understood, focus is only paint when 
>>>> !interiorFocus, in which case the background shadow and flatBox 
>>>> will shrink a bit to corperate with the outer focus whose size is 
>>>> same as the original component. My proposed solution is to shirink 
>>>> focus line for interior focus, but keep the same way of !interorFocus.
>>>>
>>>> could you pls take a look?
>>>>
>>>> On 03/27/2012 10:46 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> What do you think about another solution: can we set component 
>>>>> state as SynthConstants.FOCUSED before paintTextBackground is 
>>>>> invoked. Another solution is to set state as "focused" for 
>>>>> ComboBox renderer like the following:
>>>>>
>>>>>         if ("ComboBox.renderer".equals(c.getName())) {
>>>>>             for (Component comboBoxParent = c.getParent(); 
>>>>> comboBoxParent != null; comboBoxParent = 
>>>>> comboBoxParent.getParent()) {
>>>>>                 if (comboBoxParent instanceof JComboBox){
>>>>>                     if(comboBoxParent.hasFocus()){
>>>>>                         state |= SynthConstants.FOCUSED;
>>>>>                     }
>>>>>                     break;
>>>>>                 }
>>>>>             }
>>>>>         }
>>>>> without other changes in GTKPainter.java (actually there is some 
>>>>> problem with "interiorFocus", but it could be resolved....)
>>>>>
>>>>> See also my answers below.
>>>>>> Hi Pavel,
>>>>>>
>>>>>> Thanks for review, here's the new patch and my answers are inlined.
>>>>>> http://cr.openjdk.java.net/~luchsh/7155887_2/
>>>>>>
>>>>>> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>>>>>>> Hi Jonathan,
>>>>>>>> Hi Swing-dev,
>>>>>>>>
>>>>>>>> ComboBox on linux GTK L&F does not works as gtk native 
>>>>>>>> applications, when get focused, the apperance of Java ComboBox 
>>>>>>>> remains unchanged but native GTK ComboBox control will have a 
>>>>>>>> outline to indicate it has got focused.
>>>>>>>>
>>>>>>>> The problem seems similar to bug
>>>>>>>> 6947671 ( 
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>>>>>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>>>>>>> another bug
>>>>>>>> 7155887 
>>>>>>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>>>>>>> was created for this issue,
>>>>>>>>
>>>>>>>> And here's the proposed patch to fix this problem,
>>>>>>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>>>>>>
>>>>>>>> Could anybody please help to take a look?
>>>>>>> I have several comments about the patch:
>>>>>>>
>>>>>>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get 
>>>>>>> NPE here
>>>>>> Yes, I've changed it to
>>>>>>
>>>>>> "ComboBox.renderer".equals(c.getName())
>>>>>>
>>>>>>>
>>>>>>> 2.
>>>>>>> +            for (Component comboBoxParent = c.getParent(); 
>>>>>>> comboBoxParent != null; comboBoxParent = comboBoxParent
>>>>>>> +                    .getParent()) {
>>>>>>> +                if (comboBoxParent instanceof JComboBox
>>>>>>> + && comboBoxParent.hasFocus()) {
>>>>>>> +                    comboBoxFocused = true;
>>>>>>> +                }
>>>>>>> +            }
>>>>>>>
>>>>>>> I'm not sure we should do such deep parent investigation. Why 
>>>>>>> don't you check first parent only?
>>>>>>>
>>>>>> javax.swing.CellRendererPane is inserted between the component 
>>>>>> and renderer, so if check only the first parent, it will retrieve 
>>>>>> a CellRendererPane object instead of JComboBox component. In the 
>>>>>> new patch, I added a break when JComboBox is encounterred so to 
>>>>>> make the effect similar to the first-parent-only approach.
>>>>> I found out the following code (see 
>>>>> com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
>>>>>         if (c instanceof ListCellRenderer &&
>>>>>                  container != null &&
>>>>>                  container.getParent() instanceof JComboBox ) {
>>>>>             ...
>>>>>         }
>>>>> I think we should use the same pattern
>>>>>>
>>>>>>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>>>>>>> !comboBoxFocused)"
>>>>>>> If you are going to ignore ENGINE.paintCachedImage when 
>>>>>>> comboBoxFocused, then there is no need to invoke it at all
>>>>>>>
>>>>>> yes, in the new patch I've changed the order of these two checks.
>>>>>>> 4. "if (comboBoxFocused || focusSize > 0)"
>>>>>>> I'm not sure we should paint focus if focusSize == 0
>>>>>>>
>>>>>> I think there's no need to paint the focus if focusSize ==0, 
>>>>>> since the focus width and height arguements passed to JNI method 
>>>>>> native_paint_focus() will both be zero.
>>>>> That's what I meant! (may be my phrase was not clear enough)
>>>>> Your condition "if (comboBoxFocused || focusSize > 0)" allows to 
>>>>> paint focus even if focusSize == 0...
>>>>>
>>>> Oh, sorry for my misunderstanding, the previous patch indeed got 
>>>> such a problem, but it may not be in the new patch.
>>>>> Regards, Pavel
>>>>
>>>> Thanks and best regards!
>>>>
>>>> - Jonathan
>>>>
>>>
>>
>> Thanks and best regards!
>>
>> - Jonathan
>>
>



From pavel.porvatov at oracle.com  Wed Apr 25 15:30:13 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 25 Apr 2012 19:30:13 +0400
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F965B45.5080900@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com> <4F9038F3.5000703@linux.vnet.ibm.com>
	<4F92DEE8.9080800@oracle.com> <4F965B45.5080900@linux.vnet.ibm.com>
Message-ID: <4F981885.2030806@oracle.com>

Hi Jonathan,

Looks good for me, I approve the fix.

Regards, Pavel
> Hi Pavel,
>
> Thanks for the explanation, I've updated the patch accordingly, could 
> you please take a look?
> http://cr.openjdk.java.net/~luchsh/7154030_7/
>
> Best regards
> -Jonathan
>
> On 04/22/2012 12:23 AM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> see my comments below,
>>>
>>> On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>> Hi Pavel,
>>>>>
>>>>> Here's another updated patch.
>>>>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>>>>
>>>>> My comments are inlined.
>>>> See below
>>>>>
>>>>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>>>>> Hi Jonathan,
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> Here's the update patch,
>>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>>>>
>>>>>> Could you please explain one change in the JComponent.java:
>>>>>>
>>>>>> +    public void hide() {
>>>>>> +        if (isVisible()) {
>>>>>> +            super.hide();
>>>>>>
>>>>>> I think super.hide() should be invoked always. You must also add 
>>>>>> a javadoc to the new hide method (see {@inheritDoc} for details)
>>>>>
>>>>> Yes, the old patch may cause Component.isPacked not to be set 
>>>>> correctly, so moved super.hide() up.
>>>> Ok. The next question: I think we should use in "if (isVisible())" 
>>>> isShowing instead of isVisible. What do you think about that?
>>>
>>> I do not think so, since the problem here is that the repaining work 
>>> is not done after hiding a visible component, but the fields' status 
>>> of this hidden component have been correct, so has its parent. And 
>>> isShowing() 's implementation is just checking those fields in 
>>> similar way as isVisible() except for additional checks for the 
>>> parent, whose status also cannot reflect the visual picture from 
>>> user's eyes. So in my opinion, isShowing does not help with this 
>>> case better than isVisible but introduces more efforts of checking 
>>> and branching. Pls fix me if anything wrong with my understanding.
>> The java.awt.Component#isVisible method just returns value of the 
>> "visible" field, but isShowing reflects visible component on screen 
>> or not. E.g. almost all created components returns isVisible true, 
>> even if they were not showed on screen...
>>
>> Regards, Pavel
>>>
>>> BTW, there's a stupid bug in previous patch caused by my local 
>>> testing cache was not cleaned up completely, terribly sorry for that 
>>> and here's the updated patch. 
>>> http://cr.openjdk.java.net/~luchsh/7154030_6/
>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 3. Could you please follow our code conventions?  (see 
>>>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>>>>
>>>>>>> Sorry for this problem, I was trying to keeping aligned with the 
>>>>>>> original style of JComponent.java, which I later realized to be 
>>>>>>> inappropriate. In the updated patch, code has been well formatted.
>>>>>>>
>>>>>>>> 4. Your test is not automatic one. I think you could use 
>>>>>>>> java.awt.Robot#createScreenCapture and analyze result of hide 
>>>>>>>> method.
>>>>>>>
>>>>>>> See the link, it should be automatic now.
>>>>>> The test should be corrected:
>>>>>> 1. All Swing components must be accessed from the EDT thread
>>>>> Updated in the new test.
>>>>>> 2. What is the reason to introduce the MyButton class? I think 
>>>>>> the test can be simplified, if you will use the 
>>>>>> Util#compareBufferedImages (see 
>>>>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>>>>> screen-shots between show/hide and compare them
>>>>>
>>>>> The reason of introducing MyButton class is to test the show/hide 
>>>>> of non-opaque component.
>>>> Why can't we use something like following:
>>>>                 button.setOpaque(false);
>>>>                 button.setBackground(new Color(255, 0, 0, 128));
>>> updated in new patch.
>>>>
>>>>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>>>>
>>>>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>>>>> SunToolkit#realSync method (many existing tests uses it)
>>>>>>
>>>>> Updated in new test.
>>>> Looks good. Could you please remove unnecessary "volatile" modifiers?
>>> done in the new patch.
>>>>
>>>> Regards, Pavel
>>>
>>> Regards
>>> - Jonathan
>>
>
>

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

From littlee at linux.vnet.ibm.com  Thu Apr 26 04:47:37 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Thu, 26 Apr 2012 12:47:37 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F965B45.5080900@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com> <4F9038F3.5000703@linux.vnet.ibm.com>
	<4F92DEE8.9080800@oracle.com> <4F965B45.5080900@linux.vnet.ibm.com>
Message-ID: <4F98D369.1070407@linux.vnet.ibm.com>

Hi Jonathan,

The patch has been committed @

Changeset: 340cda7e1430
Author:    luchsh
Date:      2012-04-26 12:39 +0800
URL:http://hg.openjdk.java.net/jdk8/awt/jdk/rev/340cda7e1430

7154030: java.awt.Component.hide() does not repaint parent component
Reviewed-by: rupashka


Please verify it.

Hi Pavel,

Thank you for reviewing it.


On 04/24/2012 03:50 PM, Jonathan Lu wrote:
> Hi Pavel,
>
> Thanks for the explanation, I've updated the patch accordingly, could 
> you please take a look?
> http://cr.openjdk.java.net/~luchsh/7154030_7/
>
> Best regards
> -Jonathan
>
> On 04/22/2012 12:23 AM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> see my comments below,
>>>
>>> On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
>>>> Hi Jonathan,
>>>>> Hi Pavel,
>>>>>
>>>>> Here's another updated patch.
>>>>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>>>>
>>>>> My comments are inlined.
>>>> See below
>>>>>
>>>>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>>>>> Hi Jonathan,
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> Here's the update patch,
>>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>>>>
>>>>>> Could you please explain one change in the JComponent.java:
>>>>>>
>>>>>> +    public void hide() {
>>>>>> +        if (isVisible()) {
>>>>>> +            super.hide();
>>>>>>
>>>>>> I think super.hide() should be invoked always. You must also add 
>>>>>> a javadoc to the new hide method (see {@inheritDoc} for details)
>>>>>
>>>>> Yes, the old patch may cause Component.isPacked not to be set 
>>>>> correctly, so moved super.hide() up.
>>>> Ok. The next question: I think we should use in "if (isVisible())" 
>>>> isShowing instead of isVisible. What do you think about that?
>>>
>>> I do not think so, since the problem here is that the repaining work 
>>> is not done after hiding a visible component, but the fields' status 
>>> of this hidden component have been correct, so has its parent. And 
>>> isShowing() 's implementation is just checking those fields in 
>>> similar way as isVisible() except for additional checks for the 
>>> parent, whose status also cannot reflect the visual picture from 
>>> user's eyes. So in my opinion, isShowing does not help with this 
>>> case better than isVisible but introduces more efforts of checking 
>>> and branching. Pls fix me if anything wrong with my understanding.
>> The java.awt.Component#isVisible method just returns value of the 
>> "visible" field, but isShowing reflects visible component on screen 
>> or not. E.g. almost all created components returns isVisible true, 
>> even if they were not showed on screen...
>>
>> Regards, Pavel
>>>
>>> BTW, there's a stupid bug in previous patch caused by my local 
>>> testing cache was not cleaned up completely, terribly sorry for that 
>>> and here's the updated patch. 
>>> http://cr.openjdk.java.net/~luchsh/7154030_6/
>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 3. Could you please follow our code conventions?  (see 
>>>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>>>>
>>>>>>> Sorry for this problem, I was trying to keeping aligned with the 
>>>>>>> original style of JComponent.java, which I later realized to be 
>>>>>>> inappropriate. In the updated patch, code has been well formatted.
>>>>>>>
>>>>>>>> 4. Your test is not automatic one. I think you could use 
>>>>>>>> java.awt.Robot#createScreenCapture and analyze result of hide 
>>>>>>>> method.
>>>>>>>
>>>>>>> See the link, it should be automatic now.
>>>>>> The test should be corrected:
>>>>>> 1. All Swing components must be accessed from the EDT thread
>>>>> Updated in the new test.
>>>>>> 2. What is the reason to introduce the MyButton class? I think 
>>>>>> the test can be simplified, if you will use the 
>>>>>> Util#compareBufferedImages (see 
>>>>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>>>>> screen-shots between show/hide and compare them
>>>>>
>>>>> The reason of introducing MyButton class is to test the show/hide 
>>>>> of non-opaque component.
>>>> Why can't we use something like following:
>>>>                 button.setOpaque(false);
>>>>                 button.setBackground(new Color(255, 0, 0, 128));
>>> updated in new patch.
>>>>
>>>>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>>>>
>>>>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>>>>> SunToolkit#realSync method (many existing tests uses it)
>>>>>>
>>>>> Updated in new test.
>>>> Looks good. Could you please remove unnecessary "volatile" modifiers?
>>> done in the new patch.
>>>>
>>>> Regards, Pavel
>>>
>>> Regards
>>> - Jonathan
>>
>
>


-- 
Yours Charles

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

From luchsh at linux.vnet.ibm.com  Thu Apr 26 05:33:51 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 26 Apr 2012 13:33:51 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F981885.2030806@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com> <4F9038F3.5000703@linux.vnet.ibm.com>
	<4F92DEE8.9080800@oracle.com> <4F965B45.5080900@linux.vnet.ibm.com>
	<4F981885.2030806@oracle.com>
Message-ID: <4F98DE3F.8070908@linux.vnet.ibm.com>

Thanks, Pavel

Best regards
- Jonathan

On 04/25/2012 11:30 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>
> Looks good for me, I approve the fix.
>
> Regards, Pavel
>> Hi Pavel,
>>
>> Thanks for the explanation, I've updated the patch accordingly, could 
>> you please take a look?
>> http://cr.openjdk.java.net/~luchsh/7154030_7/
>>
>> Best regards
>> -Jonathan
>>
>> On 04/22/2012 12:23 AM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> see my comments below,
>>>>
>>>> On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>> Hi Pavel,
>>>>>>
>>>>>> Here's another updated patch.
>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>>>>>
>>>>>> My comments are inlined.
>>>>> See below
>>>>>>
>>>>>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>>>>>> Hi Jonathan,
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>> Here's the update patch,
>>>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>>>>>
>>>>>>> Could you please explain one change in the JComponent.java:
>>>>>>>
>>>>>>> +    public void hide() {
>>>>>>> +        if (isVisible()) {
>>>>>>> +            super.hide();
>>>>>>>
>>>>>>> I think super.hide() should be invoked always. You must also add 
>>>>>>> a javadoc to the new hide method (see {@inheritDoc} for details)
>>>>>>
>>>>>> Yes, the old patch may cause Component.isPacked not to be set 
>>>>>> correctly, so moved super.hide() up.
>>>>> Ok. The next question: I think we should use in "if (isVisible())" 
>>>>> isShowing instead of isVisible. What do you think about that?
>>>>
>>>> I do not think so, since the problem here is that the repaining 
>>>> work is not done after hiding a visible component, but the fields' 
>>>> status of this hidden component have been correct, so has its 
>>>> parent. And isShowing() 's implementation is just checking those 
>>>> fields in similar way as isVisible() except for additional checks 
>>>> for the parent, whose status also cannot reflect the visual picture 
>>>> from user's eyes. So in my opinion, isShowing does not help with 
>>>> this case better than isVisible but introduces more efforts of 
>>>> checking and branching. Pls fix me if anything wrong with my 
>>>> understanding.
>>> The java.awt.Component#isVisible method just returns value of the 
>>> "visible" field, but isShowing reflects visible component on screen 
>>> or not. E.g. almost all created components returns isVisible true, 
>>> even if they were not showed on screen...
>>>
>>> Regards, Pavel
>>>>
>>>> BTW, there's a stupid bug in previous patch caused by my local 
>>>> testing cache was not cleaned up completely, terribly sorry for 
>>>> that and here's the updated patch. 
>>>> http://cr.openjdk.java.net/~luchsh/7154030_6/
>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 3. Could you please follow our code conventions?  (see 
>>>>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>>>>>
>>>>>>>> Sorry for this problem, I was trying to keeping aligned with 
>>>>>>>> the original style of JComponent.java, which I later realized 
>>>>>>>> to be inappropriate. In the updated patch, code has been well 
>>>>>>>> formatted.
>>>>>>>>
>>>>>>>>> 4. Your test is not automatic one. I think you could use 
>>>>>>>>> java.awt.Robot#createScreenCapture and analyze result of hide 
>>>>>>>>> method.
>>>>>>>>
>>>>>>>> See the link, it should be automatic now.
>>>>>>> The test should be corrected:
>>>>>>> 1. All Swing components must be accessed from the EDT thread
>>>>>> Updated in the new test.
>>>>>>> 2. What is the reason to introduce the MyButton class? I think 
>>>>>>> the test can be simplified, if you will use the 
>>>>>>> Util#compareBufferedImages (see 
>>>>>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>>>>>> screen-shots between show/hide and compare them
>>>>>>
>>>>>> The reason of introducing MyButton class is to test the show/hide 
>>>>>> of non-opaque component.
>>>>> Why can't we use something like following:
>>>>>                 button.setOpaque(false);
>>>>>                 button.setBackground(new Color(255, 0, 0, 128));
>>>> updated in new patch.
>>>>>
>>>>>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>>>>>
>>>>>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>>>>>> SunToolkit#realSync method (many existing tests uses it)
>>>>>>>
>>>>>> Updated in new test.
>>>>> Looks good. Could you please remove unnecessary "volatile" modifiers?
>>>> done in the new patch.
>>>>>
>>>>> Regards, Pavel
>>>>
>>>> Regards
>>>> - Jonathan
>>>
>>
>>
>

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

From luchsh at linux.vnet.ibm.com  Thu Apr 26 05:37:38 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 26 Apr 2012 13:37:38 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F98D369.1070407@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
	<4F71E3B9.9090103@oracle.com> <4F7EB5B6.6090009@linux.vnet.ibm.com>
	<4F8589DA.5000600@oracle.com> <4F86B92D.9080900@linux.vnet.ibm.com>
	<4F880273.3080704@oracle.com> <4F9038F3.5000703@linux.vnet.ibm.com>
	<4F92DEE8.9080800@oracle.com> <4F965B45.5080900@linux.vnet.ibm.com>
	<4F98D369.1070407@linux.vnet.ibm.com>
Message-ID: <4F98DF22.200@linux.vnet.ibm.com>

Verified!

Thanks, Charles

Regards

-Jonathan

On 04/26/2012 12:47 PM, Charles Lee wrote:
> Hi Jonathan,
>
> The patch has been committed @
>
> Changeset: 340cda7e1430
> Author:    luchsh
> Date:      2012-04-26 12:39 +0800
> URL:http://hg.openjdk.java.net/jdk8/awt/jdk/rev/340cda7e1430
>
> 7154030: java.awt.Component.hide() does not repaint parent component
> Reviewed-by: rupashka
>
> Please verify it.
>
> Hi Pavel,
>
> Thank you for reviewing it.
>
>
> On 04/24/2012 03:50 PM, Jonathan Lu wrote:
>> Hi Pavel,
>>
>> Thanks for the explanation, I've updated the patch accordingly, could 
>> you please take a look?
>> http://cr.openjdk.java.net/~luchsh/7154030_7/
>>
>> Best regards
>> -Jonathan
>>
>> On 04/22/2012 12:23 AM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Pavel,
>>>>
>>>> see my comments below,
>>>>
>>>> On 04/13/2012 06:39 PM, Pavel Porvatov wrote:
>>>>> Hi Jonathan,
>>>>>> Hi Pavel,
>>>>>>
>>>>>> Here's another updated patch.
>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_5/
>>>>>>
>>>>>> My comments are inlined.
>>>>> See below
>>>>>>
>>>>>> On 04/11/2012 09:40 PM, Pavel Porvatov wrote:
>>>>>>> Hi Jonathan,
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>> Here's the update patch,
>>>>>>>> http://cr.openjdk.java.net/~luchsh/7154030_4/
>>>>>>>>
>>>>>>> Could you please explain one change in the JComponent.java:
>>>>>>>
>>>>>>> +    public void hide() {
>>>>>>> +        if (isVisible()) {
>>>>>>> +            super.hide();
>>>>>>>
>>>>>>> I think super.hide() should be invoked always. You must also add 
>>>>>>> a javadoc to the new hide method (see {@inheritDoc} for details)
>>>>>>
>>>>>> Yes, the old patch may cause Component.isPacked not to be set 
>>>>>> correctly, so moved super.hide() up.
>>>>> Ok. The next question: I think we should use in "if (isVisible())" 
>>>>> isShowing instead of isVisible. What do you think about that?
>>>>
>>>> I do not think so, since the problem here is that the repaining 
>>>> work is not done after hiding a visible component, but the fields' 
>>>> status of this hidden component have been correct, so has its 
>>>> parent. And isShowing() 's implementation is just checking those 
>>>> fields in similar way as isVisible() except for additional checks 
>>>> for the parent, whose status also cannot reflect the visual picture 
>>>> from user's eyes. So in my opinion, isShowing does not help with 
>>>> this case better than isVisible but introduces more efforts of 
>>>> checking and branching. Pls fix me if anything wrong with my 
>>>> understanding.
>>> The java.awt.Component#isVisible method just returns value of the 
>>> "visible" field, but isShowing reflects visible component on screen 
>>> or not. E.g. almost all created components returns isVisible true, 
>>> even if they were not showed on screen...
>>>
>>> Regards, Pavel
>>>>
>>>> BTW, there's a stupid bug in previous patch caused by my local 
>>>> testing cache was not cleaned up completely, terribly sorry for 
>>>> that and here's the updated patch. 
>>>> http://cr.openjdk.java.net/~luchsh/7154030_6/
>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 3. Could you please follow our code conventions?  (see 
>>>>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)
>>>>>>>>>
>>>>>>>> Sorry for this problem, I was trying to keeping aligned with 
>>>>>>>> the original style of JComponent.java, which I later realized 
>>>>>>>> to be inappropriate. In the updated patch, code has been well 
>>>>>>>> formatted.
>>>>>>>>
>>>>>>>>> 4. Your test is not automatic one. I think you could use 
>>>>>>>>> java.awt.Robot#createScreenCapture and analyze result of hide 
>>>>>>>>> method.
>>>>>>>>
>>>>>>>> See the link, it should be automatic now.
>>>>>>> The test should be corrected:
>>>>>>> 1. All Swing components must be accessed from the EDT thread
>>>>>> Updated in the new test.
>>>>>>> 2. What is the reason to introduce the MyButton class? I think 
>>>>>>> the test can be simplified, if you will use the 
>>>>>>> Util#compareBufferedImages (see 
>>>>>>> test\javax\swing\regtesthelpers\Util.java) method. Just take 
>>>>>>> screen-shots between show/hide and compare them
>>>>>>
>>>>>> The reason of introducing MyButton class is to test the show/hide 
>>>>>> of non-opaque component.
>>>>> Why can't we use something like following:
>>>>>                 button.setOpaque(false);
>>>>>                 button.setBackground(new Color(255, 0, 0, 128));
>>>> updated in new patch.
>>>>>
>>>>>> I've changed pixel comparison to Util#compareBufferedImages approach.
>>>>>>
>>>>>>> 3. Thread.sleep(milisecond) should be replaced by the 
>>>>>>> SunToolkit#realSync method (many existing tests uses it)
>>>>>>>
>>>>>> Updated in new test.
>>>>> Looks good. Could you please remove unnecessary "volatile" modifiers?
>>>> done in the new patch.
>>>>>
>>>>> Regards, Pavel
>>>>
>>>> Regards
>>>> - Jonathan
>>>
>>
>>
>
>
> -- 
> Yours Charles

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

From ptisnovs at redhat.com  Fri Apr 27 09:14:58 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Fri, 27 Apr 2012 11:14:58 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
Message-ID: <4F9A6392.1040002@redhat.com>

Hi,

I think there's a bug in a TitledBorder class. According to JavaDoc
the methods getTitleColor() and getTitleFont() should use look&feel
settings when nothing is explicitly changed by constructor/setters:

<javadoc>
If the border, font, or color property values are not specified in the constuctor or by invoking the appropriate set
methods, the property values will be defined by the current look and feel, using the following property names in the
Defaults Table:
"TitledBorder.border"
"TitledBorder.font"
"TitledBorder.titleColor"
</javadoc>

This behaviour were removed by following changeset:
changeset:   2529:d062afbe2107
user:        malenkov
date:        Thu Jul 01 18:09:45 2010 +0400
summary:     4129681: Cannot get a title border to display its label as disabled


Here is a webrew which contains fix for this issue:
http://cr.openjdk.java.net/~ptisnovs/TitledBorder/

Can anybody please review this fix?
(I'd like to push the same change to OpenJDK7 too it it will be reviewed & accepted)

Thank you in advance,
Pavel Tisnovsky


From alexandr.scherbatiy at oracle.com  Fri Apr 27 10:52:33 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 27 Apr 2012 14:52:33 +0400
Subject: <Swing Dev> [8] Review request for 7024963: Notepad demo: remove
 non-translatable resources from Notepad.properties file
Message-ID: <4F9A7A71.9090407@oracle.com>

Hello,

This is a request to review the fix for the issue:
7024963 Notepad demo: remove non-translatable resources from 
Notepad.properties file
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024963

The webrev is http://cr.openjdk.java.net/~alexsch/7024963/webrev.00

The non-translatable properties are moved to the file system.properties.
The getProperty() method is used now instead of the getResourceString() 
where non-translatable resources are used.


Thanks,
Alexandr.



From alexandr.scherbatiy at oracle.com  Fri Apr 27 11:39:42 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 27 Apr 2012 15:39:42 +0400
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4F9A6392.1040002@redhat.com>
References: <4F9A6392.1040002@redhat.com>
Message-ID: <4F9A857E.80505@oracle.com>


   Hi  Pavel,

   Thank you for the bug investigation.

   Could you create an issue on it?
   Could you also check that the issue 4129681 is not reproduced with 
your fix? At least try to run the 
test/javax/swing/border/Test4129681.java test.

   Thanks,
   Alexandr.



On 4/27/2012 1:14 PM, Pavel Tisnovsky wrote:
> Hi,
>
> I think there's a bug in a TitledBorder class. According to JavaDoc
> the methods getTitleColor() and getTitleFont() should use look&feel
> settings when nothing is explicitly changed by constructor/setters:
>
> <javadoc>
> If the border, font, or color property values are not specified in the constuctor or by invoking the appropriate set
> methods, the property values will be defined by the current look and feel, using the following property names in the
> Defaults Table:
> "TitledBorder.border"
> "TitledBorder.font"
> "TitledBorder.titleColor"
> </javadoc>
>
> This behaviour were removed by following changeset:
> changeset:   2529:d062afbe2107
> user:        malenkov
> date:        Thu Jul 01 18:09:45 2010 +0400
> summary:     4129681: Cannot get a title border to display its label as disabled
>
>
> Here is a webrew which contains fix for this issue:
> http://cr.openjdk.java.net/~ptisnovs/TitledBorder/
>
> Can anybody please review this fix?
> (I'd like to push the same change to OpenJDK7 too it it will be reviewed&  accepted)
>
> Thank you in advance,
> Pavel Tisnovsky



From alexandr.scherbatiy at oracle.com  Fri Apr 27 14:41:00 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 27 Apr 2012 18:41:00 +0400
Subject: <Swing Dev> [7] Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
Message-ID: <4F9AAFFC.5050201@oracle.com>


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

  This is a request from the NLS team to backport the issue 7093156 to 
JDK 7.
  The original JDK 8 patch is rejected when it is applied to JDK 8 
because the property files are slightly different between JDK 7 and JDK 8.

  So the UIDefaults class is just copied to the JDK 7 and property files 
are regenerated.

  The properties from the following folders are updated:
    src/share/classes/com/sun/java/swing/plaf/gtk
    src/share/classes/com/sun/swing/internal/plaf

  According to the request from the NLS team the properties, mnemonics 
and mnemonic indexes are unified from the
    xxxText, xxxMnemonic and xxxMnemonicIndex to xxx.titleAndMnemonic 
(different patterns with the different suffixes are checked).

  The TextAndMnemonicHashMap class is added to the UIDefaults class that 
now parse requested keys and returns values from the unified properties.

Thanks,
Alexandr.





From ptisnovs at redhat.com  Fri Apr 27 14:44:49 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Fri, 27 Apr 2012 16:44:49 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4F9A857E.80505@oracle.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
Message-ID: <4F9AB0E1.8050303@redhat.com>

Alexander Scherbatiy wrote:
> 
>   Hi  Pavel,
> 
>   Thank you for the bug investigation.

Hi Alexander,

thank you for your answer!

> 
>   Could you create an issue on it?

well I'm not sure what exactly you mean.
To file a new bug or something like this?
(I did not do it yet - somebody else ever created a bug #id for me ;-)

>   Could you also check that the issue 4129681 is not reproduced with
> your fix? At least try to run the
> test/javax/swing/border/Test4129681.java test.

this test and other swing tests don't seem to be affected by the fix.

> 
>   Thanks,
>   Alexandr.
> 
> 
> 
> On 4/27/2012 1:14 PM, Pavel Tisnovsky wrote:
>> Hi,
>>
>> I think there's a bug in a TitledBorder class. According to JavaDoc
>> the methods getTitleColor() and getTitleFont() should use look&feel
>> settings when nothing is explicitly changed by constructor/setters:
>>
>> <javadoc>
>> If the border, font, or color property values are not specified in the
>> constuctor or by invoking the appropriate set
>> methods, the property values will be defined by the current look and
>> feel, using the following property names in the
>> Defaults Table:
>> "TitledBorder.border"
>> "TitledBorder.font"
>> "TitledBorder.titleColor"
>> </javadoc>
>>
>> This behaviour were removed by following changeset:
>> changeset:   2529:d062afbe2107
>> user:        malenkov
>> date:        Thu Jul 01 18:09:45 2010 +0400
>> summary:     4129681: Cannot get a title border to display its label
>> as disabled
>>
>>
>> Here is a webrew which contains fix for this issue:
>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder/
>>
>> Can anybody please review this fix?
>> (I'd like to push the same change to OpenJDK7 too it it will be
>> reviewed&  accepted)
>>
>> Thank you in advance,
>> Pavel Tisnovsky
> 



From pavel.porvatov at oracle.com  Fri Apr 27 15:12:56 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 27 Apr 2012 19:12:56 +0400
Subject: <Swing Dev> [8] Review request for 7024963: Notepad demo:
 remove non-translatable resources from Notepad.properties file
In-Reply-To: <4F9A7A71.9090407@oracle.com>
References: <4F9A7A71.9090407@oracle.com>
Message-ID: <4F9AB778.8050801@oracle.com>

Hi Alexander,

That's a bad practice to use "catch (Throwable e)" and we should avoid 
that. There are a lot reasons, here is one of them:
http://www.javatuning.com/why-catch-throwable-is-evil-real-life-story/

Why can't we inline all nonlocalizable strings? After that the 
"tokenize" method can be removed, I believe...

Regards, Pavel
> Hello,
>
> This is a request to review the fix for the issue:
> 7024963 Notepad demo: remove non-translatable resources from 
> Notepad.properties file
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024963
>
> The webrev is http://cr.openjdk.java.net/~alexsch/7024963/webrev.00
>
> The non-translatable properties are moved to the file system.properties.
> The getProperty() method is used now instead of the 
> getResourceString() where non-translatable resources are used.
>
>
> Thanks,
> Alexandr.
>



From pavel.porvatov at oracle.com  Sat Apr 28 13:36:13 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 28 Apr 2012 17:36:13 +0400
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4F9AB0E1.8050303@redhat.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
	<4F9AB0E1.8050303@redhat.com>
Message-ID: <4F9BF24D.40507@oracle.com>

Hi Pavel Tisnovsky wrote:
> Alexander Scherbatiy wrote:
>>    Hi  Pavel,
>>
>>    Thank you for the bug investigation.
> Hi Alexander,
>
> thank you for your answer!
>
>>    Could you create an issue on it?
> well I'm not sure what exactly you mean.
> To file a new bug or something like this?
> (I did not do it yet - somebody else ever created a bug #id for me ;-)
Use the following bug please:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7022041
>
>>    Could you also check that the issue 4129681 is not reproduced with
>> your fix? At least try to run the
>> test/javax/swing/border/Test4129681.java test.
> this test and other swing tests don't seem to be affected by the fix.
That's good that regression tests don't fail. Could you please:
1. write a test for the fix (I think it could be property checking under 
all available LAFs).
2. use our code conventions
3. Construction like "retrun ... ? ... : ...;" looks much better in your 
case

Regards, Pavel
>
>>    Thanks,
>>    Alexandr.
>>
>>
>>
>> On 4/27/2012 1:14 PM, Pavel Tisnovsky wrote:
>>> Hi,
>>>
>>> I think there's a bug in a TitledBorder class. According to JavaDoc
>>> the methods getTitleColor() and getTitleFont() should use look&feel
>>> settings when nothing is explicitly changed by constructor/setters:
>>>
>>> <javadoc>
>>> If the border, font, or color property values are not specified in the
>>> constuctor or by invoking the appropriate set
>>> methods, the property values will be defined by the current look and
>>> feel, using the following property names in the
>>> Defaults Table:
>>> "TitledBorder.border"
>>> "TitledBorder.font"
>>> "TitledBorder.titleColor"
>>> </javadoc>
>>>
>>> This behaviour were removed by following changeset:
>>> changeset:   2529:d062afbe2107
>>> user:        malenkov
>>> date:        Thu Jul 01 18:09:45 2010 +0400
>>> summary:     4129681: Cannot get a title border to display its label
>>> as disabled
>>>
>>>
>>> Here is a webrew which contains fix for this issue:
>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder/
>>>
>>> Can anybody please review this fix?
>>> (I'd like to push the same change to OpenJDK7 too it it will be
>>> reviewed&   accepted)
>>>
>>> Thank you in advance,
>>> Pavel Tisnovsky