From alexandr.scherbatiy at oracle.com  Wed May  2 10:34:40 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 02 May 2012 14:34:40 +0400
Subject: <Swing Dev> [8] Review request for 7024963: Notepad demo:
 remove non-translatable resources from Notepad.properties file
In-Reply-To: <4F9AB778.8050801@oracle.com>
References: <4F9A7A71.9090407@oracle.com> <4F9AB778.8050801@oracle.com>
Message-ID: <4FA10DC0.9070800@oracle.com>


   Hello,

   Could you review the updated version of the fix:
     http://cr.openjdk.java.net/~alexsch/7024963/webrev.01/

   1) "catch (Throwable e)" is replaced by checking on null in the 
constructor and removed from the main method.
   2) Keys are moved from the properties file to the code as arrays.
     However the system.properties file is still used for the 
ViewportBackingStore property and for the Action values.
   3) Unused methods and variables are removed
   4) Imports are refactored
   5) "for" loops are changed to "for each" loops

   Thanks,
   Alexandr.



On 4/27/2012 7:12 PM, Pavel Porvatov wrote:
> 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  Wed May  2 11:05:09 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 02 May 2012 15:05:09 +0400
Subject: <Swing Dev> [7] Review request for 7093156: NLS: Please change
 the mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F9AAFFC.5050201@oracle.com>
References: <4F9AAFFC.5050201@oracle.com>
Message-ID: <4FA114E5.1080903@oracle.com>

Hi Alexander,


> 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.
It seems there are mistakes in the backport. For example take a look at 
basic.properties files...

BTW: why some diffs looks differently? E.g. in jdk8 gtk.properties 
contains empty lines between FileChooser properties, but jdk7 doesn't....

Regards, Pavel
>
>  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 alexandr.scherbatiy at oracle.com  Wed May  2 12:30:27 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 02 May 2012 16:30:27 +0400
Subject: <Swing Dev> [7] Review request for 7093156: NLS: Please change
 the mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4FA114E5.1080903@oracle.com>
References: <4F9AAFFC.5050201@oracle.com> <4FA114E5.1080903@oracle.com>
Message-ID: <4FA128E3.7030708@oracle.com>

On 5/2/2012 3:05 PM, Pavel Porvatov wrote:
> Hi Alexander,
>
>> 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.
> It seems there are mistakes in the backport. For example take a look 
> at basic.properties files...

       I see that the comments about mnemonics are not updated in the 
properties files (I updated them manually for the JDK 8 fix).

       And there are properties like FileChooser.saveDialogTitleText 
that are translated to FileChooser.saveDialogTitle.textAndMnemonic.
       The property names with the  TitleText suffix do not have a 
special handling and just are treated as properties with the Text suffix.
       So the requests below have the same results:
             
System.out.println(UIManager.get("FileChooser.saveDialogTitleText"));
             
System.out.println(UIManager.get("FileChooser.saveDialogTitle.textAndMnemonic"));

       We could treat the TitleText suffixes as a separated case or 
leave it as is.

    Do you mean these mistakes in the basic.properties or any others?

>
> BTW: why some diffs looks differently? E.g. in jdk8 gtk.properties 
> contains empty lines between FileChooser properties, but jdk7 doesn't....

      I opened the latest JDK 8 webrev and JDK 7 and  pressed the new 
link near the gtk.properties and the empty lines look the same:
       http://cr.openjdk.java.net/~alexsch/7093156/webrev.03/
       http://cr.openjdk.java.net/~alexsch/7093156/webrev7.00/

      However in each file there are GTK specific properties which are 
separated by empty lines and FILE CHOOSER STRINGS that are not.

      The same was in the original files. For example:
       GTKColorChooserPanel.hueText=Hue:
       GTKColorChooserPanel.hueMnemonic=72

       GTKColorChooserPanel.redText=Red:
       GTKColorChooserPanel.redMnemonic=69

    These properties are converted to:
      GTKColorChooserPanel.hue.textAndMnemonic=&Hue:

      GTKColorChooserPanel.red.textAndMnemonic=R&ed:
    So empty lines are preserved in all cases.

   Thanks,
   Alexandr.


>
> Regards, Pavel
>>
>>  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  Wed May  2 13:09:55 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Wed, 02 May 2012 15:09:55 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4F9BF24D.40507@oracle.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
	<4F9AB0E1.8050303@redhat.com> <4F9BF24D.40507@oracle.com>
Message-ID: <4FA13223.8020409@redhat.com>

Pavel Porvatov wrote:
> 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

Hi Pavel and Alexander,

I've prepared second version of fix for TitledBorder class & JTreg test is
included too. Both changes can be seen here:

http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/

Could you please look at it?

Thank you in advance,
Pavel

> 
> 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
> 



From neugens.limasoftware at gmail.com  Wed May  2 17:42:24 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 2 May 2012 19:42:24 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4F92D7EA.6090504@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>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
Message-ID: <CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>

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

Hi Pavel,

> About the test:
> 1. Now is 2012 :)

Ops...

> 2. You must access to Swing components only from the EDT (see
> clickOnComponent(final Component comp) and other methods)

Not sure if I understand correctly, all the access is done in the EDT
already, unless I became very blind!

The tests are run from the EDT, only exception is checkPopup, which
just read a value after the execution, and I think this should be
safe.

> 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

Actually, this means duplicate more code or introduce another method,
not sure if this makes the code cleaner, but I can do it if you prefer
so.

> 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

The reason why the test is so complex is that I wanted to throw the
exact exception and don't mix the reflection related stuff with the
real test exception, that also basically means I don't want to save
the exception and rethrow it later on (I've seen this in some other
tests), I rather prefer to make this obvious and not hidden, but of
course the code gets longer, and everything is complicated by the EDT
invocations.

Also, I'm not particularly happy with the use of reflection to access
the filed and check the class name, since we're testing against an
implementation detail, but I don't know how else I should test that we
create an heavy weight window (which is really also just an
implementation detail that leaked through the code up to the user,
nobody should ever care about heavy weight and lightweight imho), so
if you have a smarter idea, I would be happy to change the code.

I will try to refactor the code but I would like to not invest
significant time in that, I'll send you a revised patch later
(hopefully!)

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 neugens.limasoftware at gmail.com  Wed May  2 19:03:46 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 2 May 2012 21:03:46 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
Message-ID: <CAGUMyaQ447X8Z0H4FbUmqLBDX6EJCnAaGT36=_Jr=cLsjTGsww@mail.gmail.com>

2012/5/2 Mario Torre <neugens.limasoftware at gmail.com>:
> 2012/4/21 Pavel Porvatov <pavel.porvatov at oracle.com>:
>
> Hi Pavel,
>
> I will try to refactor the code but I would like to not invest
> significant time in that, I'll send you a revised patch later
> (hopefully!)

Hi Pavel,

I found a moment of idleness and did some minor refactoring:

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

I hope this is good!

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 alexandr.scherbatiy at oracle.com  Thu May  3 11:02:07 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 03 May 2012 15:02:07 +0400
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FA13223.8020409@redhat.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
	<4F9AB0E1.8050303@redhat.com> <4F9BF24D.40507@oracle.com>
	<4FA13223.8020409@redhat.com>
Message-ID: <4FA265AF.1080202@oracle.com>

On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
> Hi Pavel and Alexander,
> I've prepared second version of fix for TitledBorder class&  JTreg test is
> included too. Both changes can be seen here:
>
> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>
> Could you please look at it?

     Just two brief questions.
    - Why do we need the extra Font f variable? Is it possible to use 
only the titleFont?
    - In case if the titleFont variable is null would it be better to 
set it to the default L&F font?
      So in the next getTitleFont() call the 
UIManager.getFont("TitledBorder.font")  method will not be executed.

   Thanks,
   Alexandr.

> Thank you in advance,
> Pavel
>
>> 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



From ptisnovs at redhat.com  Thu May  3 11:41:19 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Thu, 03 May 2012 13:41:19 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FA265AF.1080202@oracle.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
	<4F9AB0E1.8050303@redhat.com> <4F9BF24D.40507@oracle.com>
	<4FA13223.8020409@redhat.com> <4FA265AF.1080202@oracle.com>
Message-ID: <4FA26EDF.5040300@redhat.com>

Alexander Scherbatiy wrote:
> On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
>> Hi Pavel and Alexander,
>> I've prepared second version of fix for TitledBorder class&  JTreg
>> test is
>> included too. Both changes can be seen here:
>>
>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>>
>> Could you please look at it?
> 
>     Just two brief questions.
>    - Why do we need the extra Font f variable? Is it possible to use
> only the titleFont?

Yes, you are right - it is not really needed, it only makes debugging easier.
It's possible to shorten both getters to one liner.

>    - In case if the titleFont variable is null would it be better to set
> it to the default L&F font?
>      So in the next getTitleFont() call the
> UIManager.getFont("TitledBorder.font")  method will not be executed.

Hmm it might be better (it is even possible to do it directly in setters which
could be called from constructor), but
it changes object state (it's attributes) and it IMHO could(?) cause problems
with serialization and/or XML encoding. If you think it's not a problem
I'll be happy to create new version of this fix.

> 
>   Thanks,
>   Alexandr.
> 
>> Thank you in advance,
>> Pavel
>>
>>> 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
> 



From pavel.porvatov at oracle.com  Thu May  3 14:08:17 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 03 May 2012 18:08:17 +0400
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FA26EDF.5040300@redhat.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
	<4F9AB0E1.8050303@redhat.com> <4F9BF24D.40507@oracle.com>
	<4FA13223.8020409@redhat.com> <4FA265AF.1080202@oracle.com>
	<4FA26EDF.5040300@redhat.com>
Message-ID: <4FA29151.5050509@oracle.com>

Hi Pavel,
> Alexander Scherbatiy wrote:
>> On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
>>> Hi Pavel and Alexander,
>>> I've prepared second version of fix for TitledBorder class&   JTreg
>>> test is
>>> included too. Both changes can be seen here:
>>>
>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>>>
>>> Could you please look at it?
>>      Just two brief questions.
>>     - Why do we need the extra Font f variable? Is it possible to use
>> only the titleFont?
> Yes, you are right - it is not really needed, it only makes debugging easier.
> It's possible to shorten both getters to one liner.
I'm also voting to remove unnecessary variable.
>
>>     - In case if the titleFont variable is null would it be better to set
>> it to the default L&F font?
>>       So in the next getTitleFont() call the
>> UIManager.getFont("TitledBorder.font")  method will not be executed.
> Hmm it might be better (it is even possible to do it directly in setters which
> could be called from constructor), but
> it changes object state (it's attributes) and it IMHO could(?) cause problems
> with serialization and/or XML encoding. If you think it's not a problem
> I'll be happy to create new version of this fix.
I think we can't set variable, because after LAF changing the current 
functionality will be broken.

BTW: why don't you use Oracle copyright in test header?

Regards, Pavel
>
>>    Thanks,
>>    Alexandr.
>>
>>> Thank you in advance,
>>> Pavel
>>>
>>>> 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



From pavel.porvatov at oracle.com  Thu May  3 14:19:44 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 03 May 2012 18:19:44 +0400
Subject: <Swing Dev> [8] Review request for 7024963: Notepad demo:
 remove non-translatable resources from Notepad.properties file
In-Reply-To: <4FA10DC0.9070800@oracle.com>
References: <4F9A7A71.9090407@oracle.com> <4F9AB778.8050801@oracle.com>
	<4FA10DC0.9070800@oracle.com>
Message-ID: <4FA29400.6010902@oracle.com>

Hi Alexander,

The fix looks good.

Regards, Pavel
>
>   Hello,
>
>   Could you review the updated version of the fix:
>     http://cr.openjdk.java.net/~alexsch/7024963/webrev.01/
>
>   1) "catch (Throwable e)" is replaced by checking on null in the 
> constructor and removed from the main method.
>   2) Keys are moved from the properties file to the code as arrays.
>     However the system.properties file is still used for the 
> ViewportBackingStore property and for the Action values.
>   3) Unused methods and variables are removed
>   4) Imports are refactored
>   5) "for" loops are changed to "for each" loops
>
>   Thanks,
>   Alexandr.
>
>
>
> On 4/27/2012 7:12 PM, Pavel Porvatov wrote:
>> 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 i30817 at gmail.com  Fri May  4 09:02:59 2012
From: i30817 at gmail.com (Paulo Levi)
Date: Fri, 4 May 2012 10:02:59 +0100
Subject: <Swing Dev> Hang during theme change on gnome 3
Message-ID: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>

Hi - i have a swing application that hangs during theme change with gnome 3.
uname -a gives
Linux AIVAS-I 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
java -version
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu3)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

And the stacktrace (by initiating the app in a console and sending sigquit):



2012-05-04 10:01:35
Full thread dump OpenJDK 64-Bit Server VM (22.0-b10 mixed mode):

"SwingWorker-pool-1-thread-2" daemon prio=10 tid=0x00007f70a44fc800
nid=0x11f5 waiting on condition [0x00007f70a81ec000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000c29bcd40> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

"SwingWorker-pool-1-thread-1" daemon prio=10 tid=0x00007f70a43e3000
nid=0x11f1 waiting on condition [0x00007f70a85f0000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000c29bcd40> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

"TimerQueue" daemon prio=10 tid=0x00007f70a4355000 nid=0x11f0 waiting on
condition [0x00007f70a86f1000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000c26de2c0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
    at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
    at java.util.concurrent.DelayQueue.take(DelayQueue.java:220)
    at javax.swing.TimerQueue.run(TimerQueue.java:171)
    at java.lang.Thread.run(Thread.java:722)

"DestroyJavaVM" prio=10 tid=0x00007f70ec007800 nid=0x11db waiting on
condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0" prio=10 tid=0x00007f70ec2f6000 nid=0x11ea runnable
[0x00007f70b8e6b000]
   java.lang.Thread.State: RUNNABLE
    at com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native
Method)
    at
com.sun.java.swing.plaf.gtk.GTKEngine.themeChanged(GTKEngine.java:614)
    - locked <0x00000000c2a4d378> (a java.lang.Object)
    at
com.sun.java.swing.plaf.gtk.GTKLookAndFeel$WeakPCL$1.run(GTKLookAndFeel.java:1517)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
    at java.awt.EventQueue.access$000(EventQueue.java:101)
    at java.awt.EventQueue$3.run(EventQueue.java:666)
    at java.awt.EventQueue$3.run(EventQueue.java:664)
    at java.security.AccessController.doPrivileged(Native Method)
    at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:675)
    at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
    at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
    at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

"AWT-Shutdown" prio=10 tid=0x00007f70ec2f4000 nid=0x11e9 in Object.wait()
[0x00007f70b8f6d000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c29bdd50> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:503)
    at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:287)
    - locked <0x00000000c29bdd50> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)

"AWT-XAWT" daemon prio=10 tid=0x00007f70ec2f2000 nid=0x11e8 runnable
[0x00007f70c01ee000]
   java.lang.Thread.State: RUNNABLE
    at sun.awt.X11.XToolkit.waitForEvents(Native Method)
    at sun.awt.X11.XToolkit.run(XToolkit.java:631)
    at sun.awt.X11.XToolkit.run(XToolkit.java:595)
    at java.lang.Thread.run(Thread.java:722)

"Java2D Disposer" daemon prio=10 tid=0x00007f70ec2bb800 nid=0x11e7 in
Object.wait() [0x00007f70e8173000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000ef731398> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
    - locked <0x00000000ef731398> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at sun.java2d.Disposer.run(Disposer.java:145)
    at java.lang.Thread.run(Thread.java:722)

"Service Thread" daemon prio=10 tid=0x00007f70ec12b000 nid=0x11e5 runnable
[0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f70ec128800 nid=0x11e4
waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007f70ec125800 nid=0x11e3
waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f70ec123800 nid=0x11e2
waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f70ec0cc800 nid=0x11e1 in
Object.wait() [0x00007f70f103b000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c29e1620> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
    - locked <0x00000000c29e1620> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)

"Reference Handler" daemon prio=10 tid=0x00007f70ec0ca000 nid=0x11e0 in
Object.wait() [0x00007f70f113c000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c29e11b0> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
    - locked <0x00000000c29e11b0> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x00007f70ec0c2000 nid=0x11df runnable

"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f70ec012800 nid=0x11dc
runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f70ec014800 nid=0x11dd
runnable

"VM Periodic Task Thread" prio=10 tid=0x00007f70ec135800 nid=0x11e6 waiting
on condition

JNI global references: 348

Heap
 PSYoungGen      total 65856K, used 58756K [0x00000000eb6b0000,
0x00000000ef990000, 0x0000000100000000)
  eden space 63232K, 88% used
[0x00000000eb6b0000,0x00000000eed89218,0x00000000ef470000)
  from space 2624K, 98% used
[0x00000000ef700000,0x00000000ef988030,0x00000000ef990000)
  to   space 2624K, 0% used
[0x00000000ef470000,0x00000000ef470000,0x00000000ef700000)
 PSOldGen        total 42176K, used 19721K [0x00000000c2400000,
0x00000000c4d30000, 0x00000000eb6b0000)
  object space 42176K, 46% used
[0x00000000c2400000,0x00000000c3742628,0x00000000c4d30000)
 PSPermGen       total 21248K, used 20150K [0x00000000b7e00000,
0x00000000b92c0000, 0x00000000c2400000)
  object space 21248K, 94% used
[0x00000000b7e00000,0x00000000b91ad918,0x00000000b92c0000)



It seems like something happened at
com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native Method)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120504/deccd218/attachment.html>

From ptisnovs at redhat.com  Fri May  4 09:30:06 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Fri, 04 May 2012 11:30:06 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FA29151.5050509@oracle.com>
References: <4F9A6392.1040002@redhat.com> <4F9A857E.80505@oracle.com>
	<4F9AB0E1.8050303@redhat.com> <4F9BF24D.40507@oracle.com>
	<4FA13223.8020409@redhat.com> <4FA265AF.1080202@oracle.com>
	<4FA26EDF.5040300@redhat.com> <4FA29151.5050509@oracle.com>
Message-ID: <4FA3A19E.3070107@redhat.com>

Pavel Porvatov wrote:
> Hi Pavel,
>> Alexander Scherbatiy wrote:
>>> On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
>>>> Hi Pavel and Alexander,
>>>> I've prepared second version of fix for TitledBorder class&   JTreg
>>>> test is
>>>> included too. Both changes can be seen here:
>>>>
>>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>>>>
>>>> Could you please look at it?
>>>      Just two brief questions.
>>>     - Why do we need the extra Font f variable? Is it possible to use
>>> only the titleFont?
>> Yes, you are right - it is not really needed, it only makes debugging
>> easier.
>> It's possible to shorten both getters to one liner.
> I'm also voting to remove unnecessary variable.

Hi Pavel and Alexander,

here's third version of TitledBorder fix - getters now don't contain
any temporary variable:

http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v3/

>>
>>>     - In case if the titleFont variable is null would it be better to
>>> set
>>> it to the default L&F font?
>>>       So in the next getTitleFont() call the
>>> UIManager.getFont("TitledBorder.font")  method will not be executed.
>> Hmm it might be better (it is even possible to do it directly in
>> setters which
>> could be called from constructor), but
>> it changes object state (it's attributes) and it IMHO could(?) cause
>> problems
>> with serialization and/or XML encoding. If you think it's not a problem
>> I'll be happy to create new version of this fix.
> I think we can't set variable, because after LAF changing the current
> functionality will be broken.
> 
> BTW: why don't you use Oracle copyright in test header?

Well, I'm not Oracle employee ;-) I've asked Mark Reinhold about this
issue and he told me that it's ok to use RH copyright header.

Thank,
Pavel
> 
> Regards, Pavel
>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>> Thank you in advance,
>>>> Pavel
>>>>
>>>>> 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
> 



From alexandr.scherbatiy at oracle.com  Fri May  4 09:34:15 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 04 May 2012 13:34:15 +0400
Subject: <Swing Dev> Hang during theme change on gnome 3
In-Reply-To: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>
References: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>
Message-ID: <4FA3A297.6070006@oracle.com>


    Hi Paulo,

   Could you give a code snippet that reproduce the problem.
   It could really help to investigate the issue.

   Thanks,
   Alexandr.

On 5/4/2012 1:02 PM, Paulo Levi wrote:
> Hi - i have a swing application that hangs during theme change with 
> gnome 3.
> uname -a gives
> Linux AIVAS-I 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 
> 2012 x86_64 x86_64 x86_64 GNU/Linux
> java -version
> java version "1.7.0_03"
> OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu3)
> OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)
>
> And the stacktrace (by initiating the app in a console and sending 
> sigquit):
>
>
>
> 2012-05-04 10:01:35
> Full thread dump OpenJDK 64-Bit Server VM (22.0-b10 mixed mode):
>
> "SwingWorker-pool-1-thread-2" daemon prio=10 tid=0x00007f70a44fc800 
> nid=0x11f5 waiting on condition [0x00007f70a81ec000]
>    java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <0x00000000c29bcd40> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>     at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>     at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>     at java.lang.Thread.run(Thread.java:722)
>
> "SwingWorker-pool-1-thread-1" daemon prio=10 tid=0x00007f70a43e3000 
> nid=0x11f1 waiting on condition [0x00007f70a85f0000]
>    java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <0x00000000c29bcd40> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>     at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>     at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>     at java.lang.Thread.run(Thread.java:722)
>
> "TimerQueue" daemon prio=10 tid=0x00007f70a4355000 nid=0x11f0 waiting 
> on condition [0x00007f70a86f1000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <0x00000000c26de2c0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
>     at java.util.concurrent.DelayQueue.take(DelayQueue.java:220)
>     at javax.swing.TimerQueue.run(TimerQueue.java:171)
>     at java.lang.Thread.run(Thread.java:722)
>
> "DestroyJavaVM" prio=10 tid=0x00007f70ec007800 nid=0x11db waiting on 
> condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "AWT-EventQueue-0" prio=10 tid=0x00007f70ec2f6000 nid=0x11ea runnable 
> [0x00007f70b8e6b000]
>    java.lang.Thread.State: RUNNABLE
>     at 
> com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native Method)
>     at 
> com.sun.java.swing.plaf.gtk.GTKEngine.themeChanged(GTKEngine.java:614)
>     - locked <0x00000000c2a4d378> (a java.lang.Object)
>     at 
> com.sun.java.swing.plaf.gtk.GTKLookAndFeel$WeakPCL$1.run(GTKLookAndFeel.java:1517)
>     at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
>     at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
>     at java.awt.EventQueue.access$000(EventQueue.java:101)
>     at java.awt.EventQueue$3.run(EventQueue.java:666)
>     at java.awt.EventQueue$3.run(EventQueue.java:664)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
>     at java.awt.EventQueue.dispatchEvent(EventQueue.java:675)
>     at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
>     at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
>     at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
>     at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
>     at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
>     at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
>
> "AWT-Shutdown" prio=10 tid=0x00007f70ec2f4000 nid=0x11e9 in 
> Object.wait() [0x00007f70b8f6d000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000c29bdd50> (a java.lang.Object)
>     at java.lang.Object.wait(Object.java:503)
>     at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:287)
>     - locked <0x00000000c29bdd50> (a java.lang.Object)
>     at java.lang.Thread.run(Thread.java:722)
>
> "AWT-XAWT" daemon prio=10 tid=0x00007f70ec2f2000 nid=0x11e8 runnable 
> [0x00007f70c01ee000]
>    java.lang.Thread.State: RUNNABLE
>     at sun.awt.X11.XToolkit.waitForEvents(Native Method)
>     at sun.awt.X11.XToolkit.run(XToolkit.java:631)
>     at sun.awt.X11.XToolkit.run(XToolkit.java:595)
>     at java.lang.Thread.run(Thread.java:722)
>
> "Java2D Disposer" daemon prio=10 tid=0x00007f70ec2bb800 nid=0x11e7 in 
> Object.wait() [0x00007f70e8173000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000ef731398> (a 
> java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
>     - locked <0x00000000ef731398> (a java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
>     at sun.java2d.Disposer.run(Disposer.java:145)
>     at java.lang.Thread.run(Thread.java:722)
>
> "Service Thread" daemon prio=10 tid=0x00007f70ec12b000 nid=0x11e5 
> runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "C2 CompilerThread1" daemon prio=10 tid=0x00007f70ec128800 nid=0x11e4 
> waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "C2 CompilerThread0" daemon prio=10 tid=0x00007f70ec125800 nid=0x11e3 
> waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "Signal Dispatcher" daemon prio=10 tid=0x00007f70ec123800 nid=0x11e2 
> waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "Finalizer" daemon prio=10 tid=0x00007f70ec0cc800 nid=0x11e1 in 
> Object.wait() [0x00007f70f103b000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000c29e1620> (a 
> java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
>     - locked <0x00000000c29e1620> (a java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
>     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
>
> "Reference Handler" daemon prio=10 tid=0x00007f70ec0ca000 nid=0x11e0 
> in Object.wait() [0x00007f70f113c000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000c29e11b0> (a java.lang.ref.Reference$Lock)
>     at java.lang.Object.wait(Object.java:503)
>     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
>     - locked <0x00000000c29e11b0> (a java.lang.ref.Reference$Lock)
>
> "VM Thread" prio=10 tid=0x00007f70ec0c2000 nid=0x11df runnable
>
> "GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f70ec012800 
> nid=0x11dc runnable
>
> "GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f70ec014800 
> nid=0x11dd runnable
>
> "VM Periodic Task Thread" prio=10 tid=0x00007f70ec135800 nid=0x11e6 
> waiting on condition
>
> JNI global references: 348
>
> Heap
>  PSYoungGen      total 65856K, used 58756K [0x00000000eb6b0000, 
> 0x00000000ef990000, 0x0000000100000000)
>   eden space 63232K, 88% used 
> [0x00000000eb6b0000,0x00000000eed89218,0x00000000ef470000)
>   from space 2624K, 98% used 
> [0x00000000ef700000,0x00000000ef988030,0x00000000ef990000)
>   to   space 2624K, 0% used 
> [0x00000000ef470000,0x00000000ef470000,0x00000000ef700000)
>  PSOldGen        total 42176K, used 19721K [0x00000000c2400000, 
> 0x00000000c4d30000, 0x00000000eb6b0000)
>   object space 42176K, 46% used 
> [0x00000000c2400000,0x00000000c3742628,0x00000000c4d30000)
>  PSPermGen       total 21248K, used 20150K [0x00000000b7e00000, 
> 0x00000000b92c0000, 0x00000000c2400000)
>   object space 21248K, 94% used 
> [0x00000000b7e00000,0x00000000b91ad918,0x00000000b92c0000)
>
>
>
> It seems like something happened at 
> com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native Method) 



From pavel.porvatov at oracle.com  Fri May  4 09:37:30 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 04 May 2012 13:37:30 +0400
Subject: <Swing Dev> Hang during theme change on gnome 3
In-Reply-To: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>
References: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>
Message-ID: <4FA3A35A.9040405@oracle.com>

Hi Paulo,

File a bug, please

Regards, Pavel
> Hi - i have a swing application that hangs during theme change with 
> gnome 3.
> uname -a gives
> Linux AIVAS-I 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 
> 2012 x86_64 x86_64 x86_64 GNU/Linux
> java -version
> java version "1.7.0_03"
> OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu3)
> OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)
>
> And the stacktrace (by initiating the app in a console and sending 
> sigquit):
>
>
>
> 2012-05-04 10:01:35
> Full thread dump OpenJDK 64-Bit Server VM (22.0-b10 mixed mode):
>
> "SwingWorker-pool-1-thread-2" daemon prio=10 tid=0x00007f70a44fc800 
> nid=0x11f5 waiting on condition [0x00007f70a81ec000]
>    java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <0x00000000c29bcd40> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>     at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>     at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>     at java.lang.Thread.run(Thread.java:722)
>
> "SwingWorker-pool-1-thread-1" daemon prio=10 tid=0x00007f70a43e3000 
> nid=0x11f1 waiting on condition [0x00007f70a85f0000]
>    java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <0x00000000c29bcd40> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>     at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>     at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>     at java.lang.Thread.run(Thread.java:722)
>
> "TimerQueue" daemon prio=10 tid=0x00007f70a4355000 nid=0x11f0 waiting 
> on condition [0x00007f70a86f1000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <0x00000000c26de2c0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
>     at java.util.concurrent.DelayQueue.take(DelayQueue.java:220)
>     at javax.swing.TimerQueue.run(TimerQueue.java:171)
>     at java.lang.Thread.run(Thread.java:722)
>
> "DestroyJavaVM" prio=10 tid=0x00007f70ec007800 nid=0x11db waiting on 
> condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "AWT-EventQueue-0" prio=10 tid=0x00007f70ec2f6000 nid=0x11ea runnable 
> [0x00007f70b8e6b000]
>    java.lang.Thread.State: RUNNABLE
>     at 
> com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native Method)
>     at 
> com.sun.java.swing.plaf.gtk.GTKEngine.themeChanged(GTKEngine.java:614)
>     - locked <0x00000000c2a4d378> (a java.lang.Object)
>     at 
> com.sun.java.swing.plaf.gtk.GTKLookAndFeel$WeakPCL$1.run(GTKLookAndFeel.java:1517)
>     at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
>     at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
>     at java.awt.EventQueue.access$000(EventQueue.java:101)
>     at java.awt.EventQueue$3.run(EventQueue.java:666)
>     at java.awt.EventQueue$3.run(EventQueue.java:664)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
>     at java.awt.EventQueue.dispatchEvent(EventQueue.java:675)
>     at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
>     at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
>     at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
>     at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
>     at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
>     at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
>
> "AWT-Shutdown" prio=10 tid=0x00007f70ec2f4000 nid=0x11e9 in 
> Object.wait() [0x00007f70b8f6d000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000c29bdd50> (a java.lang.Object)
>     at java.lang.Object.wait(Object.java:503)
>     at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:287)
>     - locked <0x00000000c29bdd50> (a java.lang.Object)
>     at java.lang.Thread.run(Thread.java:722)
>
> "AWT-XAWT" daemon prio=10 tid=0x00007f70ec2f2000 nid=0x11e8 runnable 
> [0x00007f70c01ee000]
>    java.lang.Thread.State: RUNNABLE
>     at sun.awt.X11.XToolkit.waitForEvents(Native Method)
>     at sun.awt.X11.XToolkit.run(XToolkit.java:631)
>     at sun.awt.X11.XToolkit.run(XToolkit.java:595)
>     at java.lang.Thread.run(Thread.java:722)
>
> "Java2D Disposer" daemon prio=10 tid=0x00007f70ec2bb800 nid=0x11e7 in 
> Object.wait() [0x00007f70e8173000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000ef731398> (a 
> java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
>     - locked <0x00000000ef731398> (a java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
>     at sun.java2d.Disposer.run(Disposer.java:145)
>     at java.lang.Thread.run(Thread.java:722)
>
> "Service Thread" daemon prio=10 tid=0x00007f70ec12b000 nid=0x11e5 
> runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "C2 CompilerThread1" daemon prio=10 tid=0x00007f70ec128800 nid=0x11e4 
> waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "C2 CompilerThread0" daemon prio=10 tid=0x00007f70ec125800 nid=0x11e3 
> waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "Signal Dispatcher" daemon prio=10 tid=0x00007f70ec123800 nid=0x11e2 
> waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>
> "Finalizer" daemon prio=10 tid=0x00007f70ec0cc800 nid=0x11e1 in 
> Object.wait() [0x00007f70f103b000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000c29e1620> (a 
> java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
>     - locked <0x00000000c29e1620> (a java.lang.ref.ReferenceQueue$Lock)
>     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
>     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
>
> "Reference Handler" daemon prio=10 tid=0x00007f70ec0ca000 nid=0x11e0 
> in Object.wait() [0x00007f70f113c000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <0x00000000c29e11b0> (a java.lang.ref.Reference$Lock)
>     at java.lang.Object.wait(Object.java:503)
>     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
>     - locked <0x00000000c29e11b0> (a java.lang.ref.Reference$Lock)
>
> "VM Thread" prio=10 tid=0x00007f70ec0c2000 nid=0x11df runnable
>
> "GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f70ec012800 
> nid=0x11dc runnable
>
> "GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f70ec014800 
> nid=0x11dd runnable
>
> "VM Periodic Task Thread" prio=10 tid=0x00007f70ec135800 nid=0x11e6 
> waiting on condition
>
> JNI global references: 348
>
> Heap
>  PSYoungGen      total 65856K, used 58756K [0x00000000eb6b0000, 
> 0x00000000ef990000, 0x0000000100000000)
>   eden space 63232K, 88% used 
> [0x00000000eb6b0000,0x00000000eed89218,0x00000000ef470000)
>   from space 2624K, 98% used 
> [0x00000000ef700000,0x00000000ef988030,0x00000000ef990000)
>   to   space 2624K, 0% used 
> [0x00000000ef470000,0x00000000ef470000,0x00000000ef700000)
>  PSOldGen        total 42176K, used 19721K [0x00000000c2400000, 
> 0x00000000c4d30000, 0x00000000eb6b0000)
>   object space 42176K, 46% used 
> [0x00000000c2400000,0x00000000c3742628,0x00000000c4d30000)
>  PSPermGen       total 21248K, used 20150K [0x00000000b7e00000, 
> 0x00000000b92c0000, 0x00000000c2400000)
>   object space 21248K, 94% used 
> [0x00000000b7e00000,0x00000000b91ad918,0x00000000b92c0000)
>
>
>
> It seems like something happened at 
> com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native Method) 



From alexandr.scherbatiy at oracle.com  Fri May  4 11:08:45 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 04 May 2012 15:08:45 +0400
Subject: <Swing Dev> [7] Review request for 7093156: NLS: Please change
 the mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4FA128E3.7030708@oracle.com>
References: <4F9AAFFC.5050201@oracle.com> <4FA114E5.1080903@oracle.com>
	<4FA128E3.7030708@oracle.com>
Message-ID: <4FA3B8BD.3040100@oracle.com>


   This is the new webrev  with the fixed comments in the  property files.
    http://cr.openjdk.java.net/~alexsch/7093156/webrev7.01/

    The *.properties files are different in the JDK7 and JDK8 because 
for example
      the JDK8 version of basic.properties file contains 2 extra 
properties:

   74 FileChooser.filesListAccessibleName=Files List
   75 FileChooser.filesDetailsAccessibleName=Files Details

    and JDK 7 version of the metal.properties file does not contain 
mnemonics definition.

   There were extra lines in the JDK8 webrev because they contain extra 
windows CRLF characters.
   The JDK 7 webrev now does not contain them, so the webrev is shown 
without extra lines.

   Thanks,
   Alexandr.


On 5/2/2012 4:30 PM, Alexander Scherbatiy wrote:
> On 5/2/2012 3:05 PM, Pavel Porvatov wrote:
>> Hi Alexander,
>>
>>> 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.
>> It seems there are mistakes in the backport. For example take a look 
>> at basic.properties files...
>
>       I see that the comments about mnemonics are not updated in the 
> properties files (I updated them manually for the JDK 8 fix).
>
>       And there are properties like FileChooser.saveDialogTitleText 
> that are translated to FileChooser.saveDialogTitle.textAndMnemonic.
>       The property names with the  TitleText suffix do not have a 
> special handling and just are treated as properties with the Text suffix.
>       So the requests below have the same results:
>             
> System.out.println(UIManager.get("FileChooser.saveDialogTitleText"));
>             
> System.out.println(UIManager.get("FileChooser.saveDialogTitle.textAndMnemonic"));
>
>       We could treat the TitleText suffixes as a separated case or 
> leave it as is.
>
>    Do you mean these mistakes in the basic.properties or any others?
>
>>
>> BTW: why some diffs looks differently? E.g. in jdk8 gtk.properties 
>> contains empty lines between FileChooser properties, but jdk7 
>> doesn't....
>
>      I opened the latest JDK 8 webrev and JDK 7 and  pressed the new 
> link near the gtk.properties and the empty lines look the same:
>       http://cr.openjdk.java.net/~alexsch/7093156/webrev.03/
>       http://cr.openjdk.java.net/~alexsch/7093156/webrev7.00/
>
>      However in each file there are GTK specific properties which are 
> separated by empty lines and FILE CHOOSER STRINGS that are not.
>
>      The same was in the original files. For example:
>       GTKColorChooserPanel.hueText=Hue:
>       GTKColorChooserPanel.hueMnemonic=72
>
>       GTKColorChooserPanel.redText=Red:
>       GTKColorChooserPanel.redMnemonic=69
>
>    These properties are converted to:
>      GTKColorChooserPanel.hue.textAndMnemonic=&Hue:
>
>      GTKColorChooserPanel.red.textAndMnemonic=R&ed:
>    So empty lines are preserved in all cases.
>
>   Thanks,
>   Alexandr.
>
>
>>
>> Regards, Pavel
>>>
>>>  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 i30817 at gmail.com  Fri May  4 11:20:06 2012
From: i30817 at gmail.com (Paulo Levi)
Date: Fri, 4 May 2012 12:20:06 +0100
Subject: <Swing Dev> Hang during theme change on gnome 3
In-Reply-To: <4FA3A35A.9040405@oracle.com>
References: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>
	<4FA3A35A.9040405@oracle.com>
Message-ID: <CAO02FZ+OEbG5ukUj3s3hyeP2Wchrvfw9fURsAf-Bdndn+kG8Ww@mail.gmail.com>

Hi Pavel, bug is submitted now with a small testcase (which require manual
work i'm afraid), to change the gnome 3 theme (i don't know how to automate
it).

It also appears to happen in any swing app, not just mine - Netbeans has it
for instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120504/4b783be0/attachment.html>

From i30817 at gmail.com  Fri May  4 11:23:35 2012
From: i30817 at gmail.com (Paulo Levi)
Date: Fri, 4 May 2012 12:23:35 +0100
Subject: <Swing Dev> Hang during theme change on gnome 3
In-Reply-To: <4FA3A35A.9040405@oracle.com>
References: <CAO02FZLt=sNV=FRHTUdEQsZk3RVTKqLtaeO9KVdPQP=RM21g=w@mail.gmail.com>
	<4FA3A35A.9040405@oracle.com>
Message-ID: <CAO02FZJXn=WQnvEc29kn1SXKPkzKLJJz_etAB=O1bJWTJ5zxpw@mail.gmail.com>

Bug Id is 7166433.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166433.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120504/a0a0e791/attachment.html>

From pavel.porvatov at oracle.com  Fri May  4 13:42:45 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 04 May 2012 17:42:45 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
Message-ID: <4FA3DCD5.2090005@oracle.com>

Hi Mario,
> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>
> Hi Pavel,
>
>> About the test:
>> 1. Now is 2012 :)
> Ops...
>
>> 2. You must access to Swing components only from the EDT (see
>> clickOnComponent(final Component comp) and other methods)
> Not sure if I understand correctly, all the access is done in the EDT
> already, unless I became very blind!
>
> The tests are run from the EDT, only exception is checkPopup, which
> just read a value after the execution, and I think this should be
> safe.
Yes, I missed the fact that the clickOnComponent method invoked on EDT. 
That's because you used robot.delay(50) in the method. There is no sense 
to use sleep methods on the EDT therad: you just freeze any event 
handling....
>> 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
> Actually, this means duplicate more code or introduce another method,
> not sure if this makes the code cleaner, but I can do it if you prefer
> so.
>
>> 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
> The reason why the test is so complex is that I wanted to throw the
> exact exception and don't mix the reflection related stuff with the
> real test exception, that also basically means I don't want to save
> the exception and rethrow it later on (I've seen this in some other
> tests), I rather prefer to make this obvious and not hidden, but of
> course the code gets longer, and everything is complicated by the EDT
> invocations.
In your case reflection exception is also test failing.
> Also, I'm not particularly happy with the use of reflection to access
> the filed and check the class name, since we're testing against an
> implementation detail, but I don't know how else I should test that we
> create an heavy weight window (which is really also just an
> implementation detail that leaked through the code up to the user,
> nobody should ever care about heavy weight and lightweight imho), so
> if you have a smarter idea, I would be happy to change the code.
I'm also trying to avoid reflection in tests but I don't see another 
solution here
> I will try to refactor the code but I would like to not invest
> significant time in that, I'll send you a revised patch later
> (hopefully!)
Yes, and that's the reason to write first version of test without any 
errors. The test shouldn't have errors, because if it fails (on some 
platforms with very specific configuration) we have to fix it (therefore 
we are trying to keep all tests as clear and short as possible)...

Your test is still have problems. E.g. setVisible invocation doesn't 
guarantee that right after method Frame becomes visible (platforms 
dependent behaviour). You can take a look at good test examples in 
repository, e.g. here
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d

Regards, Pavel



From i30817 at gmail.com  Sat May  5 07:31:41 2012
From: i30817 at gmail.com (Paulo Levi)
Date: Sat, 5 May 2012 08:31:41 +0100
Subject: <Swing Dev> JList MULTIPLE_INTERVAL_SELECTION
Message-ID: <CAO02FZLTqJf0kbmOB22KUH95++b=OKDDNo_4iXxtFJtX8jtqSw@mail.gmail.com>

Glazed list as a feature, that i consider more like a bug fix:


    /**
     * A selection mode where any element may be selected and freshly added
elements
     * are always deselected. No equivalent policy exists in
     * {@link javax.swing.ListSelectionModel}
     */
    public static final int MULTIPLE_INTERVAL_SELECTION_DEFENSIVE = 103;


used like this:
DefaultEventSelectionModel esm = new DefaultEventSelectionModel(sorted);
esm.setSelectionMode(ListSelection.MULTIPLE_INTERVAL_SELECTION_DEFENSIVE);

I've only seen the need to use it intheir filtering classes yet (because
they are constantly adding elements)
but it really seems like a bug of MULTIPLE_INTERVAL_SELECTION.
Part of the DefaultEventSelectionModel javadoc:

 * <p>Alongside <code>MULTIPLE_INTERVAL_SELECTION</code>, this {@link
ListSelectionModel}
 * supports an additional selection mode.
 * <code>MULTIPLE_INTERVAL_SELECTION_DEFENSIVE</code> is a new selection
mode.
 * It is identical to <code>MULTIPLE_INTERVAL_SELECTION</code> in every way
but
 * one. When a row is inserted immediately before a selected row in the
 * <code>MULTIPLE_INTERVAL_SELECTION</code> mode, it becomes selected. But
in
 * the <code>MULTIPLE_INTERVAL_SELECTION_DEFENSIVE</code> mode, it does not
 * become selected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120505/0053e267/attachment.html>

From sauvageor at yahoo.fr  Wed May  9 16:57:33 2012
From: sauvageor at yahoo.fr (thierry sauvageot)
Date: Wed, 9 May 2012 17:57:33 +0100 (BST)
Subject: <Swing Dev> hello
Message-ID: <1336582653.66786.YahooMailNeo@web171602.mail.ir2.yahoo.com>

Hello
?I try to add functionality to the library swing.
As elements all ready high-level and modifiable,
in a structured data model.


if you're interested, I'm starting to realize it or manage.

best regard
Thierry Sauvageot
33 (0) 952731917
33 (0) 651552736
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120509/1687140c/attachment.html>

From Alexander.Potochkin at oracle.com  Thu May 10 15:57:35 2012
From: Alexander.Potochkin at oracle.com (Alexander Potochkin)
Date: Thu, 10 May 2012 19:57:35 +0400
Subject: <Swing Dev> [7] Review request for 7093156: NLS: Please change
 the mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4FA3B8BD.3040100@oracle.com>
References: <4F9AAFFC.5050201@oracle.com> <4FA114E5.1080903@oracle.com>
	<4FA128E3.7030708@oracle.com> <4FA3B8BD.3040100@oracle.com>
Message-ID: <4FABE56F.9080904@oracle.com>

Hello Alexander
>
>   This is the new webrev  with the fixed comments in the  property files.
>    http://cr.openjdk.java.net/~alexsch/7093156/webrev7.01/
>
>    The *.properties files are different in the JDK7 and JDK8 because 
> for example
>      the JDK8 version of basic.properties file contains 2 extra 
> properties:
>
>   74 FileChooser.filesListAccessibleName=Files List
>   75 FileChooser.filesDetailsAccessibleName=Files Details
>
>    and JDK 7 version of the metal.properties file does not contain 
> mnemonics definition.
>
>   There were extra lines in the JDK8 webrev because they contain extra 
> windows CRLF characters.
>   The JDK 7 webrev now does not contain them, so the webrev is shown 
> without extra lines.

If those lines are the only difference between the JDK8 version of the fix
I approve

Thanks
alexp

>
>   Thanks,
>   Alexandr.
>
>
> On 5/2/2012 4:30 PM, Alexander Scherbatiy wrote:
>> On 5/2/2012 3:05 PM, Pavel Porvatov wrote:
>>> Hi Alexander,
>>>
>>>> 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.
>>> It seems there are mistakes in the backport. For example take a look 
>>> at basic.properties files...
>>
>>       I see that the comments about mnemonics are not updated in the 
>> properties files (I updated them manually for the JDK 8 fix).
>>
>>       And there are properties like FileChooser.saveDialogTitleText 
>> that are translated to FileChooser.saveDialogTitle.textAndMnemonic.
>>       The property names with the  TitleText suffix do not have a 
>> special handling and just are treated as properties with the Text 
>> suffix.
>>       So the requests below have the same results:
>>             
>> System.out.println(UIManager.get("FileChooser.saveDialogTitleText"));
>>             
>> System.out.println(UIManager.get("FileChooser.saveDialogTitle.textAndMnemonic"));
>>
>>       We could treat the TitleText suffixes as a separated case or 
>> leave it as is.
>>
>>    Do you mean these mistakes in the basic.properties or any others?
>>
>>>
>>> BTW: why some diffs looks differently? E.g. in jdk8 gtk.properties 
>>> contains empty lines between FileChooser properties, but jdk7 
>>> doesn't....
>>
>>      I opened the latest JDK 8 webrev and JDK 7 and  pressed the new 
>> link near the gtk.properties and the empty lines look the same:
>>       http://cr.openjdk.java.net/~alexsch/7093156/webrev.03/
>>       http://cr.openjdk.java.net/~alexsch/7093156/webrev7.00/
>>
>>      However in each file there are GTK specific properties which are 
>> separated by empty lines and FILE CHOOSER STRINGS that are not.
>>
>>      The same was in the original files. For example:
>>       GTKColorChooserPanel.hueText=Hue:
>>       GTKColorChooserPanel.hueMnemonic=72
>>
>>       GTKColorChooserPanel.redText=Red:
>>       GTKColorChooserPanel.redMnemonic=69
>>
>>    These properties are converted to:
>>      GTKColorChooserPanel.hue.textAndMnemonic=&Hue:
>>
>>      GTKColorChooserPanel.red.textAndMnemonic=R&ed:
>>    So empty lines are preserved in all cases.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>>>
>>> Regards, Pavel
>>>>
>>>>  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  Mon May 14 13:21:33 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Mon, 14 May 2012 15:21:33 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FA3A19E.3070107@redhat.com>
References: <4F9A6392.1040002@redhat.com>
	<4F9A857E.80505@oracle.com>	<4F9AB0E1.8050303@redhat.com>
	<4F9BF24D.40507@oracle.com>	<4FA13223.8020409@redhat.com>
	<4FA265AF.1080202@oracle.com>	<4FA26EDF.5040300@redhat.com>
	<4FA29151.5050509@oracle.com> <4FA3A19E.3070107@redhat.com>
Message-ID: <4FB106DD.4030305@redhat.com>

ping - can anybody please look at this issue?

Thank you in advance,
Pavel


Pavel Tisnovsky wrote:
> Pavel Porvatov wrote:
>> Hi Pavel,
>>> Alexander Scherbatiy wrote:
>>>> On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
>>>>> Hi Pavel and Alexander,
>>>>> I've prepared second version of fix for TitledBorder class&   JTreg
>>>>> test is
>>>>> included too. Both changes can be seen here:
>>>>>
>>>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>>>>>
>>>>> Could you please look at it?
>>>>      Just two brief questions.
>>>>     - Why do we need the extra Font f variable? Is it possible to use
>>>> only the titleFont?
>>> Yes, you are right - it is not really needed, it only makes debugging
>>> easier.
>>> It's possible to shorten both getters to one liner.
>> I'm also voting to remove unnecessary variable.
> 
> Hi Pavel and Alexander,
> 
> here's third version of TitledBorder fix - getters now don't contain
> any temporary variable:
> 
> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v3/
> 
>>>>     - In case if the titleFont variable is null would it be better to
>>>> set
>>>> it to the default L&F font?
>>>>       So in the next getTitleFont() call the
>>>> UIManager.getFont("TitledBorder.font")  method will not be executed.
>>> Hmm it might be better (it is even possible to do it directly in
>>> setters which
>>> could be called from constructor), but
>>> it changes object state (it's attributes) and it IMHO could(?) cause
>>> problems
>>> with serialization and/or XML encoding. If you think it's not a problem
>>> I'll be happy to create new version of this fix.
>> I think we can't set variable, because after LAF changing the current
>> functionality will be broken.
>>
>> BTW: why don't you use Oracle copyright in test header?
> 
> Well, I'm not Oracle employee ;-) I've asked Mark Reinhold about this
> issue and he told me that it's ok to use RH copyright header.
> 
> Thank,
> Pavel
>> Regards, Pavel
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>>> Thank you in advance,
>>>>> Pavel
>>>>>
>>>>>> 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
> 



From neugens.limasoftware at gmail.com  Mon May 14 13:48:28 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 14 May 2012 15:48:28 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FA3DCD5.2090005@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>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
Message-ID: <CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>

Hi Pavel,

I uploaded a new patch here:

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

I don't really understand why one should call internal private api
(realSync) when a public API is there (Toolkit.sync), that *should* do
the same (even if it obviously doesn't).

Anyway, I hope this version is good enough for you to go in.

Please, let me know what you think,
Mario

2012/5/4 Pavel Porvatov <pavel.porvatov at oracle.com>:
> Hi Mario,
>
>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>
>> Hi Pavel,
>>
>>> About the test:
>>> 1. Now is 2012 :)
>>
>> Ops...
>>
>>> 2. You must access to Swing components only from the EDT (see
>>> clickOnComponent(final Component comp) and other methods)
>>
>> Not sure if I understand correctly, all the access is done in the EDT
>> already, unless I became very blind!
>>
>> The tests are run from the EDT, only exception is checkPopup, which
>> just read a value after the execution, and I think this should be
>> safe.
>
> Yes, I missed the fact that the clickOnComponent method invoked on EDT.
> That's because you used robot.delay(50) in the method. There is no sense to
> use sleep methods on the EDT therad: you just freeze any event handling....
>
>>> 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
>>
>> Actually, this means duplicate more code or introduce another method,
>> not sure if this makes the code cleaner, but I can do it if you prefer
>> so.
>>
>>> 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
>>
>> The reason why the test is so complex is that I wanted to throw the
>> exact exception and don't mix the reflection related stuff with the
>> real test exception, that also basically means I don't want to save
>> the exception and rethrow it later on (I've seen this in some other
>> tests), I rather prefer to make this obvious and not hidden, but of
>> course the code gets longer, and everything is complicated by the EDT
>> invocations.
>
> In your case reflection exception is also test failing.
>
>> Also, I'm not particularly happy with the use of reflection to access
>> the filed and check the class name, since we're testing against an
>> implementation detail, but I don't know how else I should test that we
>> create an heavy weight window (which is really also just an
>> implementation detail that leaked through the code up to the user,
>> nobody should ever care about heavy weight and lightweight imho), so
>> if you have a smarter idea, I would be happy to change the code.
>
> I'm also trying to avoid reflection in tests but I don't see another
> solution here
>
>> I will try to refactor the code but I would like to not invest
>> significant time in that, I'll send you a revised patch later
>> (hopefully!)
>
> Yes, and that's the reason to write first version of test without any
> errors. The test shouldn't have errors, because if it fails (on some
> platforms with very specific configuration) we have to fix it (therefore we
> are trying to keep all tests as clear and short as possible)...
>
> Your test is still have problems. E.g. setVisible invocation doesn't
> guarantee that right after method Frame becomes visible (platforms dependent
> behaviour). You can take a look at good test examples in repository, e.g.
> here
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>
> Regards, Pavel
>



-- 
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 alexandr.scherbatiy at oracle.com  Tue May 15 14:47:27 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 15 May 2012 18:47:27 +0400
Subject: <Swing Dev> [8] Review request for 7158928 [macosx] NLS: Please
 change the mnemonic assignment system
Message-ID: <4FB26C7F.9080009@oracle.com>

Hello,

Please review a fix for the issue:
   7158928 [macosx] NLS: Please change the mnemonic assignment system
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158928

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

This is a request from the NLS team to use text and mnemonics in one 
property for the Aqua properties.

The fix consists of the following parts:
- aqua.properties file is added as a compiled property in the makefiles.
   There are no localizations of the aqua.properties file in the JDK.
- The aqua bundle is always added to the UIdefaults table in the 
AquaLookAndFeel. It is necessary to register the bundle and clear the 
table cache.
- Text and mnemonic properties are unified in one property for the 
aqua.properties file in the same way as it was done for the fix 7093156
For example the following properties
   xxxText=ABC
   xxxMnemonic=B
are unified to one:
   xxx.textAndMnemonic=A&BC

Thanks,
Alexandr.




From alexandr.scherbatiy at oracle.com  Wed May 16 10:38:28 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 16 May 2012 14:38:28 +0400
Subject: <Swing Dev> [8] Review request for 7169226 - NLS: Please change the
 mnemonic assignment system for windows and motif properties
Message-ID: <4FB383A4.4030204@oracle.com>


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

The properties in the windows and motif resources are changed from the
   xxxText=ABC
   xxxMnemonic=B
to
   xxx.textAndMnemonic=A&BC
in the same way as it has been done for the issue 7093156.


The following test has been used to check that UIManager.get(key, 
locale) method returns the same value as before.
http://cr.openjdk.java.net/~alexsch/7093156/test/02/SwingResourcesTest.java

Thanks,
Alexandr.



From pavel.porvatov at oracle.com  Wed May 16 11:43:50 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 16 May 2012 15:43:50 +0400
Subject: <Swing Dev> [8] Review request for 7169226 - NLS: Please change
 the mnemonic assignment system for windows and motif properties
In-Reply-To: <4FB383A4.4030204@oracle.com>
References: <4FB383A4.4030204@oracle.com>
Message-ID: <4FB392F6.90003@oracle.com>

Hi Alexander,

Looks good for me.
>
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169226
> webrev: http://cr.openjdk.java.net/~alexsch/7169226/webrev.00/
>
> The properties in the windows and motif resources are changed from the
>   xxxText=ABC
>   xxxMnemonic=B
> to
>   xxx.textAndMnemonic=A&BC
> in the same way as it has been done for the issue 7093156.
>
>
> The following test has been used to check that UIManager.get(key, 
> locale) method returns the same value as before.
> http://cr.openjdk.java.net/~alexsch/7093156/test/02/SwingResourcesTest.java 
>
>
> Thanks,
> Alexandr.
>



From pavel.porvatov at oracle.com  Wed May 16 11:56:10 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 16 May 2012 15:56:10 +0400
Subject: <Swing Dev> [8] Review request for 7158928 [macosx] NLS: Please
 change the mnemonic assignment system
In-Reply-To: <4FB26C7F.9080009@oracle.com>
References: <4FB26C7F.9080009@oracle.com>
Message-ID: <4FB395DA.9010109@oracle.com>

Hi Alexander,

Looks good for me.
> Hello,
>
> Please review a fix for the issue:
>   7158928 [macosx] NLS: Please change the mnemonic assignment system
>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158928
>
> The webrev is http://cr.openjdk.java.net/~alexsch/7158928/webrev.00
>
> This is a request from the NLS team to use text and mnemonics in one 
> property for the Aqua properties.
>
> The fix consists of the following parts:
> - aqua.properties file is added as a compiled property in the makefiles.
>   There are no localizations of the aqua.properties file in the JDK.
> - The aqua bundle is always added to the UIdefaults table in the 
> AquaLookAndFeel. It is necessary to register the bundle and clear the 
> table cache.
> - Text and mnemonic properties are unified in one property for the 
> aqua.properties file in the same way as it was done for the fix 7093156
> For example the following properties
>   xxxText=ABC
>   xxxMnemonic=B
> are unified to one:
>   xxx.textAndMnemonic=A&BC
>
> Thanks,
> Alexandr.
>
>



From Sergey.Bylokhov at oracle.com  Wed May 16 13:45:27 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 May 2012 17:45:27 +0400
Subject: <Swing Dev> [8] Review request for 7158928 [macosx] NLS: Please
 change the mnemonic assignment system
In-Reply-To: <4FB26C7F.9080009@oracle.com>
References: <4FB26C7F.9080009@oracle.com>
Message-ID: <4FB3AF77.1080300@oracle.com>

Hi Alexander.

Looks good.
Thanks.

15.05.2012 18:47, Alexander Scherbatiy wtote:
> Hello,
>
> Please review a fix for the issue:
>   7158928 [macosx] NLS: Please change the mnemonic assignment system
>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158928
>
> The webrev is http://cr.openjdk.java.net/~alexsch/7158928/webrev.00
>
> This is a request from the NLS team to use text and mnemonics in one 
> property for the Aqua properties.
>
> The fix consists of the following parts:
> - aqua.properties file is added as a compiled property in the makefiles.
>   There are no localizations of the aqua.properties file in the JDK.
> - The aqua bundle is always added to the UIdefaults table in the 
> AquaLookAndFeel. It is necessary to register the bundle and clear the 
> table cache.
> - Text and mnemonic properties are unified in one property for the 
> aqua.properties file in the same way as it was done for the fix 7093156
> For example the following properties
>   xxxText=ABC
>   xxxMnemonic=B
> are unified to one:
>   xxx.textAndMnemonic=A&BC
>
> Thanks,
> Alexandr.
>
>


-- 
Best regards, Sergey.



From pavel.porvatov at oracle.com  Fri May 18 15:33:27 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 18 May 2012 19:33:27 +0400
Subject: <Swing Dev> [8] Review request for 7168144 No appropriate CCC
 request for changes introduced by 7154030
Message-ID: <4FB66BC7.3000505@oracle.com>

Hello,

Please review a fix for the following issue:
   7168144 No appropriate CCC request for changes introduced by 7154030
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168144

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

Fix of CR 7154030 overrides the Component.hide() method but doesn't 
declare that the method is deprecated.

Regards,
Pavel.



From alexandr.scherbatiy at oracle.com  Fri May 18 15:51:20 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 18 May 2012 19:51:20 +0400
Subject: <Swing Dev> [8] Review request for 7168144 No appropriate CCC
 request for changes introduced by 7154030
In-Reply-To: <4FB66BC7.3000505@oracle.com>
References: <4FB66BC7.3000505@oracle.com>
Message-ID: <4FB66FF8.7060704@oracle.com>

On 5/18/2012 7:33 PM, Pavel Porvatov wrote:

The fix looks good.

Thanks,
Alexandr.

> Hello,
>
> Please review a fix for the following issue:
>   7168144 No appropriate CCC request for changes introduced by 7154030
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168144
>
> The webrev is here: http://cr.openjdk.java.net/~rupashka/7168144/ 
> <http://cr.openjdk.java.net/%7Erupashka/7168144/>
>
> Fix of CR 7154030 overrides the Component.hide() method but doesn't 
> declare that the method is deprecated.
>
> Regards,
> Pavel.
>



From luchsh at linux.vnet.ibm.com  Mon May 21 06:36:49 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 21 May 2012 14:36:49 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F9664D0.5040601@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> <4F7EA17D.1000902@linux.vnet.ibm.com>
	<4F96071F.70304@linux.vnet.ibm.com> <4F9664D0.5040601@oracle.com>
Message-ID: <4FB9E281.7050105@linux.vnet.ibm.com>

Hello Pavel,

Any more comments on this topic?

Regards, Jonathan

On 04/24/2012 04:31 PM, Pavel Porvatov wrote:
> 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  Mon May 21 13:55:51 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 21 May 2012 17:55:51 +0400
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: <4FBA4967.8070708@oracle.com>

Hi Jonathan,

Sorry for the delay, I was on vacation...

I applied your patch and got the following results (see attached 
screenshot). If you magnify the image you will see that focus rectangle 
is moved to left on 1 pixel. Is it possible to fix that?

All other changes looks good for me (except unnecessary "containerParent 
!= null" checking, as I said before)

Regards, Pavel

> 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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: s.png
Type: image/png
Size: 31076 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120521/b9cedfa9/s.png>

From luchsh at linux.vnet.ibm.com  Tue May 22 13:38:56 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 22 May 2012 21:38:56 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4FBA4967.8070708@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> <4F7EA17D.1000902@linux.vnet.ibm.com>
	<4FBA4967.8070708@oracle.com>
Message-ID: <4FBB96F0.1060006@linux.vnet.ibm.com>

Hi Pavel,

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

The shifting pixel problem was fix following the widget geometry 
documents from
http://svn.gnome.org/viewvc/gtk%2B/trunk/docs/widget_geometry.txt?view=markup

Could you please take a look?

Thanks!
- Jonathan

On 05/21/2012 09:55 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>
> Sorry for the delay, I was on vacation...
>
> I applied your patch and got the following results (see attached 
> screenshot). If you magnify the image you will see that focus 
> rectangle is moved to left on 1 pixel. Is it possible to fix that?
>
> All other changes looks good for me (except unnecessary 
> "containerParent != null" checking, as I said before)
>
> Regards, Pavel
>
>> 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  Tue May 22 15:14:38 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 22 May 2012 19:14:38 +0400
Subject: <Swing Dev> JList MULTIPLE_INTERVAL_SELECTION
In-Reply-To: <CAO02FZLTqJf0kbmOB22KUH95++b=OKDDNo_4iXxtFJtX8jtqSw@mail.gmail.com>
References: <CAO02FZLTqJf0kbmOB22KUH95++b=OKDDNo_4iXxtFJtX8jtqSw@mail.gmail.com>
Message-ID: <4FBBAD5E.4020408@oracle.com>

Hi Paulo,

I don't think such changes are necessary because of two reasons:
1. There is a simple workaround
2. In such case we should implement something like 
SINGLE_INTERVAL_SELECTION_DEFENSIVE as well

Regards, Pavel
> Glazed list as a feature, that i consider more like a bug fix:
>
>
>     /**
>      * A selection mode where any element may be selected and freshly 
> added elements
>      * are always deselected. No equivalent policy exists in
>      * {@link javax.swing.ListSelectionModel}
>      */
>     public static final int MULTIPLE_INTERVAL_SELECTION_DEFENSIVE = 103;
>
>
> used like this:
> DefaultEventSelectionModel esm = new DefaultEventSelectionModel(sorted);
> esm.setSelectionMode(ListSelection.MULTIPLE_INTERVAL_SELECTION_DEFENSIVE);
>
> I've only seen the need to use it intheir filtering classes yet 
> (because they are constantly adding elements)
> but it really seems like a bug of MULTIPLE_INTERVAL_SELECTION.
> Part of the DefaultEventSelectionModel javadoc:
>
>  * <p>Alongside <code>MULTIPLE_INTERVAL_SELECTION</code>, this {@link 
> ListSelectionModel}
>  * supports an additional selection mode.
>  * <code>MULTIPLE_INTERVAL_SELECTION_DEFENSIVE</code> is a new 
> selection mode.
>  * It is identical to <code>MULTIPLE_INTERVAL_SELECTION</code> in 
> every way but
>  * one. When a row is inserted immediately before a selected row in the
>  * <code>MULTIPLE_INTERVAL_SELECTION</code> mode, it becomes selected. 
> But in
>  * the <code>MULTIPLE_INTERVAL_SELECTION_DEFENSIVE</code> mode, it 
> does not
>  * become selected.



From pavel.porvatov at oracle.com  Tue May 22 15:18:18 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 22 May 2012 19:18:18 +0400
Subject: <Swing Dev> hello
In-Reply-To: <1336582653.66786.YahooMailNeo@web171602.mail.ir2.yahoo.com>
References: <1336582653.66786.YahooMailNeo@web171602.mail.ir2.yahoo.com>
Message-ID: <4FBBAE3A.4080806@oracle.com>

Hi Thierry,
> Hello
>  I try to add functionality to the library swing.
> As elements all ready high-level and modifiable,
> in a structured data model.
>
> if you're interested, I'm starting to realize it or manage.
Could you please clarify, what are you talking about?

Thanks, Pavel
>
> best regard
> Thierry Sauvageot
> 33 (0) 952731917
> 33 (0) 651552736

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

From neugens.limasoftware at gmail.com  Tue May 22 19:48:21 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Tue, 22 May 2012 21:48:21 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
Message-ID: <CAGUMyaRbDzcy-RXLwUv1vs-PfFN1jc=OW9OTCkqrtDqx4eN2cw@mail.gmail.com>

Ping?

Mario

2012/5/14 Mario Torre <neugens.limasoftware at gmail.com>:
> Hi Pavel,
>
> I uploaded a new patch here:
>
> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>
> I don't really understand why one should call internal private api
> (realSync) when a public API is there (Toolkit.sync), that *should* do
> the same (even if it obviously doesn't).
>
> Anyway, I hope this version is good enough for you to go in.
>
> Please, let me know what you think,
> Mario
>
> 2012/5/4 Pavel Porvatov <pavel.porvatov at oracle.com>:
>> Hi Mario,
>>
>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>
>>> Hi Pavel,
>>>
>>>> About the test:
>>>> 1. Now is 2012 :)
>>>
>>> Ops...
>>>
>>>> 2. You must access to Swing components only from the EDT (see
>>>> clickOnComponent(final Component comp) and other methods)
>>>
>>> Not sure if I understand correctly, all the access is done in the EDT
>>> already, unless I became very blind!
>>>
>>> The tests are run from the EDT, only exception is checkPopup, which
>>> just read a value after the execution, and I think this should be
>>> safe.
>>
>> Yes, I missed the fact that the clickOnComponent method invoked on EDT.
>> That's because you used robot.delay(50) in the method. There is no sense to
>> use sleep methods on the EDT therad: you just freeze any event handling....
>>
>>>> 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
>>>
>>> Actually, this means duplicate more code or introduce another method,
>>> not sure if this makes the code cleaner, but I can do it if you prefer
>>> so.
>>>
>>>> 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
>>>
>>> The reason why the test is so complex is that I wanted to throw the
>>> exact exception and don't mix the reflection related stuff with the
>>> real test exception, that also basically means I don't want to save
>>> the exception and rethrow it later on (I've seen this in some other
>>> tests), I rather prefer to make this obvious and not hidden, but of
>>> course the code gets longer, and everything is complicated by the EDT
>>> invocations.
>>
>> In your case reflection exception is also test failing.
>>
>>> Also, I'm not particularly happy with the use of reflection to access
>>> the filed and check the class name, since we're testing against an
>>> implementation detail, but I don't know how else I should test that we
>>> create an heavy weight window (which is really also just an
>>> implementation detail that leaked through the code up to the user,
>>> nobody should ever care about heavy weight and lightweight imho), so
>>> if you have a smarter idea, I would be happy to change the code.
>>
>> I'm also trying to avoid reflection in tests but I don't see another
>> solution here
>>
>>> I will try to refactor the code but I would like to not invest
>>> significant time in that, I'll send you a revised patch later
>>> (hopefully!)
>>
>> Yes, and that's the reason to write first version of test without any
>> errors. The test shouldn't have errors, because if it fails (on some
>> platforms with very specific configuration) we have to fix it (therefore we
>> are trying to keep all tests as clear and short as possible)...
>>
>> Your test is still have problems. E.g. setVisible invocation doesn't
>> guarantee that right after method Frame becomes visible (platforms dependent
>> behaviour). You can take a look at good test examples in repository, e.g.
>> here
>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>
>> Regards, Pavel
>>
>
>
>
> --
> 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 May 24 10:44:47 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 24 May 2012 14:44:47 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
Message-ID: <4FBE111F.4040502@oracle.com>

Hi Mario,

> Hi Pavel,
>
> I uploaded a new patch here:
>
> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>
> I don't really understand why one should call internal private api
> (realSync) when a public API is there (Toolkit.sync), that *should* do
> the same (even if it obviously doesn't).
Why do you think they should do the same?
>
> Anyway, I hope this version is good enough for you to go in.
Now the test looks without functionality problems but there are some 
code style mistakes and unnecessary code. E.g. duplicate code in the 
main method, class field passing as method parameters (the getPopup 
method) etc.

To avoid time spending I modified your test a little bit (see attach) 
and approve the fix.

Regards, Pavel
> Please, let me know what you think,
> Mario
>
> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>> Hi Mario,
>>
>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>
>>> Hi Pavel,
>>>
>>>> About the test:
>>>> 1. Now is 2012 :)
>>> Ops...
>>>
>>>> 2. You must access to Swing components only from the EDT (see
>>>> clickOnComponent(final Component comp) and other methods)
>>> Not sure if I understand correctly, all the access is done in the EDT
>>> already, unless I became very blind!
>>>
>>> The tests are run from the EDT, only exception is checkPopup, which
>>> just read a value after the execution, and I think this should be
>>> safe.
>> Yes, I missed the fact that the clickOnComponent method invoked on EDT.
>> That's because you used robot.delay(50) in the method. There is no sense to
>> use sleep methods on the EDT therad: you just freeze any event handling....
>>
>>>> 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
>>> Actually, this means duplicate more code or introduce another method,
>>> not sure if this makes the code cleaner, but I can do it if you prefer
>>> so.
>>>
>>>> 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
>>> The reason why the test is so complex is that I wanted to throw the
>>> exact exception and don't mix the reflection related stuff with the
>>> real test exception, that also basically means I don't want to save
>>> the exception and rethrow it later on (I've seen this in some other
>>> tests), I rather prefer to make this obvious and not hidden, but of
>>> course the code gets longer, and everything is complicated by the EDT
>>> invocations.
>> In your case reflection exception is also test failing.
>>
>>> Also, I'm not particularly happy with the use of reflection to access
>>> the filed and check the class name, since we're testing against an
>>> implementation detail, but I don't know how else I should test that we
>>> create an heavy weight window (which is really also just an
>>> implementation detail that leaked through the code up to the user,
>>> nobody should ever care about heavy weight and lightweight imho), so
>>> if you have a smarter idea, I would be happy to change the code.
>> I'm also trying to avoid reflection in tests but I don't see another
>> solution here
>>
>>> I will try to refactor the code but I would like to not invest
>>> significant time in that, I'll send you a revised patch later
>>> (hopefully!)
>> Yes, and that's the reason to write first version of test without any
>> errors. The test shouldn't have errors, because if it fails (on some
>> platforms with very specific configuration) we have to fix it (therefore we
>> are trying to keep all tests as clear and short as possible)...
>>
>> Your test is still have problems. E.g. setVisible invocation doesn't
>> guarantee that right after method Frame becomes visible (platforms dependent
>> behaviour). You can take a look at good test examples in repository, e.g.
>> here
>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>
>> Regards, Pavel
>>
>
>

-------------- next part --------------
/*
 * Copyright 2012 Red Hat, Inc.  All Rights Reserved.
 * 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.
 */

/*
 * @test
 * @bug 6800513
 * @summary GTK-LaF renders menus incompletely
 * @author Mario Torre
 * @library ../../regtesthelpers/
 * @build Util
 * @run main bug6800513
 */

import sun.awt.SunToolkit;

import javax.swing.*;
import java.awt.*;
import java.awt.event.InputEvent;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.lang.reflect.Field;
import java.util.concurrent.Callable;

public class bug6800513 {

    private static JPopupMenu popupMenu;
    private static JMenu menu;
    private static JFrame frame;

    public static void testFrame(final boolean defaultLightWeightPopupEnabled,
            String expectedPopupClass) throws Exception {
        SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();

        SwingUtilities.invokeAndWait(new Runnable() {
            public void run() {
                JPopupMenu.setDefaultLightWeightPopupEnabled(defaultLightWeightPopupEnabled);
                createAndShowUI();
            }
        });

        toolkit.realSync();

        clickOnMenu();

        toolkit.realSync();

        Field getPopup = JPopupMenu.class.getDeclaredField("popup");
        getPopup.setAccessible(true);
        Popup popup = (Popup) getPopup.get(popupMenu);

        if (popup == null) {
            throw new Exception("popup is null!");
        }

        String className = popup.getClass().getName();
        if (!className.equals(expectedPopupClass)) {
            throw new Exception("popup class is: " + className +
                    ", expected: " + expectedPopupClass);
        }

        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                frame.dispose();
                popupMenu = null;
            }
        });

        toolkit.realSync();
    }


    public static void clickOnMenu() throws Exception {
        Rectangle bounds = Util.invokeOnEDT(new Callable<Rectangle>() {
            @Override
            public Rectangle call() throws Exception {
                return new Rectangle(menu.getLocationOnScreen(), menu.getSize());
            }
        });

        Robot robot = new Robot();
        robot.setAutoDelay(100);

        robot.mouseMove(bounds.x + bounds.width / 2, bounds.y + bounds.height / 2);

        robot.mousePress(InputEvent.BUTTON1_MASK);
        robot.mouseRelease(InputEvent.BUTTON1_MASK);
    }

    private static class PopupListener implements PropertyChangeListener {
        @Override
        public void propertyChange(PropertyChangeEvent evt) {
            if (evt.toString().contains("visible") && ((Boolean) evt.getNewValue() == true)) {
                popupMenu = (JPopupMenu) evt.getSource();
            }
        }
    }

    public static void createAndShowUI() {
        frame = new JFrame();

        JMenuBar menuBar = new JMenuBar();
        menu = new JMenu("Menu");

        menu.add(new JMenuItem("Menu Item #1"));
        menu.add(new JMenuItem("Menu Item #2"));
        menu.add(new JMenuItem("Menu Item #3"));

        menuBar.add(menu);

        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setJMenuBar(menuBar);
        frame.setSize(500, 500);

        PopupListener listener = new PopupListener();
        menu.getPopupMenu().addPropertyChangeListener(listener);

        frame.setVisible(true);
    }

    public static void main(String[] args) throws Exception {
        testFrame(false, "javax.swing.PopupFactory$HeavyWeightPopup");

        testFrame(true, "javax.swing.PopupFactory$LightWeightPopup");
    }
}

From pavel.porvatov at oracle.com  Thu May 24 15:29:57 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 24 May 2012 19:29:57 +0400
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4FBB96F0.1060006@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>
	<4FBA4967.8070708@oracle.com> <4FBB96F0.1060006@linux.vnet.ibm.com>
Message-ID: <4FBE53F5.2090901@oracle.com>

Hi Jonathan,

Now focused JComboBox looks good. But it's not clear for me where did 
you find the following constants:

+                        x += 3 * focusSize;
+                        y += 2 * focusSize;
+                        w -= 3 * focusSize;
+                        h -= 4 * focusSize;

?

I took a look at the 
http://svn.gnome.org/viewvc/gtk%2B/trunk/docs/widget_geometry.txt?view=markup 
page but didn't find such information.

Regards, Pavel
> Hi Pavel,
>
> Here's the updated patch,
> http://cr.openjdk.java.net/~luchsh/7155887_4/
>
> The shifting pixel problem was fix following the widget geometry 
> documents from
> http://svn.gnome.org/viewvc/gtk%2B/trunk/docs/widget_geometry.txt?view=markup 
>
>
> Could you please take a look?
>
> Thanks!
> - Jonathan
>
> On 05/21/2012 09:55 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>
>> Sorry for the delay, I was on vacation...
>>
>> I applied your patch and got the following results (see attached 
>> screenshot). If you magnify the image you will see that focus 
>> rectangle is moved to left on 1 pixel. Is it possible to fix that?
>>
>> All other changes looks good for me (except unnecessary 
>> "containerParent != null" checking, as I said before)
>>
>> Regards, Pavel
>>
>>> 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 neugens.limasoftware at gmail.com  Fri May 25 12:19:09 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 25 May 2012 14:19:09 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FBE111F.4040502@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>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
Message-ID: <CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>

Hi Pavel,

Thanks,

I've pushed to the awt gate.

Cheers,
Mario

2012/5/24 Pavel Porvatov <pavel.porvatov at oracle.com>:
> Hi Mario,
>
>
>> Hi Pavel,
>>
>> I uploaded a new patch here:
>>
>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>
>> I don't really understand why one should call internal private api
>> (realSync) when a public API is there (Toolkit.sync), that *should* do
>> the same (even if it obviously doesn't).
>
> Why do you think they should do the same?
>
>>
>> Anyway, I hope this version is good enough for you to go in.
>
> Now the test looks without functionality problems but there are some code
> style mistakes and unnecessary code. E.g. duplicate code in the main method,
> class field passing as method parameters (the getPopup method) etc.
>
> To avoid time spending I modified your test a little bit (see attach) and
> approve the fix.
>
> Regards, Pavel
>
>> Please, let me know what you think,
>> Mario
>>
>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>
>>> Hi Mario,
>>>
>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>
>>>> Hi Pavel,
>>>>
>>>>> About the test:
>>>>> 1. Now is 2012 :)
>>>>
>>>> Ops...
>>>>
>>>>> 2. You must access to Swing components only from the EDT (see
>>>>> clickOnComponent(final Component comp) and other methods)
>>>>
>>>> Not sure if I understand correctly, all the access is done in the EDT
>>>> already, unless I became very blind!
>>>>
>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>> just read a value after the execution, and I think this should be
>>>> safe.
>>>
>>> Yes, I missed the fact that the clickOnComponent method invoked on EDT.
>>> That's because you used robot.delay(50) in the method. There is no sense
>>> to
>>> use sleep methods on the EDT therad: you just freeze any event
>>> handling....
>>>
>>>>> 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
>>>>
>>>> Actually, this means duplicate more code or introduce another method,
>>>> not sure if this makes the code cleaner, but I can do it if you prefer
>>>> so.
>>>>
>>>>> 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
>>>>
>>>> The reason why the test is so complex is that I wanted to throw the
>>>> exact exception and don't mix the reflection related stuff with the
>>>> real test exception, that also basically means I don't want to save
>>>> the exception and rethrow it later on (I've seen this in some other
>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>> course the code gets longer, and everything is complicated by the EDT
>>>> invocations.
>>>
>>> In your case reflection exception is also test failing.
>>>
>>>> Also, I'm not particularly happy with the use of reflection to access
>>>> the filed and check the class name, since we're testing against an
>>>> implementation detail, but I don't know how else I should test that we
>>>> create an heavy weight window (which is really also just an
>>>> implementation detail that leaked through the code up to the user,
>>>> nobody should ever care about heavy weight and lightweight imho), so
>>>> if you have a smarter idea, I would be happy to change the code.
>>>
>>> I'm also trying to avoid reflection in tests but I don't see another
>>> solution here
>>>
>>>> I will try to refactor the code but I would like to not invest
>>>> significant time in that, I'll send you a revised patch later
>>>> (hopefully!)
>>>
>>> Yes, and that's the reason to write first version of test without any
>>> errors. The test shouldn't have errors, because if it fails (on some
>>> platforms with very specific configuration) we have to fix it (therefore
>>> we
>>> are trying to keep all tests as clear and short as possible)...
>>>
>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>> guarantee that right after method Frame becomes visible (platforms
>>> dependent
>>> behaviour). You can take a look at good test examples in repository, e.g.
>>> here
>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>
>>> Regards, Pavel
>>>
>>
>>
>



-- 
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 neugens.limasoftware at gmail.com  Fri May 25 12:24:04 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 25 May 2012 14:24:04 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
Message-ID: <CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>

Ops, I just noticed that the test was not in the changeset, I applied
the patch on a clean tree and apparently forgot to do hg add...

Should i push it with the same bug id? or do I need another id for that?

Cheers,
Mario

2012/5/25 Mario Torre <neugens.limasoftware at gmail.com>:
> Hi Pavel,
>
> Thanks,
>
> I've pushed to the awt gate.
>
> Cheers,
> Mario
>
> 2012/5/24 Pavel Porvatov <pavel.porvatov at oracle.com>:
>> Hi Mario,
>>
>>
>>> Hi Pavel,
>>>
>>> I uploaded a new patch here:
>>>
>>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>>
>>> I don't really understand why one should call internal private api
>>> (realSync) when a public API is there (Toolkit.sync), that *should* do
>>> the same (even if it obviously doesn't).
>>
>> Why do you think they should do the same?
>>
>>>
>>> Anyway, I hope this version is good enough for you to go in.
>>
>> Now the test looks without functionality problems but there are some code
>> style mistakes and unnecessary code. E.g. duplicate code in the main method,
>> class field passing as method parameters (the getPopup method) etc.
>>
>> To avoid time spending I modified your test a little bit (see attach) and
>> approve the fix.
>>
>> Regards, Pavel
>>
>>> Please, let me know what you think,
>>> Mario
>>>
>>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>
>>>> Hi Mario,
>>>>
>>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>
>>>>> Hi Pavel,
>>>>>
>>>>>> About the test:
>>>>>> 1. Now is 2012 :)
>>>>>
>>>>> Ops...
>>>>>
>>>>>> 2. You must access to Swing components only from the EDT (see
>>>>>> clickOnComponent(final Component comp) and other methods)
>>>>>
>>>>> Not sure if I understand correctly, all the access is done in the EDT
>>>>> already, unless I became very blind!
>>>>>
>>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>>> just read a value after the execution, and I think this should be
>>>>> safe.
>>>>
>>>> Yes, I missed the fact that the clickOnComponent method invoked on EDT.
>>>> That's because you used robot.delay(50) in the method. There is no sense
>>>> to
>>>> use sleep methods on the EDT therad: you just freeze any event
>>>> handling....
>>>>
>>>>>> 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
>>>>>
>>>>> Actually, this means duplicate more code or introduce another method,
>>>>> not sure if this makes the code cleaner, but I can do it if you prefer
>>>>> so.
>>>>>
>>>>>> 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
>>>>>
>>>>> The reason why the test is so complex is that I wanted to throw the
>>>>> exact exception and don't mix the reflection related stuff with the
>>>>> real test exception, that also basically means I don't want to save
>>>>> the exception and rethrow it later on (I've seen this in some other
>>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>>> course the code gets longer, and everything is complicated by the EDT
>>>>> invocations.
>>>>
>>>> In your case reflection exception is also test failing.
>>>>
>>>>> Also, I'm not particularly happy with the use of reflection to access
>>>>> the filed and check the class name, since we're testing against an
>>>>> implementation detail, but I don't know how else I should test that we
>>>>> create an heavy weight window (which is really also just an
>>>>> implementation detail that leaked through the code up to the user,
>>>>> nobody should ever care about heavy weight and lightweight imho), so
>>>>> if you have a smarter idea, I would be happy to change the code.
>>>>
>>>> I'm also trying to avoid reflection in tests but I don't see another
>>>> solution here
>>>>
>>>>> I will try to refactor the code but I would like to not invest
>>>>> significant time in that, I'll send you a revised patch later
>>>>> (hopefully!)
>>>>
>>>> Yes, and that's the reason to write first version of test without any
>>>> errors. The test shouldn't have errors, because if it fails (on some
>>>> platforms with very specific configuration) we have to fix it (therefore
>>>> we
>>>> are trying to keep all tests as clear and short as possible)...
>>>>
>>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>>> guarantee that right after method Frame becomes visible (platforms
>>>> dependent
>>>> behaviour). You can take a look at good test examples in repository, e.g.
>>>> here
>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>>
>>>> Regards, Pavel
>>>>
>>>
>>>
>>
>
>
>
> --
> 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 alexandr.scherbatiy at oracle.com  Fri May 25 13:45:12 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 25 May 2012 17:45:12 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@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>	<4F92D7EA.6090504@oracle.com>	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>	<4FA3DCD5.2090005@oracle.com>	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>	<4FBE111F.4040502@oracle.com>	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
Message-ID: <4FBF8CE8.8040606@oracle.com>

On 5/25/2012 4:24 PM, Mario Torre wrote:
> Ops, I just noticed that the test was not in the changeset, I applied
> the patch on a clean tree and apparently forgot to do hg add...
>
> Should i push it with the same bug id? or do I need another id for that?

     I guess that it is not possible to make one more commit with the 
same bug id.

     Just create an issue that the test should be added to the repository.

     Thanks,
     Alexandr.

> Cheers,
> Mario
>
> 2012/5/25 Mario Torre<neugens.limasoftware at gmail.com>:
>> Hi Pavel,
>>
>> Thanks,
>>
>> I've pushed to the awt gate.
>>
>> Cheers,
>> Mario
>>
>> 2012/5/24 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>> Hi Mario,
>>>
>>>
>>>> Hi Pavel,
>>>>
>>>> I uploaded a new patch here:
>>>>
>>>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>>>
>>>> I don't really understand why one should call internal private api
>>>> (realSync) when a public API is there (Toolkit.sync), that *should* do
>>>> the same (even if it obviously doesn't).
>>> Why do you think they should do the same?
>>>
>>>> Anyway, I hope this version is good enough for you to go in.
>>> Now the test looks without functionality problems but there are some code
>>> style mistakes and unnecessary code. E.g. duplicate code in the main method,
>>> class field passing as method parameters (the getPopup method) etc.
>>>
>>> To avoid time spending I modified your test a little bit (see attach) and
>>> approve the fix.
>>>
>>> Regards, Pavel
>>>
>>>> Please, let me know what you think,
>>>> Mario
>>>>
>>>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>> Hi Mario,
>>>>>
>>>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>
>>>>>> Hi Pavel,
>>>>>>
>>>>>>> About the test:
>>>>>>> 1. Now is 2012 :)
>>>>>> Ops...
>>>>>>
>>>>>>> 2. You must access to Swing components only from the EDT (see
>>>>>>> clickOnComponent(final Component comp) and other methods)
>>>>>> Not sure if I understand correctly, all the access is done in the EDT
>>>>>> already, unless I became very blind!
>>>>>>
>>>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>>>> just read a value after the execution, and I think this should be
>>>>>> safe.
>>>>> Yes, I missed the fact that the clickOnComponent method invoked on EDT.
>>>>> That's because you used robot.delay(50) in the method. There is no sense
>>>>> to
>>>>> use sleep methods on the EDT therad: you just freeze any event
>>>>> handling....
>>>>>
>>>>>>> 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
>>>>>> Actually, this means duplicate more code or introduce another method,
>>>>>> not sure if this makes the code cleaner, but I can do it if you prefer
>>>>>> so.
>>>>>>
>>>>>>> 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
>>>>>> The reason why the test is so complex is that I wanted to throw the
>>>>>> exact exception and don't mix the reflection related stuff with the
>>>>>> real test exception, that also basically means I don't want to save
>>>>>> the exception and rethrow it later on (I've seen this in some other
>>>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>>>> course the code gets longer, and everything is complicated by the EDT
>>>>>> invocations.
>>>>> In your case reflection exception is also test failing.
>>>>>
>>>>>> Also, I'm not particularly happy with the use of reflection to access
>>>>>> the filed and check the class name, since we're testing against an
>>>>>> implementation detail, but I don't know how else I should test that we
>>>>>> create an heavy weight window (which is really also just an
>>>>>> implementation detail that leaked through the code up to the user,
>>>>>> nobody should ever care about heavy weight and lightweight imho), so
>>>>>> if you have a smarter idea, I would be happy to change the code.
>>>>> I'm also trying to avoid reflection in tests but I don't see another
>>>>> solution here
>>>>>
>>>>>> I will try to refactor the code but I would like to not invest
>>>>>> significant time in that, I'll send you a revised patch later
>>>>>> (hopefully!)
>>>>> Yes, and that's the reason to write first version of test without any
>>>>> errors. The test shouldn't have errors, because if it fails (on some
>>>>> platforms with very specific configuration) we have to fix it (therefore
>>>>> we
>>>>> are trying to keep all tests as clear and short as possible)...
>>>>>
>>>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>>>> guarantee that right after method Frame becomes visible (platforms
>>>>> dependent
>>>>> behaviour). You can take a look at good test examples in repository, e.g.
>>>>> here
>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>
>>
>>
>> --
>> 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 neugens.limasoftware at gmail.com  Fri May 25 13:54:41 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 25 May 2012 15:54:41 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FBF8CE8.8040606@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>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
Message-ID: <CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>

I created one:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806

Should I wait that it becomes public or can i just push the "fix"
right away (same reviewer and repository of course)?

Cheers,
Mario

2012/5/25 Alexander Scherbatiy <alexandr.scherbatiy at oracle.com>:
> On 5/25/2012 4:24 PM, Mario Torre wrote:
>>
>> Ops, I just noticed that the test was not in the changeset, I applied
>> the patch on a clean tree and apparently forgot to do hg add...
>>
>> Should i push it with the same bug id? or do I need another id for that?
>
>
> ? ?I guess that it is not possible to make one more commit with the same bug
> id.
>
> ? ?Just create an issue that the test should be added to the repository.
>
> ? ?Thanks,
> ? ?Alexandr.
>
>
>> Cheers,
>> Mario
>>
>> 2012/5/25 Mario Torre<neugens.limasoftware at gmail.com>:
>>>
>>> Hi Pavel,
>>>
>>> Thanks,
>>>
>>> I've pushed to the awt gate.
>>>
>>> Cheers,
>>> Mario
>>>
>>> 2012/5/24 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>
>>>> Hi Mario,
>>>>
>>>>
>>>>> Hi Pavel,
>>>>>
>>>>> I uploaded a new patch here:
>>>>>
>>>>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>>>>
>>>>> I don't really understand why one should call internal private api
>>>>> (realSync) when a public API is there (Toolkit.sync), that *should* do
>>>>> the same (even if it obviously doesn't).
>>>>
>>>> Why do you think they should do the same?
>>>>
>>>>> Anyway, I hope this version is good enough for you to go in.
>>>>
>>>> Now the test looks without functionality problems but there are some
>>>> code
>>>> style mistakes and unnecessary code. E.g. duplicate code in the main
>>>> method,
>>>> class field passing as method parameters (the getPopup method) etc.
>>>>
>>>> To avoid time spending I modified your test a little bit (see attach)
>>>> and
>>>> approve the fix.
>>>>
>>>> Regards, Pavel
>>>>
>>>>> Please, let me know what you think,
>>>>> Mario
>>>>>
>>>>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>
>>>>>> Hi Mario,
>>>>>>
>>>>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>>
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>>> About the test:
>>>>>>>> 1. Now is 2012 :)
>>>>>>>
>>>>>>> Ops...
>>>>>>>
>>>>>>>> 2. You must access to Swing components only from the EDT (see
>>>>>>>> clickOnComponent(final Component comp) and other methods)
>>>>>>>
>>>>>>> Not sure if I understand correctly, all the access is done in the EDT
>>>>>>> already, unless I became very blind!
>>>>>>>
>>>>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>>>>> just read a value after the execution, and I think this should be
>>>>>>> safe.
>>>>>>
>>>>>> Yes, I missed the fact that the clickOnComponent method invoked on
>>>>>> EDT.
>>>>>> That's because you used robot.delay(50) in the method. There is no
>>>>>> sense
>>>>>> to
>>>>>> use sleep methods on the EDT therad: you just freeze any event
>>>>>> handling....
>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>> Actually, this means duplicate more code or introduce another method,
>>>>>>> not sure if this makes the code cleaner, but I can do it if you
>>>>>>> prefer
>>>>>>> so.
>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>> The reason why the test is so complex is that I wanted to throw the
>>>>>>> exact exception and don't mix the reflection related stuff with the
>>>>>>> real test exception, that also basically means I don't want to save
>>>>>>> the exception and rethrow it later on (I've seen this in some other
>>>>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>>>>> course the code gets longer, and everything is complicated by the EDT
>>>>>>> invocations.
>>>>>>
>>>>>> In your case reflection exception is also test failing.
>>>>>>
>>>>>>> Also, I'm not particularly happy with the use of reflection to access
>>>>>>> the filed and check the class name, since we're testing against an
>>>>>>> implementation detail, but I don't know how else I should test that
>>>>>>> we
>>>>>>> create an heavy weight window (which is really also just an
>>>>>>> implementation detail that leaked through the code up to the user,
>>>>>>> nobody should ever care about heavy weight and lightweight imho), so
>>>>>>> if you have a smarter idea, I would be happy to change the code.
>>>>>>
>>>>>> I'm also trying to avoid reflection in tests but I don't see another
>>>>>> solution here
>>>>>>
>>>>>>> I will try to refactor the code but I would like to not invest
>>>>>>> significant time in that, I'll send you a revised patch later
>>>>>>> (hopefully!)
>>>>>>
>>>>>> Yes, and that's the reason to write first version of test without any
>>>>>> errors. The test shouldn't have errors, because if it fails (on some
>>>>>> platforms with very specific configuration) we have to fix it
>>>>>> (therefore
>>>>>> we
>>>>>> are trying to keep all tests as clear and short as possible)...
>>>>>>
>>>>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>>>>> guarantee that right after method Frame becomes visible (platforms
>>>>>> dependent
>>>>>> behaviour). You can take a look at good test examples in repository,
>>>>>> e.g.
>>>>>> here
>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>>>>
>>>>>> Regards, Pavel
>>>>>>
>>>>>
>>>
>>>
>>> --
>>> 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 alexandr.scherbatiy at oracle.com  Mon May 28 10:16:31 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 28 May 2012 14:16:31 +0400
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FB106DD.4030305@redhat.com>
References: <4F9A6392.1040002@redhat.com>
	<4F9A857E.80505@oracle.com>	<4F9AB0E1.8050303@redhat.com>
	<4F9BF24D.40507@oracle.com>	<4FA13223.8020409@redhat.com>
	<4FA265AF.1080202@oracle.com>	<4FA26EDF.5040300@redhat.com>
	<4FA29151.5050509@oracle.com> <4FA3A19E.3070107@redhat.com>
	<4FB106DD.4030305@redhat.com>
Message-ID: <4FC3507F.8000300@oracle.com>

On 5/14/2012 5:21 PM, Pavel Tisnovsky wrote:
> ping - can anybody please look at this issue?
      The 3d version of the fix looks good for me.

      Thanks,
      Alexandr.

> Thank you in advance,
> Pavel
>
>
> Pavel Tisnovsky wrote:
>> Pavel Porvatov wrote:
>>> Hi Pavel,
>>>> Alexander Scherbatiy wrote:
>>>>> On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
>>>>>> Hi Pavel and Alexander,
>>>>>> I've prepared second version of fix for TitledBorder class&    JTreg
>>>>>> test is
>>>>>> included too. Both changes can be seen here:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>>>>>>
>>>>>> Could you please look at it?
>>>>>       Just two brief questions.
>>>>>      - Why do we need the extra Font f variable? Is it possible to use
>>>>> only the titleFont?
>>>> Yes, you are right - it is not really needed, it only makes debugging
>>>> easier.
>>>> It's possible to shorten both getters to one liner.
>>> I'm also voting to remove unnecessary variable.
>> Hi Pavel and Alexander,
>>
>> here's third version of TitledBorder fix - getters now don't contain
>> any temporary variable:
>>
>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v3/
>>
>>>>>      - In case if the titleFont variable is null would it be better to
>>>>> set
>>>>> it to the default L&F font?
>>>>>        So in the next getTitleFont() call the
>>>>> UIManager.getFont("TitledBorder.font")  method will not be executed.
>>>> Hmm it might be better (it is even possible to do it directly in
>>>> setters which
>>>> could be called from constructor), but
>>>> it changes object state (it's attributes) and it IMHO could(?) cause
>>>> problems
>>>> with serialization and/or XML encoding. If you think it's not a problem
>>>> I'll be happy to create new version of this fix.
>>> I think we can't set variable, because after LAF changing the current
>>> functionality will be broken.
>>>
>>> BTW: why don't you use Oracle copyright in test header?
>> Well, I'm not Oracle employee ;-) I've asked Mark Reinhold about this
>> issue and he told me that it's ok to use RH copyright header.
>>
>> Thank,
>> Pavel
>>> Regards, Pavel
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>
>>>>>> Thank you in advance,
>>>>>> Pavel
>>>>>>
>>>>>>> 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



From ptisnovs at redhat.com  Mon May 28 11:02:50 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Mon, 28 May 2012 13:02:50 +0200
Subject: <Swing Dev> Reviewer needed: fix for TitledBorder class
In-Reply-To: <4FC3507F.8000300@oracle.com>
References: <4F9A6392.1040002@redhat.com>
	<4F9A857E.80505@oracle.com>	<4F9AB0E1.8050303@redhat.com>
	<4F9BF24D.40507@oracle.com>	<4FA13223.8020409@redhat.com>
	<4FA265AF.1080202@oracle.com>	<4FA26EDF.5040300@redhat.com>
	<4FA29151.5050509@oracle.com> <4FA3A19E.3070107@redhat.com>
	<4FB106DD.4030305@redhat.com> <4FC3507F.8000300@oracle.com>
Message-ID: <4FC35B5A.4040004@redhat.com>

Alexander Scherbatiy wrote:
> On 5/14/2012 5:21 PM, Pavel Tisnovsky wrote:
>> ping - can anybody please look at this issue?
>      The 3d version of the fix looks good for me.
> 
>      Thanks,
>      Alexandr.

That's great, TY Alexander.

> 
>> Thank you in advance,
>> Pavel
>>
>>
>> Pavel Tisnovsky wrote:
>>> Pavel Porvatov wrote:
>>>> Hi Pavel,
>>>>> Alexander Scherbatiy wrote:
>>>>>> On 5/2/2012 5:09 PM, Pavel Tisnovsky wrote:
>>>>>>> Hi Pavel and Alexander,
>>>>>>> I've prepared second version of fix for TitledBorder class&    JTreg
>>>>>>> test is
>>>>>>> included too. Both changes can be seen here:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v2/
>>>>>>>
>>>>>>> Could you please look at it?
>>>>>>       Just two brief questions.
>>>>>>      - Why do we need the extra Font f variable? Is it possible to
>>>>>> use
>>>>>> only the titleFont?
>>>>> Yes, you are right - it is not really needed, it only makes debugging
>>>>> easier.
>>>>> It's possible to shorten both getters to one liner.
>>>> I'm also voting to remove unnecessary variable.
>>> Hi Pavel and Alexander,
>>>
>>> here's third version of TitledBorder fix - getters now don't contain
>>> any temporary variable:
>>>
>>> http://cr.openjdk.java.net/~ptisnovs/TitledBorder_v3/
>>>
>>>>>>      - In case if the titleFont variable is null would it be
>>>>>> better to
>>>>>> set
>>>>>> it to the default L&F font?
>>>>>>        So in the next getTitleFont() call the
>>>>>> UIManager.getFont("TitledBorder.font")  method will not be executed.
>>>>> Hmm it might be better (it is even possible to do it directly in
>>>>> setters which
>>>>> could be called from constructor), but
>>>>> it changes object state (it's attributes) and it IMHO could(?) cause
>>>>> problems
>>>>> with serialization and/or XML encoding. If you think it's not a
>>>>> problem
>>>>> I'll be happy to create new version of this fix.
>>>> I think we can't set variable, because after LAF changing the current
>>>> functionality will be broken.
>>>>
>>>> BTW: why don't you use Oracle copyright in test header?
>>> Well, I'm not Oracle employee ;-) I've asked Mark Reinhold about this
>>> issue and he told me that it's ok to use RH copyright header.
>>>
>>> Thank,
>>> Pavel
>>>> Regards, Pavel
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>
>>>>>>> Thank you in advance,
>>>>>>> Pavel
>>>>>>>
>>>>>>>> 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
> 



From alexandr.scherbatiy at oracle.com  Wed May 30 09:49:55 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 30 May 2012 13:49:55 +0400
Subject: <Swing Dev> [8] Review request for 7146131 - [macosx] When click
 the show optionpane button,
 it display partly of dialog and hung until timeout
Message-ID: <4FC5ED43.4030401@oracle.com>

bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146131
webrev: http://cr.openjdk.java.net/~alexp/7146131/webrev.00/
changeset: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/fd9fe385f63c

This is a forward port of the issue which has not been automatically 
ported from the JDK 7u4 to JDK 8.

The code changes for JDK 8 are identical to the ones in JDK 7u4.

The issue is not reproduced in the JDK 8 with the applied patch.

Thanks,
Alexandr.



From alexandr.scherbatiy at oracle.com  Wed May 30 09:54:37 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 30 May 2012 13:54:37 +0400
Subject: <Swing Dev> [8] Review request for 7141296 - [macosx] Mouse Wheel
 Turn closes combobox popup
Message-ID: <4FC5EE5D.8030104@oracle.com>


bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141296
webrev: http://cr.openjdk.java.net/~alexp/7141296/webrev.01/
changeset: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/791f738fe301

This is a forward port of the issue which has not been automatically 
ported from the JDK 7u4 to JDK 8.

  The code changes for JDK 8 are identical to the ones in JDK 7u4.

The issue is not reproduced in the JDK 8 with the applied patch.

Thanks,
Alexandr.



From pavel.porvatov at oracle.com  Wed May 30 10:07:47 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 30 May 2012 14:07:47 +0400
Subject: <Swing Dev> [8] Review request for 7146131 - [macosx] When
 click the show optionpane button,
 it display partly of dialog and hung until timeout
In-Reply-To: <4FC5ED43.4030401@oracle.com>
References: <4FC5ED43.4030401@oracle.com>
Message-ID: <4FC5F173.8040708@oracle.com>

Looks good for me
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146131
> webrev: http://cr.openjdk.java.net/~alexp/7146131/webrev.00/
> changeset: 
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/fd9fe385f63c
>
> This is a forward port of the issue which has not been automatically 
> ported from the JDK 7u4 to JDK 8.
>
> The code changes for JDK 8 are identical to the ones in JDK 7u4.
>
> The issue is not reproduced in the JDK 8 with the applied patch.
>
> Thanks,
> Alexandr.
>



From pavel.porvatov at oracle.com  Wed May 30 10:09:13 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 30 May 2012 14:09:13 +0400
Subject: <Swing Dev> [8] Review request for 7141296 - [macosx] Mouse
 Wheel Turn closes combobox popup
In-Reply-To: <4FC5EE5D.8030104@oracle.com>
References: <4FC5EE5D.8030104@oracle.com>
Message-ID: <4FC5F1C9.2070806@oracle.com>

Looks good!
>
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141296
> webrev: http://cr.openjdk.java.net/~alexp/7141296/webrev.01/
> changeset: 
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/791f738fe301
>
> This is a forward port of the issue which has not been automatically 
> ported from the JDK 7u4 to JDK 8.
>
>  The code changes for JDK 8 are identical to the ones in JDK 7u4.
>
> The issue is not reproduced in the JDK 8 with the applied patch.
>
> Thanks,
> Alexandr.
>



From pavel.porvatov at oracle.com  Wed May 30 13:08:52 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 30 May 2012 17:08:52 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
Message-ID: <4FC61BE4.70603@oracle.com>

Hi Mario,

I marked CR 6800513 as fixed. Could you please push the test (with me as 
a reviewer)?

Thanks, Pavel
> I created one:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806
>
> Should I wait that it becomes public or can i just push the "fix"
> right away (same reviewer and repository of course)?
>
> Cheers,
> Mario
>
> 2012/5/25 Alexander Scherbatiy<alexandr.scherbatiy at oracle.com>:
>> On 5/25/2012 4:24 PM, Mario Torre wrote:
>>> Ops, I just noticed that the test was not in the changeset, I applied
>>> the patch on a clean tree and apparently forgot to do hg add...
>>>
>>> Should i push it with the same bug id? or do I need another id for that?
>>
>>     I guess that it is not possible to make one more commit with the same bug
>> id.
>>
>>     Just create an issue that the test should be added to the repository.
>>
>>     Thanks,
>>     Alexandr.
>>
>>
>>> Cheers,
>>> Mario
>>>
>>> 2012/5/25 Mario Torre<neugens.limasoftware at gmail.com>:
>>>> Hi Pavel,
>>>>
>>>> Thanks,
>>>>
>>>> I've pushed to the awt gate.
>>>>
>>>> Cheers,
>>>> Mario
>>>>
>>>> 2012/5/24 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>> Hi Mario,
>>>>>
>>>>>
>>>>>> Hi Pavel,
>>>>>>
>>>>>> I uploaded a new patch here:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>>>>>
>>>>>> I don't really understand why one should call internal private api
>>>>>> (realSync) when a public API is there (Toolkit.sync), that *should* do
>>>>>> the same (even if it obviously doesn't).
>>>>> Why do you think they should do the same?
>>>>>
>>>>>> Anyway, I hope this version is good enough for you to go in.
>>>>> Now the test looks without functionality problems but there are some
>>>>> code
>>>>> style mistakes and unnecessary code. E.g. duplicate code in the main
>>>>> method,
>>>>> class field passing as method parameters (the getPopup method) etc.
>>>>>
>>>>> To avoid time spending I modified your test a little bit (see attach)
>>>>> and
>>>>> approve the fix.
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>>> Please, let me know what you think,
>>>>>> Mario
>>>>>>
>>>>>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>> Hi Mario,
>>>>>>>
>>>>>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>>>
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>>> About the test:
>>>>>>>>> 1. Now is 2012 :)
>>>>>>>> Ops...
>>>>>>>>
>>>>>>>>> 2. You must access to Swing components only from the EDT (see
>>>>>>>>> clickOnComponent(final Component comp) and other methods)
>>>>>>>> Not sure if I understand correctly, all the access is done in the EDT
>>>>>>>> already, unless I became very blind!
>>>>>>>>
>>>>>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>>>>>> just read a value after the execution, and I think this should be
>>>>>>>> safe.
>>>>>>> Yes, I missed the fact that the clickOnComponent method invoked on
>>>>>>> EDT.
>>>>>>> That's because you used robot.delay(50) in the method. There is no
>>>>>>> sense
>>>>>>> to
>>>>>>> use sleep methods on the EDT therad: you just freeze any event
>>>>>>> handling....
>>>>>>>
>>>>>>>>> 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
>>>>>>>> Actually, this means duplicate more code or introduce another method,
>>>>>>>> not sure if this makes the code cleaner, but I can do it if you
>>>>>>>> prefer
>>>>>>>> so.
>>>>>>>>
>>>>>>>>> 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
>>>>>>>> The reason why the test is so complex is that I wanted to throw the
>>>>>>>> exact exception and don't mix the reflection related stuff with the
>>>>>>>> real test exception, that also basically means I don't want to save
>>>>>>>> the exception and rethrow it later on (I've seen this in some other
>>>>>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>>>>>> course the code gets longer, and everything is complicated by the EDT
>>>>>>>> invocations.
>>>>>>> In your case reflection exception is also test failing.
>>>>>>>
>>>>>>>> Also, I'm not particularly happy with the use of reflection to access
>>>>>>>> the filed and check the class name, since we're testing against an
>>>>>>>> implementation detail, but I don't know how else I should test that
>>>>>>>> we
>>>>>>>> create an heavy weight window (which is really also just an
>>>>>>>> implementation detail that leaked through the code up to the user,
>>>>>>>> nobody should ever care about heavy weight and lightweight imho), so
>>>>>>>> if you have a smarter idea, I would be happy to change the code.
>>>>>>> I'm also trying to avoid reflection in tests but I don't see another
>>>>>>> solution here
>>>>>>>
>>>>>>>> I will try to refactor the code but I would like to not invest
>>>>>>>> significant time in that, I'll send you a revised patch later
>>>>>>>> (hopefully!)
>>>>>>> Yes, and that's the reason to write first version of test without any
>>>>>>> errors. The test shouldn't have errors, because if it fails (on some
>>>>>>> platforms with very specific configuration) we have to fix it
>>>>>>> (therefore
>>>>>>> we
>>>>>>> are trying to keep all tests as clear and short as possible)...
>>>>>>>
>>>>>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>>>>>> guarantee that right after method Frame becomes visible (platforms
>>>>>>> dependent
>>>>>>> behaviour). You can take a look at good test examples in repository,
>>>>>>> e.g.
>>>>>>> here
>>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>>>>>
>>>>>>> Regards, Pavel
>>>>>>>
>>>>
>>>> --
>>>> 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 neugens.limasoftware at gmail.com  Wed May 30 13:17:45 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 30 May 2012 15:17:45 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FC61BE4.70603@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>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
Message-ID: <CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>

Hi Pavel, sure,

Should I use the
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806 that I
created as CR for the test or the same  CR 6800513?

Cheers,
Mario

2012/5/30 Pavel Porvatov <pavel.porvatov at oracle.com>:
> Hi Mario,
>
> I marked CR 6800513 as fixed. Could you please push the test (with me as a
> reviewer)?
>
> Thanks, Pavel
>
>> I created one:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806
>>
>> Should I wait that it becomes public or can i just push the "fix"
>> right away (same reviewer and repository of course)?
>>
>> Cheers,
>> Mario
>>
>> 2012/5/25 Alexander Scherbatiy<alexandr.scherbatiy at oracle.com>:
>>>
>>> On 5/25/2012 4:24 PM, Mario Torre wrote:
>>>>
>>>> Ops, I just noticed that the test was not in the changeset, I applied
>>>> the patch on a clean tree and apparently forgot to do hg add...
>>>>
>>>> Should i push it with the same bug id? or do I need another id for that?
>>>
>>>
>>> ? ?I guess that it is not possible to make one more commit with the same
>>> bug
>>> id.
>>>
>>> ? ?Just create an issue that the test should be added to the repository.
>>>
>>> ? ?Thanks,
>>> ? ?Alexandr.
>>>
>>>
>>>> Cheers,
>>>> Mario
>>>>
>>>> 2012/5/25 Mario Torre<neugens.limasoftware at gmail.com>:
>>>>>
>>>>> Hi Pavel,
>>>>>
>>>>> Thanks,
>>>>>
>>>>> I've pushed to the awt gate.
>>>>>
>>>>> Cheers,
>>>>> Mario
>>>>>
>>>>> 2012/5/24 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>
>>>>>> Hi Mario,
>>>>>>
>>>>>>
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> I uploaded a new patch here:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>>>>>>
>>>>>>> I don't really understand why one should call internal private api
>>>>>>> (realSync) when a public API is there (Toolkit.sync), that *should*
>>>>>>> do
>>>>>>> the same (even if it obviously doesn't).
>>>>>>
>>>>>> Why do you think they should do the same?
>>>>>>
>>>>>>> Anyway, I hope this version is good enough for you to go in.
>>>>>>
>>>>>> Now the test looks without functionality problems but there are some
>>>>>> code
>>>>>> style mistakes and unnecessary code. E.g. duplicate code in the main
>>>>>> method,
>>>>>> class field passing as method parameters (the getPopup method) etc.
>>>>>>
>>>>>> To avoid time spending I modified your test a little bit (see attach)
>>>>>> and
>>>>>> approve the fix.
>>>>>>
>>>>>> Regards, Pavel
>>>>>>
>>>>>>> Please, let me know what you think,
>>>>>>> Mario
>>>>>>>
>>>>>>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>>>
>>>>>>>> Hi Mario,
>>>>>>>>
>>>>>>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>>>>
>>>>>>>>> Hi Pavel,
>>>>>>>>>
>>>>>>>>>> About the test:
>>>>>>>>>> 1. Now is 2012 :)
>>>>>>>>>
>>>>>>>>> Ops...
>>>>>>>>>
>>>>>>>>>> 2. You must access to Swing components only from the EDT (see
>>>>>>>>>> clickOnComponent(final Component comp) and other methods)
>>>>>>>>>
>>>>>>>>> Not sure if I understand correctly, all the access is done in the
>>>>>>>>> EDT
>>>>>>>>> already, unless I became very blind!
>>>>>>>>>
>>>>>>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>>>>>>> just read a value after the execution, and I think this should be
>>>>>>>>> safe.
>>>>>>>>
>>>>>>>> Yes, I missed the fact that the clickOnComponent method invoked on
>>>>>>>> EDT.
>>>>>>>> That's because you used robot.delay(50) in the method. There is no
>>>>>>>> sense
>>>>>>>> to
>>>>>>>> use sleep methods on the EDT therad: you just freeze any event
>>>>>>>> handling....
>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Actually, this means duplicate more code or introduce another
>>>>>>>>> method,
>>>>>>>>> not sure if this makes the code cleaner, but I can do it if you
>>>>>>>>> prefer
>>>>>>>>> so.
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> The reason why the test is so complex is that I wanted to throw the
>>>>>>>>> exact exception and don't mix the reflection related stuff with the
>>>>>>>>> real test exception, that also basically means I don't want to save
>>>>>>>>> the exception and rethrow it later on (I've seen this in some other
>>>>>>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>>>>>>> course the code gets longer, and everything is complicated by the
>>>>>>>>> EDT
>>>>>>>>> invocations.
>>>>>>>>
>>>>>>>> In your case reflection exception is also test failing.
>>>>>>>>
>>>>>>>>> Also, I'm not particularly happy with the use of reflection to
>>>>>>>>> access
>>>>>>>>> the filed and check the class name, since we're testing against an
>>>>>>>>> implementation detail, but I don't know how else I should test that
>>>>>>>>> we
>>>>>>>>> create an heavy weight window (which is really also just an
>>>>>>>>> implementation detail that leaked through the code up to the user,
>>>>>>>>> nobody should ever care about heavy weight and lightweight imho),
>>>>>>>>> so
>>>>>>>>> if you have a smarter idea, I would be happy to change the code.
>>>>>>>>
>>>>>>>> I'm also trying to avoid reflection in tests but I don't see another
>>>>>>>> solution here
>>>>>>>>
>>>>>>>>> I will try to refactor the code but I would like to not invest
>>>>>>>>> significant time in that, I'll send you a revised patch later
>>>>>>>>> (hopefully!)
>>>>>>>>
>>>>>>>> Yes, and that's the reason to write first version of test without
>>>>>>>> any
>>>>>>>> errors. The test shouldn't have errors, because if it fails (on some
>>>>>>>> platforms with very specific configuration) we have to fix it
>>>>>>>> (therefore
>>>>>>>> we
>>>>>>>> are trying to keep all tests as clear and short as possible)...
>>>>>>>>
>>>>>>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>>>>>>> guarantee that right after method Frame becomes visible (platforms
>>>>>>>> dependent
>>>>>>>> behaviour). You can take a look at good test examples in repository,
>>>>>>>> e.g.
>>>>>>>> here
>>>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>>>>>>
>>>>>>>> Regards, Pavel
>>>>>>>>
>>>>>
>>>>> --
>>>>> 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  Wed May 30 13:54:28 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 30 May 2012 17:54:28 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@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>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
	<CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>
Message-ID: <4FC62694.1020007@oracle.com>

Hi Mario,
> Hi Pavel, sure,
>
> Should I use the
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806 that I
> created as CR for the test or the same  CR 6800513?
What do you mean? Don't change the name of the test and use comment like 
the following:
7171806: Missing test for bug ID 6800513 fix
Reviewed-by: rupashka

Regards, Pavel
>
> Cheers,
> Mario
>
> 2012/5/30 Pavel Porvatov<pavel.porvatov at oracle.com>:
>> Hi Mario,
>>
>> I marked CR 6800513 as fixed. Could you please push the test (with me as a
>> reviewer)?
>>
>> Thanks, Pavel
>>
>>> I created one:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806
>>>
>>> Should I wait that it becomes public or can i just push the "fix"
>>> right away (same reviewer and repository of course)?
>>>
>>> Cheers,
>>> Mario
>>>
>>> 2012/5/25 Alexander Scherbatiy<alexandr.scherbatiy at oracle.com>:
>>>> On 5/25/2012 4:24 PM, Mario Torre wrote:
>>>>> Ops, I just noticed that the test was not in the changeset, I applied
>>>>> the patch on a clean tree and apparently forgot to do hg add...
>>>>>
>>>>> Should i push it with the same bug id? or do I need another id for that?
>>>>
>>>>     I guess that it is not possible to make one more commit with the same
>>>> bug
>>>> id.
>>>>
>>>>     Just create an issue that the test should be added to the repository.
>>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>
>>>>
>>>>> Cheers,
>>>>> Mario
>>>>>
>>>>> 2012/5/25 Mario Torre<neugens.limasoftware at gmail.com>:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> I've pushed to the awt gate.
>>>>>>
>>>>>> Cheers,
>>>>>> Mario
>>>>>>
>>>>>> 2012/5/24 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>> Hi Mario,
>>>>>>>
>>>>>>>
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>> I uploaded a new patch here:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~neugens/6800513/webrev.02/
>>>>>>>>
>>>>>>>> I don't really understand why one should call internal private api
>>>>>>>> (realSync) when a public API is there (Toolkit.sync), that *should*
>>>>>>>> do
>>>>>>>> the same (even if it obviously doesn't).
>>>>>>> Why do you think they should do the same?
>>>>>>>
>>>>>>>> Anyway, I hope this version is good enough for you to go in.
>>>>>>> Now the test looks without functionality problems but there are some
>>>>>>> code
>>>>>>> style mistakes and unnecessary code. E.g. duplicate code in the main
>>>>>>> method,
>>>>>>> class field passing as method parameters (the getPopup method) etc.
>>>>>>>
>>>>>>> To avoid time spending I modified your test a little bit (see attach)
>>>>>>> and
>>>>>>> approve the fix.
>>>>>>>
>>>>>>> Regards, Pavel
>>>>>>>
>>>>>>>> Please, let me know what you think,
>>>>>>>> Mario
>>>>>>>>
>>>>>>>> 2012/5/4 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>>>> Hi Mario,
>>>>>>>>>
>>>>>>>>>> 2012/4/21 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>>>>>>>>>
>>>>>>>>>> Hi Pavel,
>>>>>>>>>>
>>>>>>>>>>> About the test:
>>>>>>>>>>> 1. Now is 2012 :)
>>>>>>>>>> Ops...
>>>>>>>>>>
>>>>>>>>>>> 2. You must access to Swing components only from the EDT (see
>>>>>>>>>>> clickOnComponent(final Component comp) and other methods)
>>>>>>>>>> Not sure if I understand correctly, all the access is done in the
>>>>>>>>>> EDT
>>>>>>>>>> already, unless I became very blind!
>>>>>>>>>>
>>>>>>>>>> The tests are run from the EDT, only exception is checkPopup, which
>>>>>>>>>> just read a value after the execution, and I think this should be
>>>>>>>>>> safe.
>>>>>>>>> Yes, I missed the fact that the clickOnComponent method invoked on
>>>>>>>>> EDT.
>>>>>>>>> That's because you used robot.delay(50) in the method. There is no
>>>>>>>>> sense
>>>>>>>>> to
>>>>>>>>> use sleep methods on the EDT therad: you just freeze any event
>>>>>>>>> handling....
>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>> Actually, this means duplicate more code or introduce another
>>>>>>>>>> method,
>>>>>>>>>> not sure if this makes the code cleaner, but I can do it if you
>>>>>>>>>> prefer
>>>>>>>>>> so.
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>> The reason why the test is so complex is that I wanted to throw the
>>>>>>>>>> exact exception and don't mix the reflection related stuff with the
>>>>>>>>>> real test exception, that also basically means I don't want to save
>>>>>>>>>> the exception and rethrow it later on (I've seen this in some other
>>>>>>>>>> tests), I rather prefer to make this obvious and not hidden, but of
>>>>>>>>>> course the code gets longer, and everything is complicated by the
>>>>>>>>>> EDT
>>>>>>>>>> invocations.
>>>>>>>>> In your case reflection exception is also test failing.
>>>>>>>>>
>>>>>>>>>> Also, I'm not particularly happy with the use of reflection to
>>>>>>>>>> access
>>>>>>>>>> the filed and check the class name, since we're testing against an
>>>>>>>>>> implementation detail, but I don't know how else I should test that
>>>>>>>>>> we
>>>>>>>>>> create an heavy weight window (which is really also just an
>>>>>>>>>> implementation detail that leaked through the code up to the user,
>>>>>>>>>> nobody should ever care about heavy weight and lightweight imho),
>>>>>>>>>> so
>>>>>>>>>> if you have a smarter idea, I would be happy to change the code.
>>>>>>>>> I'm also trying to avoid reflection in tests but I don't see another
>>>>>>>>> solution here
>>>>>>>>>
>>>>>>>>>> I will try to refactor the code but I would like to not invest
>>>>>>>>>> significant time in that, I'll send you a revised patch later
>>>>>>>>>> (hopefully!)
>>>>>>>>> Yes, and that's the reason to write first version of test without
>>>>>>>>> any
>>>>>>>>> errors. The test shouldn't have errors, because if it fails (on some
>>>>>>>>> platforms with very specific configuration) we have to fix it
>>>>>>>>> (therefore
>>>>>>>>> we
>>>>>>>>> are trying to keep all tests as clear and short as possible)...
>>>>>>>>>
>>>>>>>>> Your test is still have problems. E.g. setVisible invocation doesn't
>>>>>>>>> guarantee that right after method Frame becomes visible (platforms
>>>>>>>>> dependent
>>>>>>>>> behaviour). You can take a look at good test examples in repository,
>>>>>>>>> e.g.
>>>>>>>>> here
>>>>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dfa2ea47257d
>>>>>>>>>
>>>>>>>>> Regards, Pavel
>>>>>>>>>
>>>>>> --
>>>>>> 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 neugens.limasoftware at gmail.com  Wed May 30 16:17:39 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 30 May 2012 18:17:39 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FC62694.1020007@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>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
	<CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>
	<4FC62694.1020007@oracle.com>
Message-ID: <CAGUMyaRPe-Ee8gppyMLwAXRDk=5GJp4wEUr=d4SEFY1Feq1i0Q@mail.gmail.com>

2012/5/30 Pavel Porvatov <pavel.porvatov at oracle.com>:
> Hi Mario,
>
>> Hi Pavel, sure,
>>
>> Should I use the
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806 that I
>> created as CR for the test or the same ?CR 6800513?
>
> What do you mean? Don't change the name of the test and use comment like the
> following:

Seems we have a communication problem :)

> 7171806: Missing test for bug ID 6800513 fix
> Reviewed-by: rupashka

This is what I meant. The patch is in. Note however that the CR
7171806 is not yet public.

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 May 31 09:06:07 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 31 May 2012 13:06:07 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaRPe-Ee8gppyMLwAXRDk=5GJp4wEUr=d4SEFY1Feq1i0Q@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
	<CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>
	<4FC62694.1020007@oracle.com>
	<CAGUMyaRPe-Ee8gppyMLwAXRDk=5GJp4wEUr=d4SEFY1Feq1i0Q@mail.gmail.com>
Message-ID: <4FC7347F.6000009@oracle.com>

Hi Mario,
> 2012/5/30 Pavel Porvatov<pavel.porvatov at oracle.com>:
>> Hi Mario,
>>
>>> Hi Pavel, sure,
>>>
>>> Should I use the
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171806 that I
>>> created as CR for the test or the same  CR 6800513?
>> What do you mean? Don't change the name of the test and use comment like the
>> following:
> Seems we have a communication problem :)
>
>> 7171806: Missing test for bug ID 6800513 fix
>> Reviewed-by: rupashka
> This is what I meant. The patch is in. Note however that the CR
> 7171806 is not yet public.
Great, I marked bug as fixed.

Thanks, Pavel


From neugens.limasoftware at gmail.com  Thu May 31 09:18:15 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 31 May 2012 11:18:15 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FC7347F.6000009@oracle.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F8C1066.2080708@oracle.com>
	<CAGUMyaQF-zf2DGR8sDnyk7NCriYfjq_uFa8SQE6eVQaEtz3wXQ@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
	<CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>
	<4FC62694.1020007@oracle.com>
	<CAGUMyaRPe-Ee8gppyMLwAXRDk=5GJp4wEUr=d4SEFY1Feq1i0Q@mail.gmail.com>
	<4FC7347F.6000009@oracle.com>
Message-ID: <CAGUMyaRoYv9SuP6BpLf0inUtQ0UhgZmJH4DVn-r1Cx_6LTk=JQ@mail.gmail.com>

2012/5/31 Pavel Porvatov <pavel.porvatov at oracle.com>:

> Great, I marked bug as fixed.
>
> Thanks, Pavel

Hi Pavel,

Thanks for the help!

If you could mark the bug as public too, I can link it to our bugzilla too.

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 May 31 09:51:55 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 31 May 2012 13:51:55 +0400
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaRoYv9SuP6BpLf0inUtQ0UhgZmJH4DVn-r1Cx_6LTk=JQ@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
	<CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>
	<4FC62694.1020007@oracle.com>
	<CAGUMyaRPe-Ee8gppyMLwAXRDk=5GJp4wEUr=d4SEFY1Feq1i0Q@mail.gmail.com>
	<4FC7347F.6000009@oracle.com>
	<CAGUMyaRoYv9SuP6BpLf0inUtQ0UhgZmJH4DVn-r1Cx_6LTk=JQ@mail.gmail.com>
Message-ID: <4FC73F3B.1080107@oracle.com>

Hi Mario,
> 2012/5/31 Pavel Porvatov<pavel.porvatov at oracle.com>:
>
>> Great, I marked bug as fixed.
>>
>> Thanks, Pavel
> Hi Pavel,
>
> Thanks for the help!
>
> If you could mark the bug as public too, I can link it to our bugzilla too.
I can't mark the bug as public. Bugs become visible automatically, so 
you'll see the bug after some time...

Regards, Pavel


From neugens.limasoftware at gmail.com  Thu May 31 11:06:57 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 31 May 2012 13:06:57 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <4FC73F3B.1080107@oracle.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<4F8C2A21.5010604@oracle.com>
	<CAGUMyaSeHiT5Hiw63G7QLsHySUvb9K1tk=Vy5pcHhwXNsv7Qkg@mail.gmail.com>
	<4F92D7EA.6090504@oracle.com>
	<CAGUMyaQt0aTaWAsLhFmmTxbUOBKE92jbtTFbSPSpWXRS3DmpgQ@mail.gmail.com>
	<4FA3DCD5.2090005@oracle.com>
	<CAGUMyaS8bcOYXkarBW4-47ED_WvY=dr+MpbAaWCmPt380hBwCg@mail.gmail.com>
	<4FBE111F.4040502@oracle.com>
	<CAGUMyaQAyEGbOkzk50A9xOxAO9ctSRBFP+4n3_nknHnobLp2ng@mail.gmail.com>
	<CAGUMyaQVSH=ywH2G3BL4VYp+_6_-OQiJ+tYjDDthW=UT7cO81Q@mail.gmail.com>
	<4FBF8CE8.8040606@oracle.com>
	<CAGUMyaTiqJOySdoEw4LuFYnmHxO2JRv4Szn0xsx9WFq+pwXSLA@mail.gmail.com>
	<4FC61BE4.70603@oracle.com>
	<CAGUMyaT6bU=YX=oHWNmgKXbhMBfFgY_zpryg-PL+TGktY1vJiA@mail.gmail.com>
	<4FC62694.1020007@oracle.com>
	<CAGUMyaRPe-Ee8gppyMLwAXRDk=5GJp4wEUr=d4SEFY1Feq1i0Q@mail.gmail.com>
	<4FC7347F.6000009@oracle.com>
	<CAGUMyaRoYv9SuP6BpLf0inUtQ0UhgZmJH4DVn-r1Cx_6LTk=JQ@mail.gmail.com>
	<4FC73F3B.1080107@oracle.com>
Message-ID: <CAGUMyaSC5OFTcTzd2CE_pwu9qq6f_TaNNgW107CVL_-nWc_JfA@mail.gmail.com>

Ok... thanks anyway,

Cheers,
Mario

2012/5/31 Pavel Porvatov <pavel.porvatov at oracle.com>:
> Hi Mario,
>
>> 2012/5/31 Pavel Porvatov<pavel.porvatov at oracle.com>:
>>
>>> Great, I marked bug as fixed.
>>>
>>> Thanks, Pavel
>>
>> Hi Pavel,
>>
>> Thanks for the help!
>>
>> If you could mark the bug as public too, I can link it to our bugzilla
>> too.
>
> I can't mark the bug as public. Bugs become visible automatically, so you'll
> see the bug after some time...
>
> Regards, Pavel



-- 
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 Vladislav.Karnaukhov at oracle.com  Thu May 31 11:16:34 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 31 May 2012 15:16:34 +0400
Subject: <Swing Dev> Review request for 6994562 Swing classes (both
 JTextArea and JTextField) don't support caret width tuning
Message-ID: <4FC75312.8070201@oracle.com>

Hello,

please review a fix for the following issue: 6994562 Swing classes (both 
JTextArea and JTextField) don't support caret width tuning

http://monaco.sfbay.sun.com/detail.jsf?cr=6994562

Please find webrev here: 
http://washi.ru.oracle.com/vk220959/webrevs/73745308.Ford.jdk7.2/

This is a forward-port form JDK6. The fix introduces support for Windows 
Accessibility/Ease Of Access to Windows LAF.

Regards,
- Vlad


From Vladislav.Karnaukhov at oracle.com  Thu May 31 11:42:17 2012
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 31 May 2012 15:42:17 +0400
Subject: <Swing Dev> Review request for 6994562 Swing classes (both
 JTextArea and JTextField) don't support caret width tuning
In-Reply-To: <4FC75312.8070201@oracle.com>
References: <4FC75312.8070201@oracle.com>
Message-ID: <4FC75919.4030402@oracle.com>

Please ignore.

- Vlad

On 31.05.12 15:16, Vladislav Karnaukhov wrote:
> Hello,
>
> please review a fix for the following issue: 6994562 Swing classes 
> (both JTextArea and JTextField) don't support caret width tuning
>
> http://monaco.sfbay.sun.com/detail.jsf?cr=6994562
>
> Please find webrev here: 
> http://washi.ru.oracle.com/vk220959/webrevs/73745308.Ford.jdk7.2/
>
> This is a forward-port form JDK6. The fix introduces support for 
> Windows Accessibility/Ease Of Access to Windows LAF.
>
> Regards,
> - Vlad