From sergey.malenkov at sun.com  Thu Jul  2 15:47:52 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 02 Jul 2009 15:47:52 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6380849: RFE: Automatic discovery
	of	PersistanceDelegates
Message-ID: <20090702154817.607B4E90A@hg.openjdk.java.net>

Changeset: bccc4d5e8d6a
Author:    malenkov
Date:      2009-07-02 19:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/bccc4d5e8d6a

6380849: RFE: Automatic discovery of PersistanceDelegates
Reviewed-by: rupashka, alexp

+ src/share/classes/com/sun/beans/finder/BeanInfoFinder.java
+ src/share/classes/com/sun/beans/finder/InstanceFinder.java
+ src/share/classes/com/sun/beans/finder/PersistenceDelegateFinder.java
+ src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java
! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PropertyEditorManager.java
+ test/java/beans/Introspector/6380849/TestBeanInfo.java
+ test/java/beans/Introspector/6380849/beans/FirstBean.java
+ test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java
+ test/java/beans/Introspector/6380849/beans/SecondBean.java
+ test/java/beans/Introspector/6380849/beans/ThirdBean.java
+ test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java
+ test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java
+ test/java/beans/PropertyEditor/6380849/FirstBean.java
+ test/java/beans/PropertyEditor/6380849/FirstBeanEditor.java
+ test/java/beans/PropertyEditor/6380849/SecondBean.java
+ test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java
+ test/java/beans/PropertyEditor/6380849/ThirdBean.java
+ test/java/beans/PropertyEditor/6380849/editors/SecondBeanEditor.java
+ test/java/beans/PropertyEditor/6380849/editors/ThirdBeanEditor.java
+ test/java/beans/XMLEncoder/6380849/Bean.java
+ test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java
+ test/java/beans/XMLEncoder/6380849/TestPersistenceDelegate.java



From sergey.malenkov at sun.com  Fri Jul  3 12:55:04 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Fri, 03 Jul 2009 12:55:04 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6329581: RFE: LTP:
	java.beans.XMLEncoder does not	manage ClassLoader.
Message-ID: <20090703125541.8F6F6EA79@hg.openjdk.java.net>

Changeset: 7720d6c079ca
Author:    malenkov
Date:      2009-07-03 16:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/7720d6c079ca

6329581: RFE: LTP: java.beans.XMLEncoder does not manage ClassLoader.
Reviewed-by: rupashka, alexp

! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/Statement.java
+ test/java/beans/XMLEncoder/6329581/Test6329581.java



From sergey.malenkov at sun.com  Mon Jul  6 10:31:03 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Mon, 06 Jul 2009 10:31:03 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6723447: Introspector doesn't check
	return type	for indexed property setters
Message-ID: <20090706103136.723A0EBDC@hg.openjdk.java.net>

Changeset: ef20a15b3569
Author:    malenkov
Date:      2009-07-06 14:32 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ef20a15b3569

6723447: Introspector doesn't check return type for indexed property setters
Reviewed-by: rupashka

! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/Test6723447.java



From langel at redhat.com  Mon Jul  6 15:47:28 2009
From: langel at redhat.com (Lillian Angel)
Date: Mon, 06 Jul 2009 11:47:28 -0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A423DF0.8050401@redhat.com>
References: <4A37BE1F.4030300@redhat.com>	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>	<4A3BE58F.70608@redhat.com>
	<4A423DF0.8050401@redhat.com>
Message-ID: <4A521C90.6030806@redhat.com>

Lillian Angel wrote:
> Lillian Angel wrote:
>> Andrew John Hughes wrote:
>>> 2009/6/16 Lillian Angel <langel at redhat.com>:
>>>  
>>>> Hi,
>>>>
>>>> I posted a bug report, including a testcase and webrev here for 
>>>> review:
>>>>
>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100073
>>>>
>>>>
>>>> Cheers,
>>>> Lillian
>>>>
>>>>     
>>>
>>>
>>> I can confirm we still apply this fix to OpenJDK7 too, so it's needed
>>> for both repos.
>>>
>>> Any comments? Can we push this fix?
>>
>>
>>
>> Ping...
>>
>>
>
>
> Can someone please review this? 

I have updated the patch, can someone please review it again?

Cheers
Lillian



From pavel.porvatov at sun.com  Tue Jul  7 10:22:16 2009
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Tue, 07 Jul 2009 10:22:16 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6489447: Apply the more robust fix
	for 6449933 to	dolphin and 6ux
Message-ID: <20090707102240.34FF7EC93@hg.openjdk.java.net>

Changeset: 0407df5a768e
Author:    rupashka
Date:      2009-07-07 14:11 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0407df5a768e

6489447: Apply the more robust fix for 6449933 to dolphin and 6ux
Reviewed-by: malenkov

! src/windows/native/sun/windows/ShellFolder2.cpp



From Anthony.Petrov at Sun.COM  Wed Jul  8 14:20:57 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 08 Jul 2009 18:20:57 +0400
Subject: <Swing Dev> <AWT Dev> Lw/Hw mixing vs
	revalidate()/validate()/invalidate()
In-Reply-To: <4f9903f0906200652w1cb1111bvd11121a3f0fad10c@mail.gmail.com>
References: <4f9903f0906200652w1cb1111bvd11121a3f0fad10c@mail.gmail.com>
Message-ID: <4A54AB49.5050408@sun.com>

Just to revive the discussion...

On 06/20/2009 05:52 PM, Christopher Deckers wrote:
> 2. Make it so that revalidate does not mark the ancestors of the
> validate root invalid. I wonder if this is a sensible approach though.
I guess you mean an overridden JComponent.invalidate() here, since 
revalidate() calls this method to invalidate the component hierarchy.

As we understand from the previous discussions, the root problem is 
indeed the AWT's invalidate() method that goes too far doing its job. 
Since Swing introduces the concept of "validate root", it seems really 
natural to me to override the JComponent.invalidate() method 
accordingly. At least I can't imagine a problem caused by choosing this way.

What do Swing people think about that?

--
best regards,
Anthony


From langel at redhat.com  Fri Jul 10 14:06:44 2009
From: langel at redhat.com (Lillian Angel)
Date: Fri, 10 Jul 2009 10:06:44 -0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A521C90.6030806@redhat.com>
References: <4A37BE1F.4030300@redhat.com>	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>	<4A3BE58F.70608@redhat.com>	<4A423DF0.8050401@redhat.com>
	<4A521C90.6030806@redhat.com>
Message-ID: <4A574AF4.2020207@redhat.com>

Lillian Angel wrote:
> Lillian Angel wrote:
>> Lillian Angel wrote:
>>> Andrew John Hughes wrote:
>>>> 2009/6/16 Lillian Angel <langel at redhat.com>:
>>>>  
>>>>> Hi,
>>>>>
>>>>> I posted a bug report, including a testcase and webrev here for 
>>>>> review:
>>>>>
>>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100073
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Lillian
>>>>>
>>>>>     
>>>>
>>>>
>>>> I can confirm we still apply this fix to OpenJDK7 too, so it's needed
>>>> for both repos.
>>>>
>>>> Any comments? Can we push this fix?
>>>
>>>
>>>
>>> Ping...
>>>
>>>
>>
>>
>> Can someone please review this? 
>
> I have updated the patch, can someone please review it again? 


Ping!


From gnu_andrew at member.fsf.org  Fri Jul 10 14:11:16 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 10 Jul 2009 15:11:16 +0100
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A574AF4.2020207@redhat.com>
References: <4A37BE1F.4030300@redhat.com>
	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>
	<4A3BE58F.70608@redhat.com> <4A423DF0.8050401@redhat.com>
	<4A521C90.6030806@redhat.com> <4A574AF4.2020207@redhat.com>
Message-ID: <17c6771e0907100711k11b59360y7e2aab8f3f9c1b00@mail.gmail.com>

2009/7/10 Lillian Angel <langel at redhat.com>:
> Lillian Angel wrote:
>>
>> Lillian Angel wrote:
>>>
>>> Lillian Angel wrote:
>>>>
>>>> Andrew John Hughes wrote:
>>>>>
>>>>> 2009/6/16 Lillian Angel <langel at redhat.com>:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I posted a bug report, including a testcase and webrev here for
>>>>>> review:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100073
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Lillian
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> I can confirm we still apply this fix to OpenJDK7 too, so it's needed
>>>>> for both repos.
>>>>>
>>>>> Any comments? Can we push this fix?
>>>>
>>>>
>>>>
>>>> Ping...
>>>>
>>>>
>>>
>>>
>>> Can someone please review this?
>>
>> I have updated the patch, can someone please review it again?
>
>
> Ping!
>

Ping!

Can someone please review the new version?

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Sergey.Groznyh at Sun.COM  Fri Jul 10 14:13:32 2009
From: Sergey.Groznyh at Sun.COM (Sergey Groznyh)
Date: Fri, 10 Jul 2009 18:13:32 +0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A574AF4.2020207@redhat.com>
References: <4A37BE1F.4030300@redhat.com>
	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>
	<4A3BE58F.70608@redhat.com> <4A423DF0.8050401@redhat.com>
	<4A521C90.6030806@redhat.com> <4A574AF4.2020207@redhat.com>
Message-ID: <4A574C8C.3010703@Sun.COM>

>>>>> Lillian Angel wrote:

>>> Can someone please review this? 
>>
>> I have updated the patch, can someone please review it again? 

Sorry Lillian, I was on vacation. Will get to your fix soon.

Thanks,
Sergey


From langel at redhat.com  Fri Jul 10 14:15:35 2009
From: langel at redhat.com (Lillian Angel)
Date: Fri, 10 Jul 2009 10:15:35 -0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A574C8C.3010703@Sun.COM>
References: <4A37BE1F.4030300@redhat.com>
	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>
	<4A3BE58F.70608@redhat.com> <4A423DF0.8050401@redhat.com>
	<4A521C90.6030806@redhat.com> <4A574AF4.2020207@redhat.com>
	<4A574C8C.3010703@Sun.COM>
Message-ID: <4A574D07.50606@redhat.com>

Sergey Groznyh wrote:
>>>>>> Lillian Angel wrote:
>>>>>>             
>
>   
>>>> Can someone please review this? 
>>>>         
>>> I have updated the patch, can someone please review it again? 
>>>       
>
> Sorry Lillian, I was on vacation. Will get to your fix soon.


No problem :) Thanks


From yuri.nesterenko at sun.com  Sun Jul 12 15:09:53 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 15:09:53 +0000
Subject: <Swing Dev> hg: jdk7/swing: 12 new changesets
Message-ID: <20090712150953.A7716EEBD@hg.openjdk.java.net>

Changeset: 57f7e028c7ad
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/57f7e028c7ad

Added tag jdk7-b62 for changeset c7ed15ab92ce

! .hgtags

Changeset: 9849536536d2
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/9849536536d2

Added tag jdk7-b63 for changeset 57f7e028c7ad

! .hgtags

Changeset: c50469cf63cd
Author:    herrick
Date:      2009-06-11 15:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/c50469cf63cd

6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7
6845973: Update JDK7 with deployment changes in 6u13, 6u14
4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64
6825019: DownloadManager should not be loaded and referenced for full JRE
6738770: REGRESSION:JSException throws when use LiveConnect javascript facility
6772884: plugin2 : java.lang.OutOfMemoryError or crash
6707535: Crossing domain hole affecting multiple sites/domains using plug-in
6728071: Non-verification of Update files may allow unintended updates
6704154: Code loaded from local filesystem should not get access to localhost
6727081: Web Start security restrictions bypass using special extension jnlp
6727079: Java Web Start Socket() restriction bypass
6727071: Cache location/user name information disclosure in SingleInstanceImpl.
6716217: AppletClassLoader adds permissions based on codebase regardless of CS
6694892: Java Webstart inclusion via system properties override [CVE-2008-2086]
6704074: localhost socket access due to cache location exposed
6703909: Java webstart arbitrary file creation using nativelib
6665315: browser crashes when deployment.properties has more slashes ( / )
6660121: Encoding values in JNLP files can cause buffer overflow
6606110: URLConnection.setProxiedHost for resources that are loaded via proxy
6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install
6609756: Buffer Overflow in Java ActiveX component
6608712: Bypassing the same origin policy in Java with crafted names
6534630: "gnumake clobber" doesn't
6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build
6849029: Need some JDK7 merge clean-up after comments on the webrev
6847582: Build problem on JDK7 with isSecureProperty in merge
6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk
6823215: latest merge fixes from 6u12 -> JDK7
6816153: further mergers for JDK7 deployment integration
6807074: Fix Java Kernel and JQS in initial JDK7 builds
Summary: Initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/deploy-rules.gmk

Changeset: c7c4850f1478
Author:    herrick
Date:      2009-06-15 13:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/c7c4850f1478

Merge


Changeset: d28a8c422df1
Author:    herrick
Date:      2009-06-22 09:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/d28a8c422df1

Merge


Changeset: 528e4cc7541b
Author:    herrick
Date:      2009-06-29 12:00 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/528e4cc7541b

Merge


Changeset: 9f4fc871bf4d
Author:    herrick
Date:      2009-07-06 15:02 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/9f4fc871bf4d

Merge


Changeset: 03119516abbc
Author:    herrick
Date:      2009-07-06 14:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/03119516abbc

Merge


Changeset: 633840bd4c5b
Author:    jqzuo
Date:      2009-07-07 10:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/633840bd4c5b

Merge


Changeset: 46c0f8989eb2
Author:    herrick
Date:      2009-07-06 17:12 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/46c0f8989eb2

Merge


Changeset: 3e781aa606d4
Author:    ohair
Date:      2009-07-06 22:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/3e781aa606d4

6857805: Fix openjdk builds to avoid building deploy repository
Reviewed-by: xdono

! make/Defs-internal.gmk
! make/deploy-rules.gmk

Changeset: 269c1ec4435d
Author:    jqzuo
Date:      2009-07-07 10:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/269c1ec4435d

Merge




From yuri.nesterenko at sun.com  Sun Jul 12 15:16:12 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 15:16:12 +0000
Subject: <Swing Dev> hg: jdk7/swing/corba: 9 new changesets
Message-ID: <20090712151620.3E473EEC6@hg.openjdk.java.net>

Changeset: d20e45cd539f
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/d20e45cd539f

Added tag jdk7-b62 for changeset 65b66117dbd7

! .hgtags

Changeset: b3ad991d9534
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/b3ad991d9534

Added tag jdk7-b63 for changeset d20e45cd539f

! .hgtags

Changeset: ffb590b42ed1
Author:    herrick
Date:      2009-06-11 15:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/ffb590b42ed1

6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7
6845973: Update JDK7 with deployment changes in 6u13, 6u14
4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64
6825019: DownloadManager should not be loaded and referenced for full JRE
6738770: REGRESSION:JSException throws when use LiveConnect javascript facility
6772884: plugin2 : java.lang.OutOfMemoryError or crash
6707535: Crossing domain hole affecting multiple sites/domains using plug-in
6728071: Non-verification of Update files may allow unintended updates
6704154: Code loaded from local filesystem should not get access to localhost
6727081: Web Start security restrictions bypass using special extension jnlp
6727079: Java Web Start Socket() restriction bypass
6727071: Cache location/user name information disclosure in SingleInstanceImpl.
6716217: AppletClassLoader adds permissions based on codebase regardless of CS
6694892: Java Webstart inclusion via system properties override [CVE-2008-2086]
6704074: localhost socket access due to cache location exposed
6703909: Java webstart arbitrary file creation using nativelib
6665315: browser crashes when deployment.properties has more slashes ( / )
6660121: Encoding values in JNLP files can cause buffer overflow
6606110: URLConnection.setProxiedHost for resources that are loaded via proxy
6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install
6609756: Buffer Overflow in Java ActiveX component
6608712: Bypassing the same origin policy in Java with crafted names
6534630: "gnumake clobber" doesn't
6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build
6849029: Need some JDK7 merge clean-up after comments on the webrev
6847582: Build problem on JDK7 with isSecureProperty in merge
6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk
6823215: latest merge fixes from 6u12 -> JDK7
6816153: further mergers for JDK7 deployment integration
6807074: Fix Java Kernel and JQS in initial JDK7 builds
Summary: Initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/org/omg/idl/Makefile
! src/windows/resource/version.rc

Changeset: 79d8fd9e74b9
Author:    herrick
Date:      2009-06-15 13:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/79d8fd9e74b9

Merge

- make/README

Changeset: 1b3e9fdc4fc5
Author:    herrick
Date:      2009-06-22 09:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/1b3e9fdc4fc5

Merge


Changeset: 27f41fcf3d6a
Author:    herrick
Date:      2009-06-29 12:00 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/27f41fcf3d6a

Merge


Changeset: f982791bb7d4
Author:    herrick
Date:      2009-07-06 15:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/f982791bb7d4

Merge


Changeset: 863559dbbced
Author:    herrick
Date:      2009-07-06 14:02 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/863559dbbced

Merge


Changeset: 047dd27fddb6
Author:    herrick
Date:      2009-07-06 17:11 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/047dd27fddb6

Merge




From yuri.nesterenko at sun.com  Sun Jul 12 15:28:19 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 15:28:19 +0000
Subject: <Swing Dev> hg: jdk7/swing/hotspot: 11 new changesets
Message-ID: <20090712152842.C848FEECB@hg.openjdk.java.net>

Changeset: 8754a3c37762
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/8754a3c37762

Added tag jdk7-b62 for changeset a88386380bda

! .hgtags

Changeset: 821269eca479
Author:    ysr
Date:      2009-06-11 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/821269eca479

6820167: GCALotAtAllSafepoints + FullGCALot(ScavengeALot) options crash JVM
Summary: Short-circuit gc-a-lot attempts by non-JavaThreads; SkipGCALot c'tor to elide re-entrant gc-a-lot attempts.
Reviewed-by: apetrusenko, jcoomes, jmasa, kamg

! src/share/vm/memory/gcLocker.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmThread.cpp

Changeset: d44bdab1c03d
Author:    johnc
Date:      2009-06-11 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/d44bdab1c03d

6843694: G1: assert(index < _vs.committed_size(),"bad index"), g1BlockOffsetTable.inline.hpp:55
Summary: For heaps larger than 32Gb, the number of heap regions overflows the data type used to hold the region index in the SparsePRT structure. Changed the region indexes, card indexes, and RSet hash table buckets to ints and added some size overflow guarantees.
Reviewed-by: ysr, tonyp

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 353ba4575581
Author:    jcoomes
Date:      2009-06-07 22:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/353ba4575581

6814552: par compact - some compilers fail to optimize bitmap code
Reviewed-by: tonyp, iveresov, jmasa, ysr

! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp

Changeset: 6e2afda171db
Author:    jcoomes
Date:      2009-06-11 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/6e2afda171db

6849716: BitMap - performance regression introduced with G1
Summary: make verification code visible only in debug builds
Reviewed-by: iveresov, ysr, johnc, apetrusenko, tonyp

! src/share/vm/includeDB_compiler1
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/bitMap.inline.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 3104f76478ee
Author:    jmasa
Date:      2009-06-18 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/3104f76478ee

Merge


Changeset: 830ca2573896
Author:    tonyp
Date:      2009-06-12 16:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/830ca2573896

6850846: G1: extend G1 marking verification
Summary: extend G1 marking verification to use either the "prev" or "next" marking information, as appropriate.
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp

Changeset: 85d0690f7d12
Author:    jmasa
Date:      2009-06-19 07:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/85d0690f7d12

Merge


Changeset: f9c95d5dc41f
Author:    trims
Date:      2009-06-25 22:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/f9c95d5dc41f

Merge


Changeset: 32c83fb84370
Author:    trims
Date:      2009-06-30 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/32c83fb84370

6856257: Bump the HS16 build number to 05
Summary: Update the HS16 build number to 05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ba36394eb84b
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/ba36394eb84b

Added tag jdk7-b63 for changeset 32c83fb84370

! .hgtags



From yuri.nesterenko at sun.com  Sun Jul 12 16:16:07 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 16:16:07 +0000
Subject: <Swing Dev> hg: jdk7/swing/jaxp: 2 new changesets
Message-ID: <20090712161611.3428CEED0@hg.openjdk.java.net>

Changeset: ae449e9c04c1
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/ae449e9c04c1

Added tag jdk7-b62 for changeset a97dd57a6260

! .hgtags

Changeset: a10eec7a1edf
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/a10eec7a1edf

Added tag jdk7-b63 for changeset ae449e9c04c1

! .hgtags



From yuri.nesterenko at sun.com  Sun Jul 12 16:22:29 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 16:22:29 +0000
Subject: <Swing Dev> hg: jdk7/swing/jaxws: 2 new changesets
Message-ID: <20090712162233.AB15CEED5@hg.openjdk.java.net>

Changeset: b8a6e883c0a6
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/b8a6e883c0a6

Added tag jdk7-b62 for changeset 75c801c13ea1

! .hgtags

Changeset: aaa25dfd3de6
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/aaa25dfd3de6

Added tag jdk7-b63 for changeset b8a6e883c0a6

! .hgtags



From yuri.nesterenko at sun.com  Sun Jul 12 16:31:47 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 16:31:47 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 78 new changesets
Message-ID: <20090712165030.570D3EEDA@hg.openjdk.java.net>

Changeset: 8905d218cd0d
Author:    xdono
Date:      2009-06-25 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/8905d218cd0d

Added tag jdk7-b62 for changeset 12e11fab9a83

! .hgtags

Changeset: 9cf4ef04d9a7
Author:    prr
Date:      2009-05-06 14:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9cf4ef04d9a7

6806822: Font.getFontName() is slow in Java5 and 6
Reviewed-by: igor, jgodinez

! src/share/classes/sun/font/TrueTypeFont.java

Changeset: ec0a8acd4737
Author:    jgodinez
Date:      2009-05-14 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ec0a8acd4737

Merge


Changeset: fb03586d68b6
Author:    jgodinez
Date:      2009-05-21 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fb03586d68b6

6829659: Circle is rendered in C shape
Reviewed-by: campbell, flar
Contributed-by: Google <yamauchi at google.com>

! src/share/classes/sun/java2d/pisces/PiscesCache.java
+ test/sun/pisces/ScaleTest.java

Changeset: 907324eb3e64
Author:    bae
Date:      2009-05-23 08:35 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/907324eb3e64

4893408: JPEGReader throws IllegalArgException when setting the destination to BYTE_GRAY
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
+ test/javax/imageio/plugins/jpeg/ReadAsGrayTest.java

Changeset: b92e3fbbcb63
Author:    jgodinez
Date:      2009-06-08 13:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b92e3fbbcb63

Merge


Changeset: 378feb59435b
Author:    bae
Date:      2009-06-11 13:47 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/378feb59435b

6296893: BMP Writer handles TopDown property incorrectly for some of the compression types
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
+ test/javax/imageio/plugins/bmp/TopDownTest.java

Changeset: e138ae33b128
Author:    bae
Date:      2009-06-11 14:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e138ae33b128

5101862: WBMP Image reader tries to load Quicktime MOV files
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java
+ test/javax/imageio/plugins/wbmp/CanDecodeTest.java

Changeset: 0ce29cbeb6a9
Author:    bae
Date:      2009-06-15 14:49 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0ce29cbeb6a9

6829549: JVM crash on certain images
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java

Changeset: 5896dcd01fe3
Author:    bae
Date:      2009-06-15 17:19 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5896dcd01fe3

6684104: Applets fails to launch using ImageIO if .java.policy with File permissions present on the system
Reviewed-by: igor, prr

! src/share/classes/javax/imageio/ImageIO.java
+ test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java
+ test/javax/imageio/CachePremissionsTest/rw.policy
+ test/javax/imageio/CachePremissionsTest/rwd.policy
+ test/javax/imageio/CachePremissionsTest/w.policy

Changeset: 956715ded919
Author:    jgodinez
Date:      2009-06-15 09:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/956715ded919

Merge


Changeset: 70903e2c39e3
Author:    jgodinez
Date:      2009-06-22 09:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/70903e2c39e3

6850398: Allow GraphicsEnvironment to be loaded by system classloader  (edit)
Reviewed-by: campbell, prr

! src/share/classes/java/awt/GraphicsEnvironment.java

Changeset: fafa991c27ac
Author:    prr
Date:      2009-06-22 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fafa991c27ac

6853617: race condition in java.awt.Font.getAttributes() (private method)
Reviewed-by: igor, jgodinez

! src/share/classes/java/awt/Font.java

Changeset: 2886eb650801
Author:    jgodinez
Date:      2009-06-24 11:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2886eb650801

Merge

- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 2ed6ed6b5bfc
Author:    jgodinez
Date:      2009-06-29 14:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2ed6ed6b5bfc

Merge


Changeset: 120df7f49509
Author:    xdono
Date:      2009-07-02 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/120df7f49509

Added tag jdk7-b63 for changeset 2ed6ed6b5bfc

! .hgtags

Changeset: 1299804aa6e7
Author:    xuelei
Date:      2009-06-16 20:46 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1299804aa6e7

6850783: InvalidityDateExtension returns reference to internal mutable state
Summary: return cloned instead of referenced object
Reviewed-by: weijun

! src/share/classes/sun/security/x509/CertificateVersion.java
! src/share/classes/sun/security/x509/InvalidityDateExtension.java

Changeset: bc2c9dbdcc70
Author:    weijun
Date:      2009-06-17 15:26 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/bc2c9dbdcc70

6849275: enhance krb5 reg tests
Reviewed-by: xuelei

! test/sun/security/krb5/auto/CrossRealm.java
! test/sun/security/krb5/auto/HttpNegotiateServer.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
! test/sun/security/krb5/auto/OneKDC.java
! test/sun/security/krb5/auto/basic.sh

Changeset: 863351d5d244
Author:    weijun
Date:      2009-06-18 11:12 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/863351d5d244

6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13
Reviewed-by: mullan

! src/share/classes/sun/security/tools/JarSigner.java
+ test/sun/security/tools/jarsigner/emptymanifest.sh

Changeset: e387bb1367a7
Author:    mullan
Date:      2009-06-18 09:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e387bb1367a7

6833839: RFE: improve ManifestDigester by instantiating StringBuilder constructor w/ initial value
Reviewed-by: weijun

! src/share/classes/sun/security/util/ManifestDigester.java

Changeset: 81c176909720
Author:    mullan
Date:      2009-06-18 10:38 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/81c176909720

Merge


Changeset: 37ed72fe7561
Author:    weijun
Date:      2009-06-19 18:03 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/37ed72fe7561

6851973: ignore incoming channel binding if acceptor does not set one
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/krb5/InitialToken.java
+ test/sun/security/krb5/auto/IgnoreChannelBinding.java

Changeset: ed38f9e6ad9a
Author:    jccollet
Date:      2009-06-19 14:12 +0200
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ed38f9e6ad9a

6852108: Remove Preferences dependance from SocksSocketImpl
Summary: Removed Preferences API use and fixed a few findbugs gotchas
Reviewed-by: alanb

! src/share/classes/java/net/SocksSocketImpl.java

Changeset: 77367060d119
Author:    sherman
Date:      2009-06-19 14:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/77367060d119

6299219: euro sign failed to be printed in Console on Localized Windows platform with GBK encoding
4891024: EUC-KR and JOHAB converters need to be updated to include two new characters
4287467: Character converter generator tool
Summary: Migrated some of the doublebyte charsets to the new implementation.
Reviewed-by: okutsu

! make/sun/nio/FILES_java.gmk
! make/sun/nio/Makefile
+ make/tools/CharsetMapping/EUC_CN.map
+ make/tools/CharsetMapping/EUC_KR.map
+ make/tools/CharsetMapping/GBK.map
+ make/tools/CharsetMapping/Johab.map
+ make/tools/CharsetMapping/MS932.c2b
+ make/tools/CharsetMapping/MS932.map
+ make/tools/CharsetMapping/MS932.nr
+ make/tools/CharsetMapping/MS936.map
+ make/tools/CharsetMapping/MS949.map
+ make/tools/CharsetMapping/MS950.map
+ make/tools/CharsetMapping/MS950.nr
! make/tools/CharsetMapping/dbcs
! make/tools/src/build/tools/charsetmapping/GenerateDBCS.java
! src/share/classes/sun/io/ByteToCharEUC_CN.java
! src/share/classes/sun/io/ByteToCharEUC_KR.java
! src/share/classes/sun/io/ByteToCharGBK.java
! src/share/classes/sun/io/ByteToCharJohab.java
! src/share/classes/sun/io/ByteToCharMS932.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
! src/share/classes/sun/io/ByteToCharMS936.java
! src/share/classes/sun/io/ByteToCharMS949.java
! src/share/classes/sun/io/ByteToCharMS950.java
! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java
! src/share/classes/sun/io/CharToByteEUC_CN.java
! src/share/classes/sun/io/CharToByteEUC_KR.java
! src/share/classes/sun/io/CharToByteGBK.java
! src/share/classes/sun/io/CharToByteJohab.java
! src/share/classes/sun/io/CharToByteMS932.java
- src/share/classes/sun/io/CharToByteMS932DB.java
! src/share/classes/sun/io/CharToByteMS936.java
! src/share/classes/sun/io/CharToByteMS949.java
! src/share/classes/sun/io/CharToByteMS950.java
! src/share/classes/sun/io/CharToByteMS950_HKSCS.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
! src/share/classes/sun/nio/cs/ext/MS932_0213.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java
! src/solaris/classes/sun/awt/motif/X11GB2312.java
! src/solaris/classes/sun/awt/motif/X11GBK.java
! src/solaris/classes/sun/awt/motif/X11KSC5601.java
+ test/sun/nio/cs/OLD/DoubleByteDecoder.java
+ test/sun/nio/cs/OLD/DoubleByteEncoder.java
+ test/sun/nio/cs/OLD/EUC_CN_OLD.java
+ test/sun/nio/cs/OLD/EUC_KR_OLD.java
+ test/sun/nio/cs/OLD/GBK_OLD.java
+ test/sun/nio/cs/OLD/Johab_OLD.java
+ test/sun/nio/cs/OLD/MS932DB.java
+ test/sun/nio/cs/OLD/MS932_OLD.java
+ test/sun/nio/cs/OLD/MS936_OLD.java
+ test/sun/nio/cs/OLD/MS949_OLD.java
+ test/sun/nio/cs/OLD/MS950_OLD.java
! test/sun/nio/cs/OLD/TestIBMDB.java
+ test/sun/nio/cs/OLD/TestX11CS.java
+ test/sun/nio/cs/OLD/X11GB2312_OLD.java
+ test/sun/nio/cs/OLD/X11GBK_OLD.java
+ test/sun/nio/cs/OLD/X11KSC5601_OLD.java

Changeset: 28d4c9f5c9e9
Author:    xlu
Date:      2009-06-20 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/28d4c9f5c9e9

6850606: Regression from JDK 1.6.0_12
Summary: The returned result from multiply should be constructed by using valueOf to take care of the INFLATED case.
Reviewed-by: darcy

! src/share/classes/java/math/BigDecimal.java
! test/java/math/BigDecimal/MultiplyTests.java

Changeset: b0b249933c37
Author:    martin
Date:      2009-06-22 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b0b249933c37

6851653: (launcher) Make every java process 20 bytes smaller
Summary: Carefully keep track of every byte
Reviewed-by: ksrini, xlu

! src/share/bin/java.c

Changeset: 7704895771b5
Author:    sherman
Date:      2009-06-22 19:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/7704895771b5

6847092: (cs) CharsetEncoder.isLegalReplacement of US_ASCII behaves differently since
Summary: Updated the US_ASCII and ISO-8859-1 to fix the failure.
Reviewed-by: alanb, martin

! src/share/classes/sun/nio/cs/ISO_8859_1.java
! src/share/classes/sun/nio/cs/US_ASCII.java
+ test/sun/nio/cs/FindASCIIReplBugs.java

Changeset: ce55eb6668d9
Author:    martin
Date:      2009-06-22 20:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ce55eb6668d9

6834805: Improve jar -C performance
Summary: Store "-C" directories in a HashSet, not List, to remove duplicates
Reviewed-by: sherman
Contributed-by: jeremymanson at google.com

! src/share/classes/sun/tools/jar/Main.java

Changeset: ff32c270102a
Author:    martin
Date:      2009-06-22 21:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ff32c270102a

6853806: Prefer (cd $dir && jar) to jar -C for performance reasons
Summary: Eliminate (most) uses of jar -C
Reviewed-by: ohair

! make/common/Release.gmk

Changeset: b3444a42fd40
Author:    tbell
Date:      2009-06-23 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b3444a42fd40

Merge

- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java

Changeset: 70c0a927e21a
Author:    jccollet
Date:      2009-06-25 18:56 +0200
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/70c0a927e21a

6811297: Add more logging to HTTP protocol handler
Summary: Added extra logging to HttpURLConnection and HttpClient. Added a capture tool.
Reviewed-by: chegar

! make/sun/net/FILES_java.gmk
+ src/share/classes/sun/net/www/http/HttpCapture.java
+ src/share/classes/sun/net/www/http/HttpCaptureInputStream.java
+ src/share/classes/sun/net/www/http/HttpCaptureOutputStream.java
! src/share/classes/sun/net/www/http/HttpClient.java
+ src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 5a3a5388756c
Author:    langel
Date:      2009-06-25 17:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5a3a5388756c

6852607: MessageUtils JVM crash
Summary: Fixes crash by checking null field
Reviewed-by: alanb

! src/share/native/sun/misc/MessageUtils.c

Changeset: 0b6571d4b4b5
Author:    jccollet
Date:      2009-06-26 16:50 +0200
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0b6571d4b4b5

6855297: Windows build breaks after 6811297
Summary: re-introduced the mistakenly taken out authObj member
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 9f243df213fa
Author:    tbell
Date:      2009-06-26 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9f243df213fa

Merge

- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java

Changeset: a5f7d97c3f82
Author:    jjg
Date:      2009-06-26 18:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/a5f7d97c3f82

6843077: JSR 308: Annotations on types
Reviewed-by: jjg, mcimadamore, darcy
Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu

! src/share/classes/java/lang/annotation/ElementType.java

Changeset: bd4f0613dd92
Author:    tbell
Date:      2009-06-28 00:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/bd4f0613dd92

Merge


Changeset: 5208d0c90d73
Author:    alanb
Date:      2009-06-27 21:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5208d0c90d73

6838333: New I/O: Update file system API to jsr203/nio2-b101
6844313: New I/O: File timestamps should be represented by a FileTime rather than a long+TimeUnit
Reviewed-by: sherman

! make/java/java/FILES_java.gmk
! make/java/nio/FILES_java.gmk
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/share/classes/java/io/File.java
+ src/share/classes/java/io/TempFileHelper.java
! src/share/classes/java/nio/channels/SeekableByteChannel.java
! src/share/classes/java/nio/file/AccessMode.java
! src/share/classes/java/nio/file/DirectoryStream.java
- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
! src/share/classes/java/nio/file/FileRef.java
! src/share/classes/java/nio/file/FileStore.java
! src/share/classes/java/nio/file/FileTreeWalker.java
! src/share/classes/java/nio/file/FileVisitor.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/LinkPermission.java
! src/share/classes/java/nio/file/OpenOption.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/Paths.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/nio/file/SimpleFileVisitor.java
! src/share/classes/java/nio/file/StandardWatchEventKind.java
! src/share/classes/java/nio/file/WatchKey.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/AttributeView.java
! src/share/classes/java/nio/file/attribute/Attributes.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java
! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java
! src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java
+ src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java
! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java
! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java
! src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
! src/share/classes/java/nio/file/spi/FileSystemProvider.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java
! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java
+ src/share/classes/sun/nio/fs/AbstractPath.java
! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java
+ src/share/classes/sun/nio/fs/DynamicFileAttributeView.java
! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java
- src/share/classes/sun/nio/fs/MimeType.java
! src/share/classes/sun/nio/fs/PollingWatchService.java
+ src/share/classes/sun/nio/fs/Util.java
! src/share/sample/nio/file/Copy.java
! src/share/sample/nio/file/Xdd.java
! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java
! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisFileStore.java
! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixCopyFile.java
! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java
! src/solaris/classes/sun/nio/fs/UnixFileKey.java
! src/solaris/classes/sun/nio/fs/UnixFileModeAttribute.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixMountEntry.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java
! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
! src/solaris/native/sun/nio/fs/genUnixConstants.c
! src/windows/classes/sun/nio/fs/WindowsConstants.java
! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java
! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java
! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java
! src/windows/classes/sun/nio/fs/WindowsFileStore.java
! src/windows/classes/sun/nio/fs/WindowsFileSystem.java
! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/classes/sun/nio/fs/WindowsPath.java
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c
! test/java/nio/file/DirectoryStream/Basic.java
- test/java/nio/file/DirectoryStream/Filters.java
! test/java/nio/file/DirectoryStream/SecureDS.java
! test/java/nio/file/FileSystem/Basic.java
! test/java/nio/file/Files/ContentType.java
! test/java/nio/file/Files/Misc.java
- test/java/nio/file/Files/content_type.sh
! test/java/nio/file/Path/CopyAndMove.java
+ test/java/nio/file/Path/FileAttributes.java
! test/java/nio/file/Path/Links.java
! test/java/nio/file/Path/Misc.java
! test/java/nio/file/Path/PathOps.java
! test/java/nio/file/Path/TemporaryFiles.java
- test/java/nio/file/Path/temporary_files.sh
! test/java/nio/file/TestUtil.java
! test/java/nio/file/WatchService/Basic.java
! test/java/nio/file/WatchService/FileTreeModifier.java
! test/java/nio/file/attribute/AclFileAttributeView/Basic.java
- test/java/nio/file/attribute/Attributes/Basic.java
! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java
! test/java/nio/file/attribute/DosFileAttributeView/Basic.java
! test/java/nio/file/attribute/FileStoreAttributeView/Basic.java
+ test/java/nio/file/attribute/FileTime/Basic.java
! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java
! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

Changeset: 77dd50ba670b
Author:    alanb
Date:      2009-06-27 21:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/77dd50ba670b

6844054: (bf) Eliminate dependency on javax.management.ObjectName
Reviewed-by: mchung

! src/share/classes/java/lang/management/PlatformComponent.java
! src/share/classes/java/nio/Bits.java
! src/share/classes/java/nio/Direct-X-Buffer.java
! src/share/classes/sun/management/ManagementFactoryHelper.java
! src/share/classes/sun/misc/JavaNioAccess.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java

Changeset: dd20c662d463
Author:    ohair
Date:      2009-06-26 21:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/dd20c662d463

6855180: Fix classfile version check in java_crw_demo
Reviewed-by: jjg

! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/share/javavm/export/classfile_constants.h

Changeset: cbb5964d97ef
Author:    ohair
Date:      2009-06-28 11:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/cbb5964d97ef

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: 35b19adcb215
Author:    tbell
Date:      2009-06-28 23:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/35b19adcb215

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: 806c5e4d1265
Author:    michaelm
Date:      2009-06-29 13:10 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/806c5e4d1265

6513803: httpserver regression test Test13 failing and causing NullPointerException
Summary: check for NPEs
Reviewed-by: chegar

! test/com/sun/net/httpserver/Test1.java
! test/com/sun/net/httpserver/Test12.java
! test/com/sun/net/httpserver/Test13.java
! test/com/sun/net/httpserver/Test3.java
! test/com/sun/net/httpserver/Test4.java
! test/com/sun/net/httpserver/Test5.java
! test/com/sun/net/httpserver/Test9.java
! test/com/sun/net/httpserver/Test9a.java
! test/com/sun/net/httpserver/TestLogging.java

Changeset: b6721df9ae0a
Author:    michaelm
Date:      2009-06-29 13:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b6721df9ae0a

Merge


Changeset: a44009aba19f
Author:    chegar
Date:      2009-06-29 14:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/a44009aba19f

6855335: Several changes in the SCTP implementation.
Reviewed-by: michaelm

! make/com/sun/nio/sctp/mapfile-vers
! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpNet.java
! src/solaris/classes/sun/nio/ch/SctpResultContainer.java
! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
! src/solaris/native/sun/nio/ch/Sctp.h
! src/solaris/native/sun/nio/ch/SctpChannelImpl.c
! src/solaris/native/sun/nio/ch/SctpNet.c
! test/com/sun/nio/sctp/SctpChannel/Connect.java
! test/com/sun/nio/sctp/SctpChannel/Shutdown.java
! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
+ test/com/sun/nio/sctp/SctpMultiChannel/Branch.java
+ test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java

Changeset: 89b14d3740dc
Author:    michaelm
Date:      2009-06-29 15:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/89b14d3740dc

6827999: 6827999: URLClassLoader.addURL(URL) adds URLs to closed class loader
Reviewed-by: chegar

! src/share/classes/sun/misc/URLClassPath.java
+ test/java/net/URLClassLoader/B6827999.java

Changeset: 424420bf5917
Author:    michaelm
Date:      2009-06-29 15:08 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/424420bf5917

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: d926534a1c17
Author:    jjg
Date:      2009-06-29 16:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d926534a1c17

6855069: rmic should support v51 class files.
Reviewed-by: jrose

! src/share/classes/sun/tools/java/RuntimeConstants.java

Changeset: cb20a8a1f22f
Author:    tbell
Date:      2009-06-29 17:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/cb20a8a1f22f

Merge


Changeset: 605d3fa6764e
Author:    weijun
Date:      2009-06-30 11:55 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/605d3fa6764e

6855671: DerOutputStream encodes negative integer incorrectly
Reviewed-by: xuelei

! src/share/classes/sun/security/util/DerOutputStream.java
+ test/sun/security/util/DerValue/NegInt.java

Changeset: 1cc9eb0c952e
Author:    sherman
Date:      2009-06-29 19:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1cc9eb0c952e

6707281: Adler32.update() JavaDoc is wrong
6553961: java.util.zip.{CRC32,Adler32}.update(int) doc errors
6646605: Missing method ZipFile.getComment()
6841232: ZipFile should implement Closeable
4985614: Failure on calls to ZipFile constructor
5032358: "java.util.zip.ZipException: The system cannot find the file specified"
6846616: java/util/zip/ZipFile/ReadAfterClose.java failed after fix for 6735255
Summary: some misc bug/rfe fixes for zipfile
Reviewed-by: alanb

! make/java/java/mapfile-vers
! make/java/zip/mapfile-vers
! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/native/java/util/zip/ZipFile.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/java/util/zip/zip_util.h
! test/java/util/zip/ZipFile/ReadAfterClose.java
! test/java/util/zip/ZipFile/ReadZip.java

Changeset: b144685f6694
Author:    sherman
Date:      2009-06-29 21:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b144685f6694

Merge


Changeset: 861f23119072
Author:    tbell
Date:      2009-06-29 23:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/861f23119072

Merge


Changeset: 4e4ff42f3140
Author:    tbell
Date:      2009-07-03 09:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4e4ff42f3140

Merge


Changeset: 49e7d22262a9
Author:    ant
Date:      2009-06-18 11:28 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/49e7d22262a9

4788402: SortingFocusTraversalPolicy: prob with non-focusable focus Cycle Root as first
Reviewed-by: dcherepanov

! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! test/java/awt/Focus/FocusTraversalPolicy/DefaultFTPTest.java
! test/java/awt/Focus/FocusTraversalPolicy/LayoutFTPTest.java

Changeset: 06f35d090a5e
Author:    langel
Date:      2009-06-19 16:49 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/06f35d090a5e

6721086: Toolkit beep does not work consistently
Summary: Flush out after bell is sounded
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: d1bdaf29e531
Author:    dcherepanov
Date:      2009-06-23 13:35 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d1bdaf29e531

6824169: Need to remove some AWT class dependencies
Reviewed-by: art, anthony, igor, alexp

! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/Window.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/shell/ShellFolder.java
- src/share/classes/sun/swing/AccessibleMethod.java
+ src/share/classes/sun/swing/SwingAccessor.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
! src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java

Changeset: 61e25d428bfe
Author:    dcherepanov
Date:      2009-06-23 15:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/61e25d428bfe

6736247: Component.printAll Invalid local JNI handle
Reviewed-by: anthony

! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

Changeset: e279dd2c5a2c
Author:    ant
Date:      2009-06-23 15:53 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e279dd2c5a2c

6821291: assertion failure in awt_Frame.h
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_Frame.h

Changeset: 51e452ff726a
Author:    anthony
Date:      2009-06-23 16:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/51e452ff726a

6851646: test/closed/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java can fail
Summary: Added realSync() call. Made the test public.
Reviewed-by: dcherepanov

+ test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.html
+ test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java

Changeset: 5e880ea33ddc
Author:    yan
Date:      2009-06-26 11:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5e880ea33ddc

6711676: Numpad keys trigger more than one KeyEvent.
Summary: Introduce a new sniffer based on server keymap.
Reviewed-by: art

! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XlibWrapper.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h
! src/solaris/native/sun/xawt/XlibWrapper.c

Changeset: 60290477fe73
Author:    dav
Date:      2009-06-26 19:50 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/60290477fe73

6848458: java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java fails
Summary: consider gap between the component edge and container borders instead of just getX() and getY()
Reviewed-by: dav
Contributed-by: mwong at redhat.com

! test/java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java

Changeset: 2df0d81c4201
Author:    ant
Date:      2009-06-30 12:55 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2df0d81c4201

6855713: jdk7: debug build failure in awt_Frame.cpp
Reviewed-by: dcherepanov, yan

! src/windows/native/sun/windows/awt_Frame.cpp

Changeset: 75497b840ed0
Author:    yan
Date:      2009-06-30 02:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/75497b840ed0

Merge

- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 4d7e08935d95
Author:    yan
Date:      2009-07-01 00:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4d7e08935d95

Merge

- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 9be953f877a8
Author:    yan
Date:      2009-07-01 00:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9be953f877a8

Merge

! src/share/classes/javax/swing/BufferStrategyPaintManager.java

Changeset: 1a52b17a18d2
Author:    yan
Date:      2009-07-07 23:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1a52b17a18d2

Merge

- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 9053bcc8eef0
Author:    herrick
Date:      2009-06-12 14:56 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9053bcc8eef0

6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7
6845973: Update JDK7 with deployment changes in 6u13, 6u14
4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64
6825019: DownloadManager should not be loaded and referenced for full JRE
6738770: REGRESSION:JSException throws when use LiveConnect javascript facility
6772884: plugin2 : java.lang.OutOfMemoryError or crash
6707535: Crossing domain hole affecting multiple sites/domains using plug-in
6728071: Non-verification of Update files may allow unintended updates
6704154: Code loaded from local filesystem should not get access to localhost
6727081: Web Start security restrictions bypass using special extension jnlp
6727079: Java Web Start Socket() restriction bypass
6727071: Cache location/user name information disclosure in SingleInstanceImpl.
6716217: AppletClassLoader adds permissions based on codebase regardless of CS
6694892: Java Webstart inclusion via system properties override [CVE-2008-2086]
6704074: localhost socket access due to cache location exposed
6703909: Java webstart arbitrary file creation using nativelib
6665315: browser crashes when deployment.properties has more slashes ( / )
6660121: Encoding values in JNLP files can cause buffer overflow
6606110: URLConnection.setProxiedHost for resources that are loaded via proxy
6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install
6609756: Buffer Overflow in Java ActiveX component
6608712: Bypassing the same origin policy in Java with crafted names
6534630: "gnumake clobber" doesn't
6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build
6849029: Need some JDK7 merge clean-up after comments on the webrev
6847582: Build problem on JDK7 with isSecureProperty in merge
6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk
6823215: latest merge fixes from 6u12 -> JDK7
6816153: further mergers for JDK7 deployment integration
6807074: Fix Java Kernel and JQS in initial JDK7 builds
Summary: Initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/Release.gmk
! make/common/shared/Compiler-msvc.gmk
! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity.gmk
! make/java/java/FILES_c.gmk
! make/java/redist/Makefile
! make/jpda/tty/Makefile
! make/sun/Makefile
! make/sun/applet/Makefile
! make/sun/jar/Makefile
! make/sun/javazic/tzdata_jdk/jdk11_full_backward
! make/sun/jconsole/Makefile
+ make/sun/jkernel/FILES_c_windows.gmk
+ make/sun/jkernel/FILES_java.gmk
+ make/sun/jkernel/Makefile
! make/sun/native2ascii/Makefile
! make/sun/rmi/rmic/Makefile
! make/sun/serialver/Makefile
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/sun/applet/AppletClassLoader.java
! src/share/classes/sun/applet/AppletPanel.java
+ src/share/classes/sun/jkernel/BackgroundDownloader.java
+ src/share/classes/sun/jkernel/Bundle.java
+ src/share/classes/sun/jkernel/BundleCheck.java
+ src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java
+ src/share/classes/sun/jkernel/DigestOutputStream.java
+ src/share/classes/sun/jkernel/DownloadManager.java
+ src/share/classes/sun/jkernel/KernelError.java
+ src/share/classes/sun/jkernel/Mutex.java
+ src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java
+ src/share/classes/sun/jkernel/StandaloneMessageDigest.java
+ src/share/classes/sun/jkernel/StandaloneSHA.java
! src/share/classes/sun/management/OperatingSystemImpl.java
! src/share/classes/sun/management/ThreadImpl.java
! src/share/classes/sun/misc/Launcher.java
! src/share/classes/sun/misc/PerformanceLogger.java
! src/share/classes/sun/misc/VM.java
! src/share/native/common/jni_util.c
! src/share/native/common/jni_util.h
! src/share/native/sun/misc/VM.c
+ src/solaris/native/common/jni_util_md.c
! src/windows/bin/java_md.c
+ src/windows/native/common/jni_util_md.c
+ src/windows/native/sun/jkernel/DownloadDialog.cpp
+ src/windows/native/sun/jkernel/DownloadDialog.h
+ src/windows/native/sun/jkernel/DownloadHelper.cpp
+ src/windows/native/sun/jkernel/DownloadHelper.h
+ src/windows/native/sun/jkernel/graphics/bullet.bmp
+ src/windows/native/sun/jkernel/graphics/cautionshield32.bmp
+ src/windows/native/sun/jkernel/graphics/java-icon.ico
+ src/windows/native/sun/jkernel/graphics/masthead.bmp
+ src/windows/native/sun/jkernel/graphics/warningmasthead.bmp
+ src/windows/native/sun/jkernel/kernel.cpp
+ src/windows/native/sun/jkernel/kernel.def
+ src/windows/native/sun/jkernel/kernel.h
+ src/windows/native/sun/jkernel/kernel.rc
+ src/windows/native/sun/jkernel/kernel_de.rc
+ src/windows/native/sun/jkernel/kernel_en.rc
+ src/windows/native/sun/jkernel/kernel_es.rc
+ src/windows/native/sun/jkernel/kernel_fr.rc
+ src/windows/native/sun/jkernel/kernel_it.rc
+ src/windows/native/sun/jkernel/kernel_ja.rc
+ src/windows/native/sun/jkernel/kernel_ko.rc
+ src/windows/native/sun/jkernel/kernel_sv.rc
+ src/windows/native/sun/jkernel/kernel_zh.rc
+ src/windows/native/sun/jkernel/kernel_zh_TW.rc
+ src/windows/native/sun/jkernel/resource.h
+ src/windows/native/sun/jkernel/stdafx.cpp
+ src/windows/native/sun/jkernel/stdafx.h
+ src/windows/native/sun/jkernel/version.rc
! src/windows/native/sun/windows/awt.rc
+ src/windows/resource/unpack200_proto.exe.manifest
! src/windows/resource/version.rc
! test/java/awt/Focus/NonFocusableWindowTest/NoEventsTest.java
! test/java/awt/Focus/RestoreFocusOnDisabledComponentTest/RestoreFocusOnDisabledComponentTest.java
! test/java/awt/font/Rotate/TranslatedOutlineTest.java
! test/java/awt/font/Threads/FontThread.java
! test/java/security/AccessControlContext/FailureDebugOption.java
! test/javax/swing/JPopupMenu/6691503/bug6691503.java
! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java

Changeset: ea7620b05a58
Author:    herrick
Date:      2009-06-15 13:08 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ea7620b05a58

Merge

! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity.gmk

Changeset: 4f207797e185
Author:    herrick
Date:      2009-06-19 11:46 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4f207797e185

6852646: JDK 7 cannot build w/o ALT_HOTSPOT_KERNEL_PATH set.
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/shared/Defs-windows.gmk
! make/common/shared/Sanity.gmk

Changeset: 23c7d780c1b3
Author:    herrick
Date:      2009-06-19 15:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/23c7d780c1b3

6853152: JDK 7 cannot build w/o ALT_HOTSPOT_KERNEL_PATH set. - still broken
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/shared/Defs-windows.gmk
! make/java/redist/Makefile

Changeset: f509fe92a102
Author:    herrick
Date:      2009-06-22 09:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f509fe92a102

Merge


Changeset: 9362d0114c3a
Author:    herrick
Date:      2009-06-24 14:49 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9362d0114c3a

6633813: Add standard hotspot import path for Kernel VM
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/shared/Defs-windows.gmk
! make/java/redist/Makefile

Changeset: dd0371861841
Author:    herrick
Date:      2009-06-29 12:06 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/dd0371861841

Merge

! make/common/Release.gmk
! make/sun/Makefile
! src/share/classes/java/lang/System.java
- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 4caa574b3993
Author:    herrick
Date:      2009-06-29 17:34 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4caa574b3993

6855953: JDK7 - merger error of deployment changes with b62 -in jdk/make/sun/Makefile
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/sun/Makefile

Changeset: 9710ed723163
Author:    herrick
Date:      2009-07-01 10:18 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9710ed723163

Merge

! src/share/classes/java/awt/color/ICC_Profile.java

Changeset: c51ead46c547
Author:    herrick
Date:      2009-07-06 14:10 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/c51ead46c547

Merge

! make/common/Release.gmk
- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: a50217eb3ee1
Author:    jqzuo
Date:      2009-07-09 13:53 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/a50217eb3ee1

Merge

- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 913ad033bb37
Author:    yan
Date:      2009-07-12 06:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/913ad033bb37

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- src/share/classes/sun/swing/AccessibleMethod.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java



From yuri.nesterenko at sun.com  Sun Jul 12 17:13:20 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Sun, 12 Jul 2009 17:13:20 +0000
Subject: <Swing Dev> hg: jdk7/swing/langtools: 24 new changesets
Message-ID: <20090712171359.04D59EEDF@hg.openjdk.java.net>

Changeset: 5c2c81120555
Author:    xdono
Date:      2009-06-25 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/5c2c81120555

Added tag jdk7-b62 for changeset 6855e5aa3348

! .hgtags

Changeset: 619c768ad104
Author:    xdono
Date:      2009-07-02 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/619c768ad104

Added tag jdk7-b63 for changeset 5c2c81120555

! .hgtags

Changeset: a9c04a57a39f
Author:    mcimadamore
Date:      2009-06-16 10:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/a9c04a57a39f

6845686: basic and raw formatters do not display captured var id properly when javac runs in -XDoldDiags mode
Summary: Basic and raw formatters do not override Printer methods properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! test/tools/javac/Diagnostics/6799605/T6799605.java
! test/tools/javac/Diagnostics/6799605/T6799605.out

Changeset: 3d539f4123b8
Author:    mcimadamore
Date:      2009-06-16 10:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/3d539f4123b8

6835430: javac does not generate signature attributes for classes extending parameterized inner classes
Summary: ClassWriter does not consider outer params of an inner class when emitting signature attributes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/6835430/A.java
+ test/tools/javac/6835430/T6835430.java

Changeset: 3ac205ad1f05
Author:    mcimadamore
Date:      2009-06-16 10:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/3ac205ad1f05

6835428: regression: return-type inference rejects valid code
Summary: Redundant subtyping test during type-inference ends up in rejecting legal code
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/generics/inference/T6835428.java

Changeset: 22872b24d38c
Author:    mcimadamore
Date:      2009-06-16 10:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/22872b24d38c

6638712: Inference with wildcard types causes selection of inapplicable method
Summary: Added global sanity check in order to make sure that return type inference does not violate bounds constraints
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/generics/inference/6302954/T6476073.java
+ test/tools/javac/generics/inference/6638712/T6638712a.java
+ test/tools/javac/generics/inference/6638712/T6638712a.out
+ test/tools/javac/generics/inference/6638712/T6638712b.java
+ test/tools/javac/generics/inference/6638712/T6638712b.out
+ test/tools/javac/generics/inference/6638712/T6638712c.java
+ test/tools/javac/generics/inference/6638712/T6638712c.out
+ test/tools/javac/generics/inference/6638712/T6638712d.java
+ test/tools/javac/generics/inference/6638712/T6638712d.out
+ test/tools/javac/generics/inference/6638712/T6638712e.java
+ test/tools/javac/generics/inference/6638712/T6638712e.out

Changeset: ed989c347b3c
Author:    jjg
Date:      2009-06-19 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/ed989c347b3c

6852856: javap changes to facilitate subclassing javap for variants
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/share/classes/com/sun/tools/javap/ClassWriter.java
! src/share/classes/com/sun/tools/javap/ConstantWriter.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/com/sun/tools/javap/SourceWriter.java

Changeset: fe077c71cd47
Author:    tbell
Date:      2009-06-23 22:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/fe077c71cd47

Merge


Changeset: 18e0269f25e3
Author:    mcimadamore
Date:      2009-06-24 10:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/18e0269f25e3

6822637: ResolveError hierarchy needs to be refactored
Summary: Break ResolveError class into a hierarchy representing different kinds of resolution errors
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java

Changeset: 8ec37cf2b37e
Author:    mcimadamore
Date:      2009-06-24 10:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/8ec37cf2b37e

6852595: Accessing scope using JSR199 API on erroneous tree causes Illegal Argument Exception
Summary: Fixed problem with empty DiagnosticSource objects causing IAE in the JCDiagnostic constructor
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/util/AbstractLog.java
! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java
+ test/tools/javac/api/6852595/T6852595.java

Changeset: 1d9e61e0a075
Author:    mcimadamore
Date:      2009-06-24 10:51 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/1d9e61e0a075

6852649: The Rich formatter printer should be an explicit class to facilitate overriding
Summary: Improve reusabiliy of the rich formatter by removing anonymous inner classes/changing visibility of fields
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java

Changeset: 812d5486a023
Author:    tbell
Date:      2009-06-24 17:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/812d5486a023

Merge


Changeset: e71fd3fcebf5
Author:    tbell
Date:      2009-06-26 10:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/e71fd3fcebf5

Merge


Changeset: ca063536e4a6
Author:    darcy
Date:      2009-06-26 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/ca063536e4a6

6593082: MirroredTypeException constructor does not throw NPE when type is null
Reviewed-by: jjg

! src/share/classes/javax/lang/model/type/MirroredTypeException.java
+ test/tools/javac/processing/model/type/MirroredTypeEx/NpeTest.java

Changeset: 03944ee4fac4
Author:    jjg
Date:      2009-06-26 18:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/03944ee4fac4

6843077: JSR 308: Annotations on types
Reviewed-by: jjg, mcimadamore, darcy
Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu

! src/share/bin/launcher.sh-template
! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreePath.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javap/AnnotationWriter.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! test/tools/javac/6341866/T6341866.java
! test/tools/javac/processing/6348499/T6348499.java
! test/tools/javac/processing/6414633/T6414633.java
! test/tools/javac/processing/6430209/T6430209.java
! test/tools/javac/processing/T6439826.java

Changeset: 664edca41e34
Author:    jjg
Date:      2009-06-26 19:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/664edca41e34

6855544: add missing files
Reviewed-by: jjg, mcimadamore, darcy
Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu

+ src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java
+ src/share/classes/com/sun/source/util/AbstractTypeProcessor.java
+ src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java
+ src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/javac/code/TargetType.java
+ src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
+ test/tools/javac/api/TestTreePath.java
+ test/tools/javac/meth/InvokeMH_BAD68.java
+ test/tools/javac/meth/InvokeMH_BAD72.java
+ test/tools/javac/quid/QuotedIdent_BAD61.java
+ test/tools/javac/quid/QuotedIdent_BAD62.java
+ test/tools/javac/quid/QuotedIdent_BAD63.java
+ test/tools/javac/typeAnnotations/InnerClass.java
+ test/tools/javac/typeAnnotations/MultipleTargets.java
+ test/tools/javac/typeAnnotations/TypeParameterTarget.java
+ test/tools/javac/typeAnnotations/TypeUseTarget.java
+ test/tools/javac/typeAnnotations/attribution/Scopes.java
+ test/tools/javac/typeAnnotations/failures/AnnotationVersion.java
+ test/tools/javac/typeAnnotations/failures/AnnotationVersion.out
+ test/tools/javac/typeAnnotations/failures/IncompleteArray.java
+ test/tools/javac/typeAnnotations/failures/IncompleteArray.out
+ test/tools/javac/typeAnnotations/failures/IncompleteVararg.java
+ test/tools/javac/typeAnnotations/failures/IncompleteVararg.out
+ test/tools/javac/typeAnnotations/failures/IndexArray.java
+ test/tools/javac/typeAnnotations/failures/IndexArray.out
+ test/tools/javac/typeAnnotations/failures/LintCast.java
+ test/tools/javac/typeAnnotations/failures/LintCast.out
+ test/tools/javac/typeAnnotations/failures/OldArray.java
+ test/tools/javac/typeAnnotations/failures/OldArray.out
+ test/tools/javac/typeAnnotations/failures/Scopes.java
+ test/tools/javac/typeAnnotations/failures/Scopes.out
+ test/tools/javac/typeAnnotations/failures/StaticFields.java
+ test/tools/javac/typeAnnotations/failures/StaticFields.out
+ test/tools/javac/typeAnnotations/failures/StaticMethods.java
+ test/tools/javac/typeAnnotations/failures/StaticMethods.out
+ test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
+ test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
+ test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java
+ test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out
+ test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
+ test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
+ test/tools/javac/typeAnnotations/failures/target/Constructor.java
+ test/tools/javac/typeAnnotations/failures/target/Constructor.out
+ test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java
+ test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out
+ test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java
+ test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out
+ test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java
+ test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out
+ test/tools/javac/typeAnnotations/failures/target/VoidMethod.java
+ test/tools/javac/typeAnnotations/failures/target/VoidMethod.out
+ test/tools/javac/typeAnnotations/newlocations/BasicTest.java
+ test/tools/javac/typeAnnotations/newlocations/ClassExtends.java
+ test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java
+ test/tools/javac/typeAnnotations/newlocations/ClassParameters.java
+ test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java
+ test/tools/javac/typeAnnotations/newlocations/Expressions.java
+ test/tools/javac/typeAnnotations/newlocations/Fields.java
+ test/tools/javac/typeAnnotations/newlocations/LocalVariables.java
+ test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java
+ test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java
+ test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java
+ test/tools/javac/typeAnnotations/newlocations/Parameters.java
+ test/tools/javac/typeAnnotations/newlocations/Receivers.java
+ test/tools/javac/typeAnnotations/newlocations/Throws.java
+ test/tools/javac/typeAnnotations/newlocations/TypeCasts.java
+ test/tools/javac/typeAnnotations/newlocations/TypeParameters.java
+ test/tools/javac/typeAnnotations/newlocations/Wildcards.java
+ test/tools/javap/typeAnnotations/ClassLiterals.java
+ test/tools/javap/typeAnnotations/JSR175Annotations.java
+ test/tools/javap/typeAnnotations/NewArray.java
+ test/tools/javap/typeAnnotations/Presence.java
+ test/tools/javap/typeAnnotations/PresenceInner.java
+ test/tools/javap/typeAnnotations/Visibility.java

Changeset: 7c154fdc3547
Author:    jjg
Date:      2009-06-26 19:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/7c154fdc3547

6854796: update JSR308 impl with latest code from type-annotations repo
Reviewed-by: jjg, mcimadamore, darcy
Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu

! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java

Changeset: 464d58654324
Author:    jjg
Date:      2009-06-27 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/464d58654324

6855563: test broken after merge with latest parser
Reviewed-by: jjg
Contributed-by: mali at csail.mit.edu

! test/tools/javac/typeAnnotations/failures/OldArray.java
- test/tools/javac/typeAnnotations/failures/OldArray.out

Changeset: c391a167ac57
Author:    tbell
Date:      2009-06-28 00:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/c391a167ac57

Merge


Changeset: 7913e72a24b0
Author:    jjg
Date:      2009-06-29 17:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/7913e72a24b0

6855993: fix comments in langtools launcher script
Reviewed-by: ohair

! src/share/bin/launcher.sh-template

Changeset: ec1acd3af057
Author:    tbell
Date:      2009-06-29 23:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/ec1acd3af057

Merge


Changeset: 24374861f91e
Author:    tbell
Date:      2009-07-03 09:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/24374861f91e

Merge


Changeset: 09dc14c713f0
Author:    yan
Date:      2009-07-01 00:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/09dc14c713f0

Merge


Changeset: d8f23a81d46f
Author:    yan
Date:      2009-07-07 23:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/d8f23a81d46f

Merge




From Anthony.Petrov at Sun.COM  Tue Jul 14 10:33:11 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 14 Jul 2009 14:33:11 +0400
Subject: <Swing Dev> <AWT Dev> Lw/Hw mixing vs
	revalidate()/validate()/invalidate()
In-Reply-To: <4A54AB49.5050408@sun.com>
References: <4f9903f0906200652w1cb1111bvd11121a3f0fad10c@mail.gmail.com>
	<4A54AB49.5050408@sun.com>
Message-ID: <4A5C5EE7.7040908@sun.com>

So may I assume that the silence means agreement?

If there's no objections coming within about a week, then I'm going to 
make a patch with an overridden JComponent.invalidate() method.

--
best regards,
Anthony

On 07/08/2009 06:20 PM, Anthony Petrov wrote:
> Just to revive the discussion...
> 
> On 06/20/2009 05:52 PM, Christopher Deckers wrote:
>> 2. Make it so that revalidate does not mark the ancestors of the
>> validate root invalid. I wonder if this is a sensible approach though.
> I guess you mean an overridden JComponent.invalidate() here, since 
> revalidate() calls this method to invalidate the component hierarchy.
> 
> As we understand from the previous discussions, the root problem is 
> indeed the AWT's invalidate() method that goes too far doing its job. 
> Since Swing introduces the concept of "validate root", it seems really 
> natural to me to override the JComponent.invalidate() method 
> accordingly. At least I can't imagine a problem caused by choosing this 
> way.
> 
> What do Swing people think about that?


From Alexander.Potochkin at Sun.COM  Tue Jul 14 14:55:57 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Tue, 14 Jul 2009 18:55:57 +0400
Subject: <Swing Dev> <AWT Dev> Lw/Hw mixing
	vs	revalidate()/validate()/invalidate()
In-Reply-To: <4A5C5EE7.7040908@sun.com>
References: <4f9903f0906200652w1cb1111bvd11121a3f0fad10c@mail.gmail.com>
	<4A54AB49.5050408@sun.com> <4A5C5EE7.7040908@sun.com>
Message-ID: <4A5C9C7D.9070708@sun.com>

Hello Anthony

> So may I assume that the silence means agreement?

Yep!
I see no problems with overridden JComponent.invalidate()

> If there's no objections coming within about a week, then I'm going to 
> make a patch with an overridden JComponent.invalidate() method.

There is no need to wait, please send the patch when it is ready

Thanks
alexp

> 
> -- 
> best regards,
> Anthony
> 
> On 07/08/2009 06:20 PM, Anthony Petrov wrote:
>> Just to revive the discussion...
>>
>> On 06/20/2009 05:52 PM, Christopher Deckers wrote:
>>> 2. Make it so that revalidate does not mark the ancestors of the
>>> validate root invalid. I wonder if this is a sensible approach though.
>> I guess you mean an overridden JComponent.invalidate() here, since 
>> revalidate() calls this method to invalidate the component hierarchy.
>>
>> As we understand from the previous discussions, the root problem is 
>> indeed the AWT's invalidate() method that goes too far doing its job. 
>> Since Swing introduces the concept of "validate root", it seems really 
>> natural to me to override the JComponent.invalidate() method 
>> accordingly. At least I can't imagine a problem caused by choosing 
>> this way.
>>
>> What do Swing people think about that?



From langel at redhat.com  Wed Jul 15 12:23:20 2009
From: langel at redhat.com (Lillian Angel)
Date: Wed, 15 Jul 2009 08:23:20 -0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A574D07.50606@redhat.com>
References: <4A37BE1F.4030300@redhat.com>	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>	<4A3BE58F.70608@redhat.com>
	<4A423DF0.8050401@redhat.com>	<4A521C90.6030806@redhat.com>
	<4A574AF4.2020207@redhat.com>	<4A574C8C.3010703@Sun.COM>
	<4A574D07.50606@redhat.com>
Message-ID: <4A5DCA38.2010207@redhat.com>

Lillian Angel wrote:
> Sergey Groznyh wrote:
>>>>>>> Lillian Angel wrote:
>>>>>>>             
>>
>>  
>>>>> Can someone please review this?         
>>>> I have updated the patch, can someone please review it again?       
>>
>> Sorry Lillian, I was on vacation. Will get to your fix soon.
>
>
> No problem :) Thanks


I posted another updated patch for review.

Thanks!



From Anthony.Petrov at Sun.COM  Wed Jul 15 15:11:16 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 15 Jul 2009 19:11:16 +0400
Subject: <Swing Dev> Review request: 6852592 (revalidate() must be smarter)
Message-ID: <4A5DF194.9000706@sun.com>

Hello Swing and AWT teams,

This is a fix for the problem discussed recently (see the thread "Lw/Hw 
mixing vs revalidate()/validate()/invalidate()"). The webrev:

http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/

Please review.

A couple of notes:

1. We need to get a CCC approval for the API specification changes. This 
will take some time.

2. The Container.invalidate() previously had a block of code that was 
executed w/o grabbing the TreeLock (a call to the 
LayoutManager2.invalidateLayout())). Now the code is moved to the 
invalidateImpl() which is always invoked under the TreeLock. This 
doesn't seem to be a problem: actually only the initial call to the 
Container.invalidate() ran the code off the lock. All subsequent 
recursive calls to this method did in fact happen under the lock. 
Therefore I assume that this change is OK.

--
best regards,
Anthony


From Anthony.Petrov at Sun.COM  Wed Jul 15 15:12:01 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 15 Jul 2009 19:12:01 +0400
Subject: <Swing Dev> <AWT Dev> Lw/Hw mixing
	vs	revalidate()/validate()/invalidate()
In-Reply-To: <4A5C9C7D.9070708@sun.com>
References: <4f9903f0906200652w1cb1111bvd11121a3f0fad10c@mail.gmail.com>
	<4A54AB49.5050408@sun.com> <4A5C5EE7.7040908@sun.com>
	<4A5C9C7D.9070708@sun.com>
Message-ID: <4A5DF1C1.8030107@sun.com>

On 07/14/2009 06:55 PM, Alexander Potochkin wrote:
>> So may I assume that the silence means agreement?
> 
> Yep!
> I see no problems with overridden JComponent.invalidate()
> 
>> If there's no objections coming within about a week, then I'm going to 
>> make a patch with an overridden JComponent.invalidate() method.
> 
> There is no need to wait, please send the patch when it is ready
Thanks!

--
best regards,
Anthony

> 
> Thanks
> alexp
> 
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 07/08/2009 06:20 PM, Anthony Petrov wrote:
>>> Just to revive the discussion...
>>>
>>> On 06/20/2009 05:52 PM, Christopher Deckers wrote:
>>>> 2. Make it so that revalidate does not mark the ancestors of the
>>>> validate root invalid. I wonder if this is a sensible approach though.
>>> I guess you mean an overridden JComponent.invalidate() here, since 
>>> revalidate() calls this method to invalidate the component hierarchy.
>>>
>>> As we understand from the previous discussions, the root problem is 
>>> indeed the AWT's invalidate() method that goes too far doing its job. 
>>> Since Swing introduces the concept of "validate root", it seems 
>>> really natural to me to override the JComponent.invalidate() method 
>>> accordingly. At least I can't imagine a problem caused by choosing 
>>> this way.
>>>
>>> What do Swing people think about that?
> 


From sergey.groznyh at sun.com  Wed Jul 15 15:16:02 2009
From: sergey.groznyh at sun.com (sergey.groznyh at sun.com)
Date: Wed, 15 Jul 2009 15:16:02 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk:
	6612541:	api/javax_swing/text/LabelView/index.html#getXXX[LabelView0004]	fails
	since JDK 7 b20
Message-ID: <20090715151635.EF0F2E12D@hg.openjdk.java.net>

Changeset: b624f8613cc6
Author:    gsm
Date:      2009-07-15 19:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b624f8613cc6

6612541: api/javax_swing/text/LabelView/index.html#getXXX[LabelView0004] fails since JDK 7 b20
Reviewed-by: peterz

! src/share/classes/javax/swing/text/GlyphView.java



From Anthony.Petrov at Sun.COM  Wed Jul 15 16:17:49 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 15 Jul 2009 20:17:49 +0400
Subject: <Swing Dev> Review request: 6852592 (revalidate() must be
	smarter)
In-Reply-To: <4A5DFBBA.5050404@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
Message-ID: <4A5E012D.5070609@sun.com>

On 07/15/2009 07:54 PM, Alexander Potochkin wrote:
> I think checking isValidatRoot() on AWT side
> will save lots of lines of code
> 
> Here is the existing code from the Component class
> 
>             if (Component.isInstanceOf(this, "javax.swing.JComponent")) {
>                 if (((javax.swing.JComponent) this).isOpaque()) {
>                     states.add(AccessibleState.OPAQUE);
>                 }
>             }
> 
> Can we do the same for isValidatRoot()?
Yes, that is a smaller solution (in terms of the code size), though I 
prefer to minimize calling Swing stuff from AWT code. What do others think?

--
best regards,
Anthony

> 
> Thanks
> alexp
> 
>> Hello Swing and AWT teams,
>>
>> This is a fix for the problem discussed recently (see the thread 
>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
>>
>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>
>> Please review.
>>
>> A couple of notes:
>>
>> 1. We need to get a CCC approval for the API specification changes. 
>> This will take some time.
>>
>> 2. The Container.invalidate() previously had a block of code that was 
>> executed w/o grabbing the TreeLock (a call to the 
>> LayoutManager2.invalidateLayout())). Now the code is moved to the 
>> invalidateImpl() which is always invoked under the TreeLock. This 
>> doesn't seem to be a problem: actually only the initial call to the 
>> Container.invalidate() ran the code off the lock. All subsequent 
>> recursive calls to this method did in fact happen under the lock. 
>> Therefore I assume that this change is OK.
>>
>> -- 
>> best regards,
>> Anthony
> 


From Alexander.Potochkin at Sun.COM  Wed Jul 15 16:16:02 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 15 Jul 2009 20:16:02 +0400
Subject: <Swing Dev> Review request: 6852592 (revalidate() must be
	smarter)
In-Reply-To: <4A5E012D.5070609@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com>
Message-ID: <4A5E00C2.5090508@sun.com>

Hello Anthony

>> Can we do the same for isValidatRoot()?
> Yes, that is a smaller solution (in terms of the code size), 

smaller fix is less error-prone
and gives better maintainable code for future changes

> though I 
> prefer to minimize calling Swing stuff from AWT code. What do others think?

let's wait for the rest of the team

Thanks
alexp

> 
> -- 
> best regards,
> Anthony
> 
>>
>> Thanks
>> alexp
>>
>>> Hello Swing and AWT teams,
>>>
>>> This is a fix for the problem discussed recently (see the thread 
>>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
>>>
>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>>
>>> Please review.
>>>
>>> A couple of notes:
>>>
>>> 1. We need to get a CCC approval for the API specification changes. 
>>> This will take some time.
>>>
>>> 2. The Container.invalidate() previously had a block of code that was 
>>> executed w/o grabbing the TreeLock (a call to the 
>>> LayoutManager2.invalidateLayout())). Now the code is moved to the 
>>> invalidateImpl() which is always invoked under the TreeLock. This 
>>> doesn't seem to be a problem: actually only the initial call to the 
>>> Container.invalidate() ran the code off the lock. All subsequent 
>>> recursive calls to this method did in fact happen under the lock. 
>>> Therefore I assume that this change is OK.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>



From Alexander.Potochkin at Sun.COM  Wed Jul 15 15:54:34 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 15 Jul 2009 19:54:34 +0400
Subject: <Swing Dev> Review request: 6852592 (revalidate() must be
	smarter)
In-Reply-To: <4A5DF194.9000706@sun.com>
References: <4A5DF194.9000706@sun.com>
Message-ID: <4A5DFBBA.5050404@sun.com>

Hello Anthony

While the fix itself does what we need,
its implementation is quite confusing

Component.invalidate() calls invalidImpl()

and JComponent.invalidate()
also calls invalidImpl() for validate roots and otherwise
calls super.invalidte()

I think checking isValidatRoot() on AWT side
will save lots of lines of code

Here is the existing code from the Component class

             if (Component.isInstanceOf(this, "javax.swing.JComponent")) {
                 if (((javax.swing.JComponent) this).isOpaque()) {
                     states.add(AccessibleState.OPAQUE);
                 }
             }

Can we do the same for isValidatRoot()?

Thanks
alexp

> Hello Swing and AWT teams,
> 
> This is a fix for the problem discussed recently (see the thread "Lw/Hw 
> mixing vs revalidate()/validate()/invalidate()"). The webrev:
> 
> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
> 
> Please review.
> 
> A couple of notes:
> 
> 1. We need to get a CCC approval for the API specification changes. This 
> will take some time.
> 
> 2. The Container.invalidate() previously had a block of code that was 
> executed w/o grabbing the TreeLock (a call to the 
> LayoutManager2.invalidateLayout())). Now the code is moved to the 
> invalidateImpl() which is always invoked under the TreeLock. This 
> doesn't seem to be a problem: actually only the initial call to the 
> Container.invalidate() ran the code off the lock. All subsequent 
> recursive calls to this method did in fact happen under the lock. 
> Therefore I assume that this change is OK.
> 
> -- 
> best regards,
> Anthony



From Anthony.Petrov at Sun.COM  Wed Jul 15 17:49:07 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 15 Jul 2009 21:49:07 +0400
Subject: <Swing Dev> Review request: 6852592 (revalidate() must be
	smarter)
In-Reply-To: <4A5E00C2.5090508@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
Message-ID: <4A5E1693.2030204@sun.com>

One more concern that comes to my mind is that the logic stated in the 
Swing's method specification is going to be implemented on the AWT's 
side, which I don't like much. So definitely we need more opinions on 
this proposal.

--
best regards,
Anthony

On 7/15/2009 8:16 PM Alexander Potochkin wrote:
> Hello Anthony
> 
>>> Can we do the same for isValidatRoot()?
>> Yes, that is a smaller solution (in terms of the code size), 
> 
> smaller fix is less error-prone
> and gives better maintainable code for future changes
> 
>> though I prefer to minimize calling Swing stuff from AWT code. What do 
>> others think?
> 
> let's wait for the rest of the team
> 
> Thanks
> alexp
> 
>>
>> -- 
>> best regards,
>> Anthony
>>
>>>
>>> Thanks
>>> alexp
>>>
>>>> Hello Swing and AWT teams,
>>>>
>>>> This is a fix for the problem discussed recently (see the thread 
>>>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
>>>>
>>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>>>
>>>> Please review.
>>>>
>>>> A couple of notes:
>>>>
>>>> 1. We need to get a CCC approval for the API specification changes. 
>>>> This will take some time.
>>>>
>>>> 2. The Container.invalidate() previously had a block of code that 
>>>> was executed w/o grabbing the TreeLock (a call to the 
>>>> LayoutManager2.invalidateLayout())). Now the code is moved to the 
>>>> invalidateImpl() which is always invoked under the TreeLock. This 
>>>> doesn't seem to be a problem: actually only the initial call to the 
>>>> Container.invalidate() ran the code off the lock. All subsequent 
>>>> recursive calls to this method did in fact happen under the lock. 
>>>> Therefore I assume that this change is OK.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>
> 


From Jeff.Dinkins at Sun.COM  Wed Jul 15 18:06:18 2009
From: Jeff.Dinkins at Sun.COM (Jeff Dinkins)
Date: Wed, 15 Jul 2009 13:06:18 -0500
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <4A5E00C2.5090508@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
Message-ID: <3D8B6841-DCE7-443C-927F-25C2BBA724A1@sun.com>

>> though I prefer to minimize calling Swing stuff from AWT code. What  
>> do others think?
>
> let's wait for the rest of the team

Is there any awt code that calls into swing already? (not including  
any peer impls)

jeff

>
> Thanks
> alexp
>
>> -- 
>> best regards,
>> Anthony
>>>
>>> Thanks
>>> alexp
>>>
>>>> Hello Swing and AWT teams,
>>>>
>>>> This is a fix for the problem discussed recently (see the thread  
>>>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The  
>>>> webrev:
>>>>
>>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>>>
>>>> Please review.
>>>>
>>>> A couple of notes:
>>>>
>>>> 1. We need to get a CCC approval for the API specification  
>>>> changes. This will take some time.
>>>>
>>>> 2. The Container.invalidate() previously had a block of code that  
>>>> was executed w/o grabbing the TreeLock (a call to the  
>>>> LayoutManager2.invalidateLayout())). Now the code is moved to the  
>>>> invalidateImpl() which is always invoked under the TreeLock. This  
>>>> doesn't seem to be a problem: actually only the initial call to  
>>>> the Container.invalidate() ran the code off the lock. All  
>>>> subsequent recursive calls to this method did in fact happen  
>>>> under the lock. Therefore I assume that this change is OK.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>
>



From Anthony.Petrov at Sun.COM  Wed Jul 15 18:58:27 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 15 Jul 2009 22:58:27 +0400
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <3D8B6841-DCE7-443C-927F-25C2BBA724A1@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<3D8B6841-DCE7-443C-927F-25C2BBA724A1@sun.com>
Message-ID: <4A5E26D3.7070604@sun.com>

Hi Jeff,

On 7/15/2009 10:06 PM Jeff Dinkins wrote:
>>> though I prefer to minimize calling Swing stuff from AWT code. What 
>>> do others think?
>>
>> let's wait for the rest of the team
> 
> Is there any awt code that calls into swing already? (not including any 
> peer impls)
Yes, as Alex already mentioned, see, for instance, the 
Component.AccessibleAWTComponent.getAccessibleStateSet(). Also, see 
Window.setLayeresOpaque(). Still, all this looks quite awkward, 
especially when it comes to implementing a Swing's method specification 
in the AWT's code.

--
best regards,
Anthony

> 
> jeff
> 
>>
>> Thanks
>> alexp
>>
>>> -- 
>>> best regards,
>>> Anthony
>>>>
>>>> Thanks
>>>> alexp
>>>>
>>>>> Hello Swing and AWT teams,
>>>>>
>>>>> This is a fix for the problem discussed recently (see the thread 
>>>>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>>>>
>>>>> Please review.
>>>>>
>>>>> A couple of notes:
>>>>>
>>>>> 1. We need to get a CCC approval for the API specification changes. 
>>>>> This will take some time.
>>>>>
>>>>> 2. The Container.invalidate() previously had a block of code that 
>>>>> was executed w/o grabbing the TreeLock (a call to the 
>>>>> LayoutManager2.invalidateLayout())). Now the code is moved to the 
>>>>> invalidateImpl() which is always invoked under the TreeLock. This 
>>>>> doesn't seem to be a problem: actually only the initial call to the 
>>>>> Container.invalidate() ran the code off the lock. All subsequent 
>>>>> recursive calls to this method did in fact happen under the lock. 
>>>>> Therefore I assume that this change is OK.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>
>>
> 


From chrriis at gmail.com  Wed Jul 15 19:14:39 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Wed, 15 Jul 2009 21:14:39 +0200
Subject: <Swing Dev> <AWT Dev> Review request: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A5E1693.2030204@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<4A5E1693.2030204@sun.com>
Message-ID: <4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>

Hi Anthony,

> One more concern that comes to my mind is that the logic stated in the
> Swing's method specification is going to be implemented on the AWT's side,
> which I don't like much. So definitely we need more opinions on this
> proposal.

This may be a stupid idea, so disregard it if it is :)
If the problem is having isValidateRoot() used by AWT code, why not promote:
public/protected boolean isValidateRoot()
to the Container class? It would obviously return false by default,
but if custom code wants to play with it (which is anyway unlikely to
happen) why not! After all, is there anything specially swingish with
this method?

Cheers,
-Christopher


From Anthony.Petrov at Sun.COM  Thu Jul 16 06:35:04 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 16 Jul 2009 10:35:04 +0400
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<4A5E1693.2030204@sun.com>
	<4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
Message-ID: <4A5ECA18.8050902@sun.com>

On 7/15/2009 11:14 PM Christopher Deckers wrote:
> This may be a stupid idea, so disregard it if it is :)
> If the problem is having isValidateRoot() used by AWT code, why not promote:
> public/protected boolean isValidateRoot()
> to the Container class? It would obviously return false by default,
> but if custom code wants to play with it (which is anyway unlikely to
> happen) why not! After all, is there anything specially swingish with
> this method?
Generally I like the idea. That would make the fix way smaller, and much 
clearer, and would in fact affect only AWT's specification of the 
Component/Container.invalidate() methods.

AWT, do we want to adopt the isValidateRoot() method?

I suspect this happened once before with, say, the isOpaque() method: it 
had had nothing to do with AWT until we recently overrode it in the 
Window class. But still the method is present in the Component class 
since JDK 1.2.

--
best regards,
Anthony


From Peter.Zhelezniakov at Sun.COM  Thu Jul 16 08:37:31 2009
From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov)
Date: Thu, 16 Jul 2009 12:37:31 +0400
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<4A5E1693.2030204@sun.com>
	<4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
Message-ID: <4A5EE6CB.5090300@Sun.com>

Christopher Deckers wrote:
> This may be a stupid idea, so disregard it if it is :)
> If the problem is having isValidateRoot() used by AWT code, why not promote:
> public/protected boolean isValidateRoot()
> to the Container class? It would obviously return false by default,
> but if custom code wants to play with it (which is anyway unlikely to
> happen) why not! After all, is there anything specially swingish with
> this method?

I like this solution best. Having that failed, i would implement Alex's 
suggestion. The cleaner the code, the happier we hackers are =)

Thanks!
-- 
Peter


From sergey.malenkov at sun.com  Thu Jul 16 16:23:29 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 16 Jul 2009 16:23:29 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6505027: terminateEditOnFocusLost
	making problems	for table in JDesktopPane
Message-ID: <20090716162359.06C5FE327@hg.openjdk.java.net>

Changeset: f727cac13697
Author:    malenkov
Date:      2009-07-16 20:12 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f727cac13697

6505027: terminateEditOnFocusLost making problems for table in JDesktopPane
Reviewed-by: alexp

! src/share/classes/javax/swing/JInternalFrame.java
+ test/javax/swing/JInternalFrame/Test6505027.java



From Artem.Ananiev at Sun.COM  Thu Jul 16 16:43:58 2009
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 16 Jul 2009 20:43:58 +0400
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <4A5EE6CB.5090300@Sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<4A5E1693.2030204@sun.com>
	<4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
	<4A5EE6CB.5090300@Sun.com>
Message-ID: <4A5F58CE.4060103@sun.com>


Peter Zhelezniakov wrote:
> Christopher Deckers wrote:
>> This may be a stupid idea, so disregard it if it is :)
>> If the problem is having isValidateRoot() used by AWT code, why not 
>> promote:
>> public/protected boolean isValidateRoot()
>> to the Container class? It would obviously return false by default,
>> but if custom code wants to play with it (which is anyway unlikely to
>> happen) why not! After all, is there anything specially swingish with
>> this method?
> 
> I like this solution best. Having that failed, i would implement Alex's 
> suggestion. The cleaner the code, the happier we hackers are =)

I vote for this proposal too.

Thanks,

Artem

> Thanks!


From Artem.Ananiev at Sun.COM  Thu Jul 16 16:45:59 2009
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 16 Jul 2009 20:45:59 +0400
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <3D8B6841-DCE7-443C-927F-25C2BBA724A1@sun.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<3D8B6841-DCE7-443C-927F-25C2BBA724A1@sun.com>
Message-ID: <4A5F5947.5020603@sun.com>


Jeff Dinkins wrote:
>>> though I prefer to minimize calling Swing stuff from AWT code. What 
>>> do others think?
>>
>> let's wait for the rest of the team
> 
> Is there any awt code that calls into swing already? (not including any 
> peer impls)

I hope, not :) When it's absolutely necessary to call some Swing code 
from AWT (I believe all such cases should be eliminated eventually), we 
first check the component's class name to avoid loading Swing classes.

Thanks,

Artem

> jeff
> 
>>
>> Thanks
>> alexp
>>
>>> -- 
>>> best regards,
>>> Anthony
>>>>
>>>> Thanks
>>>> alexp
>>>>
>>>>> Hello Swing and AWT teams,
>>>>>
>>>>> This is a fix for the problem discussed recently (see the thread 
>>>>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>>>>
>>>>> Please review.
>>>>>
>>>>> A couple of notes:
>>>>>
>>>>> 1. We need to get a CCC approval for the API specification changes. 
>>>>> This will take some time.
>>>>>
>>>>> 2. The Container.invalidate() previously had a block of code that 
>>>>> was executed w/o grabbing the TreeLock (a call to the 
>>>>> LayoutManager2.invalidateLayout())). Now the code is moved to the 
>>>>> invalidateImpl() which is always invoked under the TreeLock. This 
>>>>> doesn't seem to be a problem: actually only the initial call to the 
>>>>> Container.invalidate() ran the code off the lock. All subsequent 
>>>>> recursive calls to this method did in fact happen under the lock. 
>>>>> Therefore I assume that this change is OK.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>
>>
> 


From peter.zhelezniakov at sun.com  Fri Jul 17 11:32:22 2009
From: peter.zhelezniakov at sun.com (peter.zhelezniakov at sun.com)
Date: Fri, 17 Jul 2009 11:32:22 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6387360: Usage of package-private
	class as a	parameter of a method (javax.swing.text.ParagraphView)
Message-ID: <20090717113254.9A893E5AD@hg.openjdk.java.net>

Changeset: 59249ab7aa16
Author:    peterz
Date:      2009-07-17 15:25 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/59249ab7aa16

6387360: Usage of package-private class as a parameter of a method (javax.swing.text.ParagraphView)
Reviewed-by: malenkov

! src/share/classes/javax/swing/text/ParagraphView.java



From Anthony.Petrov at Sun.COM  Fri Jul 17 14:07:40 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 17 Jul 2009 18:07:40 +0400
Subject: <Swing Dev> Review request #2: 6852592 (revalidate() must be
	smarter)
Message-ID: <4A6085AC.3000207@sun.com>

Hello Swing and AWT teams,

This is the next version of the fix for the issue with the 
invalidate()/isValidateRoot() methods. The webrev:

http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.1/

I'm looking forward to your comments.

--
best regards,
Anthony


From Artem.Ananiev at Sun.COM  Mon Jul 20 07:01:30 2009
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 20 Jul 2009 11:01:30 +0400
Subject: <Swing Dev> <AWT Dev> Review request #2: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A6085AC.3000207@sun.com>
References: <4A6085AC.3000207@sun.com>
Message-ID: <4A64164A.5060701@sun.com>

Hi, Anthony,

I see a number of isValidateRoot() methods in Swing code besides in 
JComponent class. Probably, all of them could be linked (@see tag) to 
Container.isValidateRoot() as well?

Another idea is to override this method to return true for Window and 
Applet classes. This would simplify a code in a RepaintManager class, 
for example.

Thanks,

Artem

Anthony Petrov wrote:
> Hello Swing and AWT teams,
> 
> This is the next version of the fix for the issue with the 
> invalidate()/isValidateRoot() methods. The webrev:
> 
> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.1/
> 
> I'm looking forward to your comments.
> 
> -- 
> best regards,
> Anthony


From peter.zhelezniakov at sun.com  Mon Jul 20 09:41:15 2009
From: peter.zhelezniakov at sun.com (peter.zhelezniakov at sun.com)
Date: Mon, 20 Jul 2009 09:41:15 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 2 new changesets
Message-ID: <20090720094158.9322FE836@hg.openjdk.java.net>

Changeset: 4575323d917c
Author:    peterz
Date:      2009-07-20 13:33 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4575323d917c

6857360: NimbusLAF: Menu indicator looks ugly with RTL orientation.
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/nimbus/NimbusIcon.java
! src/share/classes/sun/swing/MenuItemLayoutHelper.java

Changeset: a2114bbf7f3e
Author:    peterz
Date:      2009-07-20 13:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/a2114bbf7f3e

6849331: Nimbus L&F: AbstractRegionPainter's paint context is not initialized
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java



From Anthony.Petrov at Sun.COM  Tue Jul 21 10:13:55 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 21 Jul 2009 14:13:55 +0400
Subject: <Swing Dev> <AWT Dev> Review request #2: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A64164A.5060701@sun.com>
References: <4A6085AC.3000207@sun.com> <4A64164A.5060701@sun.com>
Message-ID: <4A6594E3.1010308@sun.com>

Hi Artem,

On 07/20/2009 11:01 AM, Artem Ananiev wrote:
> I see a number of isValidateRoot() methods in Swing code besides in 
> JComponent class. Probably, all of them could be linked (@see tag) to 
> Container.isValidateRoot() as well?
Yeah, that's a good suggestion. Done.

> Another idea is to override this method to return true for Window and 
> Applet classes. This would simplify a code in a RepaintManager class, 
> for example.
Indeed, overriding it for Window and Applet makes sense. Though I would 
like to avoid hacking the Swing code much with this fix. Perhaps we 
should file a separate CR for the optimization task?

--
best regards,
Anthony

>> This is the next version of the fix for the issue with the 
>> invalidate()/isValidateRoot() methods. The webrev:
>>
>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.1/


From fbrunnerlist at gmx.ch  Tue Jul 21 20:38:19 2009
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Tue, 21 Jul 2009 22:38:19 +0200
Subject: <Swing Dev> [PATCH] 6179357: Generics: JList
In-Reply-To: <200906191228.55101.fbrunnerlist@gmx.ch>
References: <200903222003.05081.fbrunnerlist@gmx.ch> <4A31301B.3020904@sun.com>
	<200906191228.55101.fbrunnerlist@gmx.ch>
Message-ID: <200907212238.19991.fbrunnerlist@gmx.ch>

Hi Pavel,

I hope you had nice holidays.

Do you have any news about the patch?

-Florian

Am Freitag, 19. Juni 2009 schrieb Florian Brunner:
> Hi Pavel,
>
> enjoy your holidays! My holidays start from 27th June till 8th July, so we
> can continue the work on generics afterwards again.
>
> -Florian
>
> Am Donnerstag, 11. Juni 2009 schrieb Pavel Porvatov:
> > Hi Florian,
> >
> > > Hi Pavel,
> > >
> > > no problem, I presumably don't have much time in June anyway. Just tell
> > > me when there are some news about the patch.
> >
> > Sure.
> >
> > Regards, Pavel
> >
> > P.S. Note that I have vacation from 15th till 30th June.
> >
> > > -Florian
> > >
> > > Am Montag, 1. Juni 2009 schrieb Pavel Porvatov:
> > >> Hi Florian,
> > >>
> > >> I've filed request about changing API according to your fix.
> > >>
> > >> A couple comments:
> > >> 1. Because of J1 approve of changing API can be delayed
> > >>
> > >> 2. We should generify all subclasses of generified classes and
> > >> interfaces in the JDK
> > >>
> > >> 3. One of our developers Alexander Potochkin suggests the next
> > >> generification step:
> > >>
> > >> ---------------
> > >> I'd like to suggest the next generification step
> > >> - ComponentUI and descendants
> > >>
> > >> the fix should be quite simple:
> > >>
> > >> class ComponentUI<C extends JComponent> {
> > >>
> > >>    public void installUI(C c) {
> > >>      }
> > >>
> > >>     public void paint(Graphics g, C c) {
> > >>      }
> > >>
> > >>   // and so on
> > >> }
> > >>
> > >> and then:
> > >>
> > >> class ButtonUI extends ComponentUI<AbstractButton>
> > >>
> > >> it's okay if RadioButtonUI, CheckBoxUI etc...
> > >> will inherit AbstractButton as the generic type,
> > >> because they cast JComponent to AbstractButton anyway
> > >>
> > >> class TableUI extends ComponentUI<JTable> etc...
> > >>
> > >> note that the JComponent subclasses will not be modified
> > >> -------------
> > >>
> > >> Regards, Pavel
> > >>
> > >>> Hi Pavel,
> > >>>
> > >>> as far as I remember, the problem with
> > >>> E[] getSelectedValues()
> > >>>
> > >>> was, that it is not possible to create a generic array.
> > >>>
> > >>> As for:
> > >>> public E[] getSelectedValues(E[] a)
> > >>>
> > >>> you can get this array already with
> > >>> getSelectedValuesList().toArray(array)
> > >>>
> > >>> Of course, the other way around would work, too, but since lists
> > >>> should generally be preferred to arrays for various reasons (see item
> > >>> 25 of Joshua Bloch's book "Effective Java", 2nd edition, for some of
> > >>> them), I think we should prefer
> > >>>
> > >>> List<E> getSelectedValuesList()
> > >>>
> > >>> over
> > >>>
> > >>> E[] getSelectedValues(E[] a)
> > >>>
> > >>> As for deprecating the original getSelectedValues() method:
> > >>> It's not absolutly needed, but then we would have 2 methods, which
> > >>> would do pretty much the same. This could confuse users, which one to
> > >>> use. By deprecating the old one, we tell users that for new code,
> > >>> lists and generics are preferred. They still can get an array when
> > >>> needed without getting a deprecated warning, by calling one of the
> > >>> toArray-methods.
> > >>>
> > >>> And since people are complaining, that the Swing API is already
> > >>> bloated (eg. see the Swing 2.0 discussions at
> > >>> http://kenai.com/projects/swing2/lists ), I think it's a good thing
> > >>> to reduce the API by deprecating methods, if there are other methods
> > >>> which should be preferred.
> > >>>
> > >>> -Florian
> > >>>
> > >>>> Hi Florian,
> > >>>>
> > >>>> Some time ago we discussed two different ways to add the new method
> > >>>> "getSelectedValuesList()". The first one is the current
> > >>>> implementation in your fix:
> > >>>>
> > >>>> 1. public List<E> getSelectedValuesList()
> > >>>> Benefits:
> > >>>>    a. easy to use
> > >>>>    b. Collection framework is very flexible
> > >>>>
> > >>>> The second way is:
> > >>>>
> > >>>> 2. public E[] getSelectedValues(E[] a)
> > >>>> Benefits:
> > >>>>    a. The same pattern used in the java.util.Collection#toArray(T[]
> > >>>> a) method
> > >>>>    b. a little bit easer to port an old code
> > >>>>
> > >>>> Also a lot of people noticed that there is no need to deprecate the
> > >>>> javax.swing.JList#getSelectedValues method because it still can be
> > >>>> useful.
> > >>>>
> > >>>> Any ideas?
> > >>>>
> > >>>> Regards, Pavel
> > >>>>
> > >>>>> Hi Pavel, hi Alexander,
> > >>>>>
> > >>>>> I'm back from holiday.
> > >>>>>
> > >>>>> What is the status of this patch? Any news?
> > >>>>>
> > >>>>> -Florian
> > >>>>>
> > >>>>> Alexander Potochkin schrieb:
> > >>>>>> Hello Florian
> > >>>>>>
> > >>>>>>> Great! :-)
> > >>>>>>>
> > >>>>>>> In the case of other issues please note that I'm on holiday until
> > >>>>>>> the end of next week.
> > >>>>>>
> > >>>>>> Have a nice holiday!
> > >>>>>>
> > >>>>>> (I am reviewing the fix right now)
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> alexp
> > >>>>>>
> > >>>>>>> -Florian
> > >>>>>>>
> > >>>>>>> Pavel Porvatov schrieb:
> > >>>>>>>> Hi Florian,
> > >>>>>>>>
> > >>>>>>>>> Hi Pavel,
> > >>>>>>>>>
> > >>>>>>>>> I agree that we should avoid to mix several different fixes in
> > >>>>>>>>> one fix, but since in this fix we change
> > >>>>>>>>>
> > >>>>>>>>> AbstractListModel to AbstractListModel<E>
> > >>>>>>>>> and
> > >>>>>>>>> JList(ListModel dataModel) to JList(ListModel<E> dataModel)
> > >>>>>>>>>
> > >>>>>>>>> I think we should also change usages of AbstractListModel  such
> > >>>>>>>>> as "this (new AbstractListModel()...)" to "this (new
> > >>>>>>>>> AbstractListModel<E>()...)" to avoid warnings.
> > >>>>>>>>
> > >>>>>>>> Ok, then it will not be a problem. Let's include this change in
> > >>>>>>>> your fix. Therefore all my comments are gone and I'm going to
> > >>>>>>>> start our internal process to commit your fix.
> > >>>>>>>>
> > >>>>>>>> Thanks, Pavel.
> > >>>>>>>>
> > >>>>>>>>> If you don't agree:
> > >>>>>>>>> There are several places where I changed the usage of now
> > >>>>>>>>> generified classes to the generic variant. Which ones should I
> > >>>>>>>>> change back? Only this case?




From sergey.malenkov at sun.com  Wed Jul 22 08:30:08 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Wed, 22 Jul 2009 08:30:08 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6802868: JInternalFrame is not
	maximized when	maximized parent frame.
Message-ID: <20090722083037.80825EB95@hg.openjdk.java.net>

Changeset: 125eff6f653f
Author:    malenkov
Date:      2009-07-22 12:21 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/125eff6f653f

6802868: JInternalFrame is not maximized when maximized parent frame.
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
+ test/javax/swing/JInternalFrame/Test6802868.java



From Pavel.Porvatov at Sun.COM  Wed Jul 22 13:32:00 2009
From: Pavel.Porvatov at Sun.COM (Pavel Porvatov)
Date: Wed, 22 Jul 2009 17:32:00 +0400
Subject: <Swing Dev> [PATCH] 6179357: Generics: JList
In-Reply-To: <200907212238.19991.fbrunnerlist@gmx.ch>
References: <200903222003.05081.fbrunnerlist@gmx.ch> <4A31301B.3020904@sun.com>
	<200906191228.55101.fbrunnerlist@gmx.ch>
	<200907212238.19991.fbrunnerlist@gmx.ch>
Message-ID: <4A6714D0.1000009@sun.com>

Hi Florian,

> Hi Pavel,
> 
> I hope you had nice holidays.
> 
> Do you have any news about the patch?
I'm awaiting approve of API changes. It's not a very quick step because 
a lot of people should take a look at your changes and give approve for 
it...

Regards, Pavel


> 
> -Florian
> 
> Am Freitag, 19. Juni 2009 schrieb Florian Brunner:
>> Hi Pavel,
>>
>> enjoy your holidays! My holidays start from 27th June till 8th July, so we
>> can continue the work on generics afterwards again.
>>
>> -Florian
>>
>> Am Donnerstag, 11. Juni 2009 schrieb Pavel Porvatov:
>>> Hi Florian,
>>>
>>>> Hi Pavel,
>>>>
>>>> no problem, I presumably don't have much time in June anyway. Just tell
>>>> me when there are some news about the patch.
>>> Sure.
>>>
>>> Regards, Pavel
>>>
>>> P.S. Note that I have vacation from 15th till 30th June.
>>>
>>>> -Florian
>>>>
>>>> Am Montag, 1. Juni 2009 schrieb Pavel Porvatov:
>>>>> Hi Florian,
>>>>>
>>>>> I've filed request about changing API according to your fix.
>>>>>
>>>>> A couple comments:
>>>>> 1. Because of J1 approve of changing API can be delayed
>>>>>
>>>>> 2. We should generify all subclasses of generified classes and
>>>>> interfaces in the JDK
>>>>>
>>>>> 3. One of our developers Alexander Potochkin suggests the next
>>>>> generification step:
>>>>>
>>>>> ---------------
>>>>> I'd like to suggest the next generification step
>>>>> - ComponentUI and descendants
>>>>>
>>>>> the fix should be quite simple:
>>>>>
>>>>> class ComponentUI<C extends JComponent> {
>>>>>
>>>>>    public void installUI(C c) {
>>>>>      }
>>>>>
>>>>>     public void paint(Graphics g, C c) {
>>>>>      }
>>>>>
>>>>>   // and so on
>>>>> }
>>>>>
>>>>> and then:
>>>>>
>>>>> class ButtonUI extends ComponentUI<AbstractButton>
>>>>>
>>>>> it's okay if RadioButtonUI, CheckBoxUI etc...
>>>>> will inherit AbstractButton as the generic type,
>>>>> because they cast JComponent to AbstractButton anyway
>>>>>
>>>>> class TableUI extends ComponentUI<JTable> etc...
>>>>>
>>>>> note that the JComponent subclasses will not be modified
>>>>> -------------
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>>>> Hi Pavel,
>>>>>>
>>>>>> as far as I remember, the problem with
>>>>>> E[] getSelectedValues()
>>>>>>
>>>>>> was, that it is not possible to create a generic array.
>>>>>>
>>>>>> As for:
>>>>>> public E[] getSelectedValues(E[] a)
>>>>>>
>>>>>> you can get this array already with
>>>>>> getSelectedValuesList().toArray(array)
>>>>>>
>>>>>> Of course, the other way around would work, too, but since lists
>>>>>> should generally be preferred to arrays for various reasons (see item
>>>>>> 25 of Joshua Bloch's book "Effective Java", 2nd edition, for some of
>>>>>> them), I think we should prefer
>>>>>>
>>>>>> List<E> getSelectedValuesList()
>>>>>>
>>>>>> over
>>>>>>
>>>>>> E[] getSelectedValues(E[] a)
>>>>>>
>>>>>> As for deprecating the original getSelectedValues() method:
>>>>>> It's not absolutly needed, but then we would have 2 methods, which
>>>>>> would do pretty much the same. This could confuse users, which one to
>>>>>> use. By deprecating the old one, we tell users that for new code,
>>>>>> lists and generics are preferred. They still can get an array when
>>>>>> needed without getting a deprecated warning, by calling one of the
>>>>>> toArray-methods.
>>>>>>
>>>>>> And since people are complaining, that the Swing API is already
>>>>>> bloated (eg. see the Swing 2.0 discussions at
>>>>>> http://kenai.com/projects/swing2/lists ), I think it's a good thing
>>>>>> to reduce the API by deprecating methods, if there are other methods
>>>>>> which should be preferred.
>>>>>>
>>>>>> -Florian
>>>>>>
>>>>>>> Hi Florian,
>>>>>>>
>>>>>>> Some time ago we discussed two different ways to add the new method
>>>>>>> "getSelectedValuesList()". The first one is the current
>>>>>>> implementation in your fix:
>>>>>>>
>>>>>>> 1. public List<E> getSelectedValuesList()
>>>>>>> Benefits:
>>>>>>>    a. easy to use
>>>>>>>    b. Collection framework is very flexible
>>>>>>>
>>>>>>> The second way is:
>>>>>>>
>>>>>>> 2. public E[] getSelectedValues(E[] a)
>>>>>>> Benefits:
>>>>>>>    a. The same pattern used in the java.util.Collection#toArray(T[]
>>>>>>> a) method
>>>>>>>    b. a little bit easer to port an old code
>>>>>>>
>>>>>>> Also a lot of people noticed that there is no need to deprecate the
>>>>>>> javax.swing.JList#getSelectedValues method because it still can be
>>>>>>> useful.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Regards, Pavel
>>>>>>>
>>>>>>>> Hi Pavel, hi Alexander,
>>>>>>>>
>>>>>>>> I'm back from holiday.
>>>>>>>>
>>>>>>>> What is the status of this patch? Any news?
>>>>>>>>
>>>>>>>> -Florian
>>>>>>>>
>>>>>>>> Alexander Potochkin schrieb:
>>>>>>>>> Hello Florian
>>>>>>>>>
>>>>>>>>>> Great! :-)
>>>>>>>>>>
>>>>>>>>>> In the case of other issues please note that I'm on holiday until
>>>>>>>>>> the end of next week.
>>>>>>>>> Have a nice holiday!
>>>>>>>>>
>>>>>>>>> (I am reviewing the fix right now)
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> alexp
>>>>>>>>>
>>>>>>>>>> -Florian
>>>>>>>>>>
>>>>>>>>>> Pavel Porvatov schrieb:
>>>>>>>>>>> Hi Florian,
>>>>>>>>>>>
>>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>>>
>>>>>>>>>>>> I agree that we should avoid to mix several different fixes in
>>>>>>>>>>>> one fix, but since in this fix we change
>>>>>>>>>>>>
>>>>>>>>>>>> AbstractListModel to AbstractListModel<E>
>>>>>>>>>>>> and
>>>>>>>>>>>> JList(ListModel dataModel) to JList(ListModel<E> dataModel)
>>>>>>>>>>>>
>>>>>>>>>>>> I think we should also change usages of AbstractListModel  such
>>>>>>>>>>>> as "this (new AbstractListModel()...)" to "this (new
>>>>>>>>>>>> AbstractListModel<E>()...)" to avoid warnings.
>>>>>>>>>>> Ok, then it will not be a problem. Let's include this change in
>>>>>>>>>>> your fix. Therefore all my comments are gone and I'm going to
>>>>>>>>>>> start our internal process to commit your fix.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Pavel.
>>>>>>>>>>>
>>>>>>>>>>>> If you don't agree:
>>>>>>>>>>>> There are several places where I changed the usage of now
>>>>>>>>>>>> generified classes to the generic variant. Which ones should I
>>>>>>>>>>>> change back? Only this case?
> 
> 



From Anthony.Petrov at Sun.COM  Thu Jul 23 11:57:07 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 23 Jul 2009 15:57:07 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
	smarter)
Message-ID: <4A685013.7080807@sun.com>

Hello Swing and AWT teams,

So here's the latest version of the fix:

http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/

The specification has been modified, some stuff has been moved around. 
Currently the spec is being reviewed by the CCC at Sun, and therefore is 
kind of frozen. However, if anyone happen to find major problems with 
the javadoc, please feel free to speak up.

Suggestions for the code changes are still very welcome. Thank you in 
advance!

--
best regards,
Anthony


From pavel.porvatov at sun.com  Thu Jul 23 14:05:32 2009
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Thu, 23 Jul 2009 14:05:32 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk:
	6460525:	javax/swing/JFileChooser/6396844/TwentyThousandTest.java
	times out
Message-ID: <20090723140556.3BE4DECBD@hg.openjdk.java.net>

Changeset: 9fc588f78952
Author:    rupashka
Date:      2009-07-23 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9fc588f78952

6460525: javax/swing/JFileChooser/6396844/TwentyThousandTest.java times out
Reviewed-by: malenkov, peterz

! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java
! src/share/classes/sun/awt/shell/ShellFolder.java
! src/share/classes/sun/awt/shell/ShellFolderManager.java
! src/share/classes/sun/swing/FilePane.java
! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java



From chrriis at gmail.com  Thu Jul 23 14:06:36 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Thu, 23 Jul 2009 16:06:36 +0200
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
	smarter)
In-Reply-To: <4A685013.7080807@sun.com>
References: <4A685013.7080807@sun.com>
Message-ID: <4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>

Anthony,

I think I disagree with Applet returning true to isValidateRoot. If I
am not mistaken, I think I saw some people placing an applet in their
component hierarchy as if it was a normal component. Invalidation
should propagate so that outer components can revalidate and thus have
proper layout calculations. Thus I think the only AWT components that
should return true are the ones with an outer parent (window class
hierarchy).

For the window method, shouldn't it be marked as final?

And what about the AWT ScrollPane? Shouldn't it return true as well?

Hope this helps,
-Christopher


On Thu, Jul 23, 2009 at 1:57 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
> Hello Swing and AWT teams,
>
> So here's the latest version of the fix:
>
> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/
>
> The specification has been modified, some stuff has been moved around.
> Currently the spec is being reviewed by the CCC at Sun, and therefore is
> kind of frozen. However, if anyone happen to find major problems with the
> javadoc, please feel free to speak up.
>
> Suggestions for the code changes are still very welcome. Thank you in
> advance!
>
> --
> best regards,
> Anthony
>


From chrriis at gmail.com  Thu Jul 23 14:39:55 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Thu, 23 Jul 2009 16:39:55 +0200
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
	smarter)
In-Reply-To: <4A685013.7080807@sun.com>
References: <4A685013.7080807@sun.com>
Message-ID: <4f9903f0907230739ud07baeeybbeaf061f788cb49@mail.gmail.com>

While looking at some of the changes, I saw some existing code which I
do not really understand: why is JTextField having a special logic in
isValidateRoot in case it is not in a JViewPort? And if this component
has a special handling, why not other components?

-Christopher


On Thu, Jul 23, 2009 at 1:57 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
> Hello Swing and AWT teams,
>
> So here's the latest version of the fix:
>
> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/
>
> The specification has been modified, some stuff has been moved around.
> Currently the spec is being reviewed by the CCC at Sun, and therefore is
> kind of frozen. However, if anyone happen to find major problems with the
> javadoc, please feel free to speak up.
>
> Suggestions for the code changes are still very welcome. Thank you in
> advance!
>
> --
> best regards,
> Anthony
>


From Artem.Ananiev at Sun.COM  Thu Jul 23 14:54:38 2009
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 23 Jul 2009 18:54:38 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
Message-ID: <4A6879AE.4080407@sun.com>


Christopher Deckers wrote:
> Anthony,
> 
> I think I disagree with Applet returning true to isValidateRoot. If I
> am not mistaken, I think I saw some people placing an applet in their
> component hierarchy as if it was a normal component. Invalidation
> should propagate so that outer components can revalidate and thus have
> proper layout calculations. Thus I think the only AWT components that
> should return true are the ones with an outer parent (window class
> hierarchy).

There's a reason to mark an Applet as a validate root: user should be 
able to call validate() on all the validate roots. If invalidate() goes 
up to the applet's parent (embedded frame), what code will call 
validate() on it? Do we want developers to write something like this:

     applet.getParent().validate();

? Embedded frame being a parent of any applet is an implementation 
details of the current AWT/Plugin code, so we shouldn't expose this to 
developers.

As for applets inserted to some regular applications as just plain 
Panels... If it's my own applet, a workaround is to override 
isValidateRoot() to return false. If it's not - do you expect it will 
call validate() on its top-level window? I don't think so. It's a 
responsibility of the host application. At least, we won't make any 
application worse than now.

> For the window method, shouldn't it be marked as final?

This looks like a good idea.

> And what about the AWT ScrollPane? Shouldn't it return true as well?

As well as this one.

Thanks,

Artem

> Hope this helps,
> -Christopher
> 
> 
> On Thu, Jul 23, 2009 at 1:57 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
>> Hello Swing and AWT teams,
>>
>> So here's the latest version of the fix:
>>
>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/
>>
>> The specification has been modified, some stuff has been moved around.
>> Currently the spec is being reviewed by the CCC at Sun, and therefore is
>> kind of frozen. However, if anyone happen to find major problems with the
>> javadoc, please feel free to speak up.
>>
>> Suggestions for the code changes are still very welcome. Thank you in
>> advance!
>>
>> --
>> best regards,
>> Anthony
>>


From chrriis at gmail.com  Thu Jul 23 15:06:19 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Thu, 23 Jul 2009 17:06:19 +0200
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A6879AE.4080407@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com>
Message-ID: <4f9903f0907230806m5587ced1nec4e23638e8f6f3f@mail.gmail.com>

> There's a reason to mark an Applet as a validate root: user should be able
> to call validate() on all the validate roots. If invalidate() goes up to the
> applet's parent (embedded frame), what code will call validate() on it? Do
> we want developers to write something like this:
>
> ? ?applet.getParent().validate();

I remember a project where we had an Web 2.0 like page that contained
many applets. We decided to rewrite the UI framework in Swing but the
applets couldn't be migrated: applets were simple components for the
web page and became simple components of our Swing application.
Why would isValidateRoot not be coded like this for applets:
return getParent() == null? true: false;

And as to how we would validate it, if the applet contains some Swing
code, I guess users would not even notice what is happening behind the
scene:
someComponentInTheApplet.revalidate();

Note that I don't particularily care about whether or not applets are
validate roots, such applet integration is not very common.

-Christopher


From Peter.Zhelezniakov at Sun.COM  Thu Jul 23 15:34:22 2009
From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov)
Date: Thu, 23 Jul 2009 19:34:22 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4f9903f0907230739ud07baeeybbeaf061f788cb49@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230739ud07baeeybbeaf061f788cb49@mail.gmail.com>
Message-ID: <4A6882FE.6000108@Sun.com>

Christopher Deckers wrote:
> While looking at some of the changes, I saw some existing code which I
> do not really understand: why is JTextField having a special logic in
> isValidateRoot in case it is not in a JViewPort? And if this component
> has a special handling, why not other components?

When a text field is in a viewport, it grows indefinitely as more text 
is typed into it, and lets the viewport handle scrolling. A standalone 
text field, on the other hand, starts scrolling text once it exceeds 
available width, thus acting as a viewport by itself. So invalidation 
can safely stop at such text fields -- this is why they are validate roots.

-- 
Peter


From Anthony.Petrov at Sun.COM  Thu Jul 23 18:03:28 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 23 Jul 2009 22:03:28 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4f9903f0907230806m5587ced1nec4e23638e8f6f3f@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com>
	<4f9903f0907230806m5587ced1nec4e23638e8f6f3f@mail.gmail.com>
Message-ID: <4A68A5F0.6070901@sun.com>

Hi Christopher,

On 7/23/2009 7:06 PM Christopher Deckers wrote:
>>    applet.getParent().validate();
> 
> I remember a project where we had an Web 2.0 like page that contained
> many applets. We decided to rewrite the UI framework in Swing but the
> applets couldn't be migrated: applets were simple components for the
> web page and became simple components of our Swing application.
> Why would isValidateRoot not be coded like this for applets:
> return getParent() == null? true: false;
Applets always have a parent: it's either an embedded frame on the 
web-page, or your own container (such as a JFrame, or whatever). So this 
condition is not going to work as we would like it to.

> And as to how we would validate it, if the applet contains some Swing
> code, I guess users would not even notice what is happening behind the
> scene:
> someComponentInTheApplet.revalidate();
Calling the validate() method indicates that Artem is referring to an 
AWT application.

> Note that I don't particularily care about whether or not applets are
> validate roots, such applet integration is not very common.
Do the applets migrated from a web-page into your application resize 
themselves? If not, that means that they do not actually affect the 
layout of their containers, which, in turn, is the definition for 
validate roots. I bet in most cases the size of applets is specified by 
their embedder - a web-page, or an application. So I believe making the 
Applet class a validate root should not harm much. Though if in 0.001% 
of cases it does harm, one may easily override the method in their 
applet to return false, like: myContainer.add(new MyApplet() { public 
boolean isValidateRoot() { return false; } });

--
best regards,
Anthony


From naoto.sato at sun.com  Thu Jul 23 18:49:15 2009
From: naoto.sato at sun.com (naoto.sato at sun.com)
Date: Thu, 23 Jul 2009 18:49:15 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 2 new changesets
Message-ID: <20090723185000.A9681EED9@hg.openjdk.java.net>

Changeset: 5054103dc032
Author:    naoto
Date:      2009-06-30 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5054103dc032

6852429: IME should call ImmIsUIMessage() or DefWindowProc() when it receives WM_IME_SETCONTEX
Reviewed-by: peytoia

! src/windows/native/sun/windows/awt_Component.cpp

Changeset: 584fe3163de9
Author:    naoto
Date:      2009-07-23 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/584fe3163de9

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- src/share/classes/sun/swing/AccessibleMethod.java
! src/windows/native/sun/windows/awt_Component.cpp
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java



From chrriis at gmail.com  Thu Jul 23 20:10:31 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Thu, 23 Jul 2009 22:10:31 +0200
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A68A5F0.6070901@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com>
	<4f9903f0907230806m5587ced1nec4e23638e8f6f3f@mail.gmail.com>
	<4A68A5F0.6070901@sun.com>
Message-ID: <4f9903f0907231310n3bcb7dd5x5943fbe5e95c4b41@mail.gmail.com>

Hi Anthony,

> Applets always have a parent: it's either an embedded frame on the web-page,
> or your own container (such as a JFrame, or whatever). So this condition is
> not going to work as we would like it to.

If I understand correctly, the logical validate root in case of the
browser is the browser frame, not really the applet. The applet is
just a container that can be placed in a web browser and I don't see
why it would have a different treatment than a Panel for example.
I can understand we don't have a handle to the Window object
containing the applet so we can't really call validate(), hence this
work around.

This is mostly a conceptual discussion, as I said I don't really care
about the outcome for the Applet case :)

Slightly off-topic feature: wouldn't it be conceptually possible to
have a special parameter in the applet tag that specifies to use the
preferred size rather than an hardcoded size? That way applet that
declare not being validate roots would really be like any other HTML
elements and would automatically resize following
invalidation/validation cycles. This would also be useful if an applet
has a size that cannot be hardcoded (depending on font sizes or
whatever).

Cheers,
-Christopher


From Anthony.Petrov at Sun.COM  Fri Jul 24 12:06:18 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 24 Jul 2009 16:06:18 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4f9903f0907231310n3bcb7dd5x5943fbe5e95c4b41@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com>
	<4f9903f0907230806m5587ced1nec4e23638e8f6f3f@mail.gmail.com>
	<4A68A5F0.6070901@sun.com>
	<4f9903f0907231310n3bcb7dd5x5943fbe5e95c4b41@mail.gmail.com>
Message-ID: <4A69A3BA.2020702@sun.com>

Hi Chris,

On 07/24/2009 12:10 AM, Christopher Deckers wrote:
>> Applets always have a parent: it's either an embedded frame on the web-page,
>> or your own container (such as a JFrame, or whatever). So this condition is
>> not going to work as we would like it to.
> 
> If I understand correctly, the logical validate root in case of the
> browser is the browser frame, not really the applet. The applet is
> just a container that can be placed in a web browser and I don't see
> why it would have a different treatment than a Panel for example.

If all browsers were written in Java, we could possibly say so. Given 
this is not the case, we just can't expose our concepts (like validate 
roots, and validating in general) beyond the bounds of a Java components 
hierarchy.


> I can understand we don't have a handle to the Window object

We actually do. If you examine an object returned by the 
applet.getParent() when the applet is running on a web page, you can 
notice that it is an instance of the sun.awt.EmbeddedFrame class which 
extends java.awt.Frame. But anyway, this is an implementation detail, 
and we don't really want to tell the users to get the parent of their 
applets and then call validate() on this parent. For a typical user an 
Applet is conceptually the root of their components hierarchy, therefore 
they imply it's enough to validate just that applet to have the whole 
hierarchy valid. However, w/o making the Applet a validate root we'll 
end up with the embedded frame being invalid forever.


> containing the applet so we can't really call validate(), hence this
> work around.
> 
> This is mostly a conceptual discussion, as I said I don't really care
> about the outcome for the Applet case :)
> 
> Slightly off-topic feature: wouldn't it be conceptually possible to
> have a special parameter in the applet tag that specifies to use the
> preferred size rather than an hardcoded size? That way applet that
> declare not being validate roots would really be like any other HTML
> elements and would automatically resize following
> invalidation/validation cycles. This would also be useful if an applet
> has a size that cannot be hardcoded (depending on font sizes or
> whatever).

Theoretically I agree with the concept. However, this is a difficult 
task that would require a lot of collaboration between the Plugin and 
AWT teams, and what's more important (or sad?), might be incompatible 
with some web-browsers. So this seems like a cool idea, but I hardly see 
it implemented in the near future.

--
best regards,
Anthony


From Anthony.Petrov at Sun.COM  Fri Jul 24 12:32:02 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 24 Jul 2009 16:32:02 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
Message-ID: <4A69A9C2.80404@sun.com>

On 07/23/2009 06:06 PM, Christopher Deckers wrote:
> For the window method, shouldn't it be marked as final?

Could you please elaborate on the necessity/reasons of making the 
Window.isValidateRoot() method final?

--
best regards,
Anthony


From yuri.nesterenko at sun.com  Mon Jul 27 13:39:16 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 13:39:16 +0000
Subject: <Swing Dev> hg: jdk7/swing: 7 new changesets
Message-ID: <20090727133916.89E93E846@hg.openjdk.java.net>

Changeset: d92b13b3c138
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/d92b13b3c138

Added tag jdk7-b64 for changeset 269c1ec4435d

! .hgtags

Changeset: 8ca3d95b1ea3
Author:    xdono
Date:      2009-06-22 10:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/8ca3d95b1ea3

6853596: Update Build README-build.html with new info regarding update for Solaris 10u2 and BOOTDIR update
Reviewed-by: tbell, ohair

! README-builds.html

Changeset: 38c6ee1015aa
Author:    xdono
Date:      2009-06-29 22:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/38c6ee1015aa

Merge

! README-builds.html

Changeset: 9ed059501673
Author:    xdono
Date:      2009-07-08 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/9ed059501673

Merge


Changeset: e01380cd1de4
Author:    xdono
Date:      2009-07-14 14:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/e01380cd1de4

Merge


Changeset: 6bad5e3fe503
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/6bad5e3fe503

Added tag jdk7-b65 for changeset e01380cd1de4

! .hgtags

Changeset: 5dc862ec024e
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/5dc862ec024e

Added tag jdk7-b66 for changeset 6bad5e3fe503

! .hgtags



From yuri.nesterenko at sun.com  Mon Jul 27 13:44:39 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 13:44:39 +0000
Subject: <Swing Dev> hg: jdk7/swing/corba: 3 new changesets
Message-ID: <20090727134442.E393DE84B@hg.openjdk.java.net>

Changeset: 97fd9b42f5c2
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/97fd9b42f5c2

Added tag jdk7-b64 for changeset 047dd27fddb6

! .hgtags

Changeset: a821e059a961
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/a821e059a961

Added tag jdk7-b65 for changeset 97fd9b42f5c2

! .hgtags

Changeset: d5e36cb83d8c
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/d5e36cb83d8c

Added tag jdk7-b66 for changeset a821e059a961

! .hgtags



From yuri.nesterenko at sun.com  Mon Jul 27 13:52:14 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 13:52:14 +0000
Subject: <Swing Dev> hg: jdk7/swing/hotspot: 28 new changesets
Message-ID: <20090727135308.B2747E874@hg.openjdk.java.net>

Changeset: 92b5fbbe8477
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/92b5fbbe8477

Added tag jdk7-b64 for changeset ba36394eb84b

! .hgtags

Changeset: 45c4b1fe45e4
Author:    trims
Date:      2009-07-10 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/45c4b1fe45e4

6859411: Bump the HS16 build number to 06
Summary: Update the HS16 build number to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b109e761e927
Author:    kvn
Date:      2009-06-09 16:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/b109e761e927

6837472: com/sun/jdi/MonitorFrameInfo.java fails with AggressiveOpts in 6u14
Summary: Disable escape analysis when jvmti/debugger is used. Add support for EA ibto SA.
Reviewed-by: never

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/MonitorValue.java
+ agent/src/share/classes/sun/jvm/hotspot/code/ObjectValue.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeValue.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ObjectReferenceImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ThreadReferenceImpl.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/InterpretedVFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/MonitorInfo.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaThread.java
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/stackValue.cpp
! src/share/vm/runtime/stackValue.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframe_hp.cpp

Changeset: c6386080541b
Author:    never
Date:      2009-06-10 12:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/c6386080541b

6849574: VM crash using NonBlockingHashMap (high_scale_lib)
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/6849574/Test.java

Changeset: 915cc9c5ebc6
Author:    kvn
Date:      2009-06-23 17:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/915cc9c5ebc6

6837094: False positive for "meet not symmetric" failure
Summary: Have the meet not symmetric check recursively do the interface-vs-oop check on array subtypes.
Reviewed-by: jrose
Contributed-by: rasbold at google.com

! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
+ test/compiler/6837094/Test.java

Changeset: d1fe2c2fbdac
Author:    twisti
Date:      2009-06-17 09:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/d1fe2c2fbdac

6851829: solaris build fails with 5.8 compilers
Summary: Solaris builds with the CC 5.8 compilers (used for jdk6 update builds) fail while compiling adlc.
Reviewed-by: never

! make/solaris/makefiles/adlc.make

Changeset: e306d7c7222c
Author:    twisti
Date:      2009-06-24 02:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/e306d7c7222c

Merge


Changeset: 14367225a853
Author:    kvn
Date:      2009-06-24 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/14367225a853

6841800: Incorrect boundary values behavior for option -XX:MaxLabelRootDepth=0-6 leads to jvm crash
Summary: MaxLabelRootDepth value less then 10 is invalid.
Reviewed-by: never

! src/share/vm/opto/matcher.cpp

Changeset: 18a08a7e16b5
Author:    twisti
Date:      2009-06-26 07:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/18a08a7e16b5

5057225: Remove useless I2L conversions
Summary: The optimizer should be told to normalize (AndL (ConvI2L x) 0xFF) to (ConvI2L (AndI x 0xFF)), and then the existing matcher rule will work for free.
Reviewed-by: kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/mulnode.cpp
+ test/compiler/5057225/Test5057225.java

Changeset: 8f5825e0aeaa
Author:    never
Date:      2009-06-26 13:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/8f5825e0aeaa

6818666: G1: Type lost in g1 pre-barrier
Reviewed-by: kvn

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp

Changeset: 3f06f139ef53
Author:    never
Date:      2009-06-26 16:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/3f06f139ef53

6851908: interpreter null check profiling broken causing extra compilation invalidation
Reviewed-by: kvn

! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp

Changeset: bf3489cc0aa0
Author:    never
Date:      2009-07-01 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/bf3489cc0aa0

6856025: assert(_base >= OopPtr && _base <= KlassPtr,"Not a Java pointer")
Reviewed-by: kvn

! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp

Changeset: b64314863098
Author:    kvn
Date:      2009-07-01 15:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/b64314863098

Merge


Changeset: 30b9b25b9cc1
Author:    tonyp
Date:      2009-06-24 11:42 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/30b9b25b9cc1

6850869: G1: RSet "scrubbing" scrubs too much
Summary: RSet scrubbing incorrectly deletes RSet entries that point to regions tagged as "continues humongous" due to a race when RSet scrubbing iterates over regions in parallel.
Reviewed-by: apetrusenko, iveresov

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: 00f7ec32f290
Author:    apetrusenko
Date:      2009-06-26 09:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/00f7ec32f290

6854027: Precompiled headers are not being updated in Linux/GCC builds
Summary: Fixes incorrect handling of precompiled headers in diff mode.
Reviewed-by: never, twisti

! src/share/tools/MakeDeps/Database.java

Changeset: 3eb9872b10ce
Author:    tonyp
Date:      2009-06-29 12:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/3eb9872b10ce

6855115: G1: Fix for 6850869 is incorrect
Summary: Missed updating two variable names when improving the code for 6850869.
Reviewed-by: iveresov, jmasa, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: e7d5557ad624
Author:    jmasa
Date:      2009-07-02 16:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/e7d5557ad624

Merge


Changeset: acba6af809c8
Author:    kvn
Date:      2009-07-01 20:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/acba6af809c8

6840775: Multiple JVM crashes seen with 1.6.0_10 through 1.6.0_14
Summary: Put missed reference to allocated array in copyOf() intrinsic into OopMap for the call slow_arraycopy().
Reviewed-by: never

! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java
! make/solaris/makefiles/optimized.make
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/library_call.cpp

Changeset: 0f2d888530e7
Author:    cfang
Date:      2009-07-02 16:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/0f2d888530e7

6855164: SIGSEGV during compilation of method involving loop over CharSequence.
Summary: Don not split a block if it contains a FastLockNode with a PhiNode input.
Reviewed-by: kvn, never

! src/share/vm/opto/loopopts.cpp

Changeset: 73dac61fe300
Author:    cfang
Date:      2009-07-06 12:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/73dac61fe300

6857707: Add missing test case for CR 6855164 from its bug description.
Summary: Add missing test case for CR 6855164 from its bug description.
Reviewed-by: never

+ test/compiler/6855164/Test.java

Changeset: 4325cdaa78ad
Author:    kvn
Date:      2009-07-06 15:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/4325cdaa78ad

6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class")
Summary: Move the secondary raw memory barrier to the correct place in generate_arraycopy().
Reviewed-by: never

! src/share/vm/opto/library_call.cpp

Changeset: f0bd02f95856
Author:    kvn
Date:      2009-07-07 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/f0bd02f95856

Merge


Changeset: 0316eac49d5a
Author:    tonyp
Date:      2009-07-07 14:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/0316eac49d5a

6855834: G1: minimize the output when -XX:+PrintHeapAtGC is set
Summary: Changing the behavior of -XX:+PrintHeapAtGC for G1 from printing lengthy, per-region information to instead printing a concise summary.
Reviewed-by: ysr, apetrusenko, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/runtime/globals.hpp

Changeset: bb18957ad21e
Author:    ysr
Date:      2009-07-10 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/bb18957ad21e

Merge


Changeset: 218f6b67f9c5
Author:    trims
Date:      2009-07-11 03:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/218f6b67f9c5

Merge


Changeset: ba313800759b
Author:    trims
Date:      2009-07-14 19:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/ba313800759b

Merge


Changeset: 57c71ad0341b
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/57c71ad0341b

Added tag jdk7-b65 for changeset ba313800759b

! .hgtags

Changeset: 96e4ccadd5f6
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/96e4ccadd5f6

Added tag jdk7-b66 for changeset 57c71ad0341b

! .hgtags



From yuri.nesterenko at sun.com  Mon Jul 27 14:06:56 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 14:06:56 +0000
Subject: <Swing Dev> hg: jdk7/swing/jaxp: 3 new changesets
Message-ID: <20090727140702.92675E879@hg.openjdk.java.net>

Changeset: 008c662e0ee9
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/008c662e0ee9

Added tag jdk7-b64 for changeset a10eec7a1edf

! .hgtags

Changeset: 22f9d5d5b5fe
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/22f9d5d5b5fe

Added tag jdk7-b65 for changeset 008c662e0ee9

! .hgtags

Changeset: f8f9c0186d87
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/f8f9c0186d87

Added tag jdk7-b66 for changeset 22f9d5d5b5fe

! .hgtags



From Alexander.Potochkin at Sun.COM  Mon Jul 27 14:01:30 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Mon, 27 Jul 2009 18:01:30 +0400
Subject: <Swing Dev> <AWT Dev> Review request: 6852592
 (revalidate()	must be smarter)
In-Reply-To: <4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
References: <4A5DF194.9000706@sun.com> <4A5DFBBA.5050404@sun.com>
	<4A5E012D.5070609@sun.com> <4A5E00C2.5090508@sun.com>
	<4A5E1693.2030204@sun.com>
	<4f9903f0907151214x434bbc98kf263fd7407330b65@mail.gmail.com>
Message-ID: <4A6DB33A.4030806@sun.com>

Hello Christopher

> Hi Anthony,
> 
>> One more concern that comes to my mind is that the logic stated in the
>> Swing's method specification is going to be implemented on the AWT's side,
>> which I don't like much. So definitely we need more opinions on this
>> proposal.
> 
> This may be a stupid idea, so disregard it if it is :)
> If the problem is having isValidateRoot() used by AWT code, why not promote:
> public/protected boolean isValidateRoot()
> to the Container class? It would obviously return false by default,
> but if custom code wants to play with it (which is anyway unlikely to
> happen) why not! After all, is there anything specially swingish with
> this method?

This is a great idea and I like it!

I have been working on JDK 6 recently
and just forget that we can introduce new methods for JDK 7
:-)

The new method will fix all the mess

alexp

> 
> Cheers,
> -Christopher



From yuri.nesterenko at sun.com  Mon Jul 27 14:13:00 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 14:13:00 +0000
Subject: <Swing Dev> hg: jdk7/swing/jaxws: 3 new changesets
Message-ID: <20090727141305.A4E98E882@hg.openjdk.java.net>

Changeset: aa22a1be5866
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/aa22a1be5866

Added tag jdk7-b64 for changeset aaa25dfd3de6

! .hgtags

Changeset: fa8712c099ed
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/fa8712c099ed

Added tag jdk7-b65 for changeset aa22a1be5866

! .hgtags

Changeset: 58f51e3cc0fa
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/58f51e3cc0fa

Added tag jdk7-b66 for changeset fa8712c099ed

! .hgtags



From yuri.nesterenko at sun.com  Mon Jul 27 14:20:20 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 14:20:20 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 34 new changesets
Message-ID: <20090727142740.7AAB6E888@hg.openjdk.java.net>

Changeset: 382a27aa78d3
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/382a27aa78d3

Added tag jdk7-b64 for changeset a50217eb3ee1

! .hgtags

Changeset: 6ec0174d4f36
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/6ec0174d4f36

Added tag jdk7-b65 for changeset 382a27aa78d3

! .hgtags

Changeset: b22f9e823be7
Author:    alanb
Date:      2009-06-30 11:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b22f9e823be7

6843003: Windows Server 2008 R2 system recognition
Reviewed-by: ohair, sherman

! src/windows/native/java/lang/java_props_md.c

Changeset: d57c10cf07c5
Author:    alanb
Date:      2009-06-30 11:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d57c10cf07c5

Merge


Changeset: c2baa2f0415e
Author:    xuelei
Date:      2009-07-03 11:13 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/c2baa2f0415e

6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check
Summary: allocate memory dynamically, keep reading until EOF.
Reviewed-by: weijun

! src/share/classes/sun/security/provider/certpath/OCSPChecker.java
! src/share/classes/sun/security/timestamp/HttpTimestamper.java

Changeset: 803db6c94a3b
Author:    martin
Date:      2009-07-03 07:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/803db6c94a3b

6857287: (file) Clarifications for symbolic link related javadoc
Summary: Fix up jsr203 file javadoc related to symbolic links
Reviewed-by: alanb

! src/share/classes/java/nio/file/LinkPermission.java
! src/share/classes/java/nio/file/NotLinkException.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/nio/file/attribute/Attributes.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java

Changeset: 75459b125461
Author:    tbell
Date:      2009-07-03 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/75459b125461

Merge


Changeset: fa488e4ff685
Author:    jccollet
Date:      2009-07-06 15:13 +0200
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fa488e4ff685

6856856: NPE in HTTP protocol handler logging
Summary: Fixed the NPE and Moved the java.util.logging dependency to a single class and used reflection to make it a soft one.
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpCapture.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 0cabe1192c8b
Author:    martin
Date:      2009-07-06 11:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0cabe1192c8b

6854795: Miscellaneous improvements to "jar"
Summary: cleanup of jar/Main.java (Initial patch by tobyr at google.com, additional review by jeremymanson at google.com, ulf.zibis at gmx.de)
Reviewed-by: sherman, alanb

! src/share/classes/sun/tools/jar/Main.java
! test/tools/jar/index/MetaInf.java

Changeset: 0a294c066e7a
Author:    darcy
Date:      2009-07-07 16:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0a294c066e7a

6857803: Missing links to exceptions in javadoc for Class.getGeneric{Superclass, Interfaces}
Reviewed-by: chegar

! src/share/classes/java/lang/Class.java

Changeset: 1175f872a968
Author:    weijun
Date:      2009-07-08 12:07 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1175f872a968

6857802: GSS getRemainingInitLifetime method returns milliseconds not seconds
Reviewed-by: xuelei

! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
+ test/sun/security/krb5/auto/LifeTimeInSeconds.java

Changeset: 1df67a3ecce8
Author:    weijun
Date:      2009-07-08 12:07 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1df67a3ecce8

6857795: krb5.conf ignored if system properties on realm and kdc are provided
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/Config.java
+ test/sun/security/krb5/ConfPlusProp.java
+ test/sun/security/krb5/confplusprop.conf
+ test/sun/security/krb5/confplusprop2.conf

Changeset: d133d4052378
Author:    ohair
Date:      2009-07-08 09:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d133d4052378

6858127: Missing -DNDEBUG on Linux and Windows native code compiles
Reviewed-by: tbell, dcubed

! make/common/Defs-linux.gmk
! make/common/Defs-windows.gmk

Changeset: d3a08f8c3c86
Author:    ohair
Date:      2009-07-08 09:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d3a08f8c3c86

6855551: java -Xrunhprof crashes when running with classes compiled with targed=7
Reviewed-by: tbell, dcubed

! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! test/demo/jvmti/hprof/HelloWorld.java
! test/demo/jvmti/hprof/StackMapTableTest.java

Changeset: ae60bb671e54
Author:    darcy
Date:      2009-07-09 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ae60bb671e54

6628737: Specification of wrapper class valueOf static factories should require caching
Reviewed-by: mr

! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java

Changeset: 6f26e2e5f4f3
Author:    xuelei
Date:      2009-07-10 17:27 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/6f26e2e5f4f3

6852744: PIT b61: PKI test suite fails because self signed certificates are beingrejected
Summary: make the builder aware of SKID/AKID, break the internal circular dependences
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
+ test/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
+ test/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
+ test/java/security/cert/CertPathBuilder/selfIssued/README
+ test/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
+ test/java/security/cert/CertPathBuilder/selfIssued/generate.sh
+ test/java/security/cert/CertPathBuilder/selfIssued/openssl.cnf

Changeset: 880896883a47
Author:    andrew
Date:      2009-07-11 16:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/880896883a47

6562614: Compiler warnings for gettimeofday in Inet4/Inet6AddressImpl.c
Summary: Add missing header to remove compiler warnings.
Reviewed-by: martin
Contributed-by: Matthew Flaschen <matthew.flaschen at gatech.edu>

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c

Changeset: d0ce095004b2
Author:    xuelei
Date:      2009-07-13 23:01 +0800
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d0ce095004b2

6453837: PartialCompositeContext.allEmpty is buggy
Reviewed-by: weijun

! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java

Changeset: beb5e5cad3ae
Author:    valeriep
Date:      2009-07-13 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/beb5e5cad3ae

6832540: IllegalArgumentException in ClassLoader.definePackage when classes are loaded in parallel
Summary: Modified to handle race condition for parallel-capable classloaders by re-trying/re-verifying package
Reviewed-by: alanb

! src/share/classes/java/net/URLClassLoader.java

Changeset: 53b27ac4f706
Author:    tbell
Date:      2009-07-13 23:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/53b27ac4f706

Merge

! make/common/Defs-windows.gmk

Changeset: 51ccb32e6d14
Author:    tbell
Date:      2009-07-16 18:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/51ccb32e6d14

Merge


Changeset: 043c7100a752
Author:    anthony
Date:      2009-07-07 17:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/043c7100a752

6853916: java.awt.Window.setBackground(null) throws NullPointerException
Summary: Window.setBackground() should check for null.
Reviewed-by: art, dcherepanov

! src/share/classes/java/awt/Window.java
+ test/java/awt/Window/SetBackgroundNPE/SetBackgroundNPE.java

Changeset: 99cdc0268e4b
Author:    dcherepanov
Date:      2009-07-09 15:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/99cdc0268e4b

6855323: Robot(GraphicsDevice) constructor initializes LEGAL_BUTTON_MASK variable improperly
Reviewed-by: art

! src/share/classes/java/awt/Robot.java
+ test/java/awt/Robot/CtorTest/CtorTest.java

Changeset: 9b1e640af25e
Author:    dcherepanov
Date:      2009-07-09 15:18 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9b1e640af25e

6759726: TrayIcon constructor throws NPE instead of documented IAE
Reviewed-by: art

! src/share/classes/java/awt/TrayIcon.java
+ test/java/awt/TrayIcon/CtorTest/CtorTest.java

Changeset: df34ec9f3e26
Author:    dcherepanov
Date:      2009-07-09 15:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/df34ec9f3e26

6847958: MouseWheel event is getting triggered for the disabled Textarea in jdk7 b60 pit build.
Reviewed-by: art

! src/solaris/classes/sun/awt/X11/XBaseWindow.java
+ test/java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java

Changeset: c27d7c1d1918
Author:    dcherepanov
Date:      2009-07-09 15:53 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/c27d7c1d1918

6847149: test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java fails
Reviewed-by: art

! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java

Changeset: 6d92ce5fe15b
Author:    yan
Date:      2009-07-12 23:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/6d92ce5fe15b

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: 4cd623432e7d
Author:    anthony
Date:      2009-07-14 14:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4cd623432e7d

6837446: Introduce Window.isOpaque() method
Reviewed-by: art, alexp

! src/share/classes/com/sun/awt/AWTUtilities.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/Window.java
! src/share/classes/javax/swing/DefaultDesktopManager.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/SunToolkit.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: fc869bc0cd63
Author:    yan
Date:      2009-07-14 22:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fc869bc0cd63

Merge


Changeset: c8da3750c7ca
Author:    yan
Date:      2009-07-14 22:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/c8da3750c7ca

Merge


Changeset: f88379effbcf
Author:    yan
Date:      2009-07-21 23:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f88379effbcf

Merge


Changeset: bd31b30a5b21
Author:    dcherepanov
Date:      2009-07-23 11:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/bd31b30a5b21

6857870: Regression tests are failing with ExceptionInInitializerError
Reviewed-by: art

! src/windows/classes/sun/awt/windows/WToolkit.java

Changeset: 11a8f0936228
Author:    xdono
Date:      2009-07-24 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/11a8f0936228

Added tag jdk7-b66 for changeset bd31b30a5b21

! .hgtags

Changeset: 80d076251250
Author:    yan
Date:      2009-07-27 03:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/80d076251250

Merge




From yuri.nesterenko at sun.com  Mon Jul 27 14:41:44 2009
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 27 Jul 2009 14:41:44 +0000
Subject: <Swing Dev> hg: jdk7/swing/langtools: 3 new changesets
Message-ID: <20090727144152.E0EEDE88D@hg.openjdk.java.net>

Changeset: 7e0056ded28c
Author:    xdono
Date:      2009-07-13 14:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/7e0056ded28c

Added tag jdk7-b64 for changeset d8f23a81d46f

! .hgtags

Changeset: 634f519d6f9a
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/634f519d6f9a

Added tag jdk7-b65 for changeset 7e0056ded28c

! .hgtags

Changeset: 0695e8ebae88
Author:    xdono
Date:      2009-07-24 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/0695e8ebae88

Added tag jdk7-b66 for changeset 634f519d6f9a

! .hgtags



From Alexander.Potochkin at Sun.COM  Mon Jul 27 16:41:35 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Mon, 27 Jul 2009 20:41:35 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
Message-ID: <4A6DD8BF.5040505@sun.com>

Hello Christopher

> Anthony,
> 
> I think I disagree with Applet returning true to isValidateRoot. If I
> am not mistaken, I think I saw some people placing an applet in their
> component hierarchy as if it was a normal component. Invalidation
> should propagate so that outer components can revalidate and thus have
> proper layout calculations. Thus I think the only AWT components that
> should return true are the ones with an outer parent (window class
> hierarchy).

It is actually not recommended to tread Applet as a normal component

The javadoc says:

  * An applet is a small program that is intended not to be run on
  * its own, but rather to be embedded inside another application.

I would expect some strange bugs in an application that uses JApplet
or Applet instead of general containers like JPanel

Swing code treats Applet like a topLevel component
which reflects in different places

see
SwingUtilities.convertPointToScreen():
SwingUtilities.getRoot(Component)
KeyboardManager.getTopAncestor()
PopupFactory.ContainerPopup.fitsOnScreen()

and so on...

RepaintManager.addInvalidComponent() also uses the same logic for 
Windows and Applets, please have a look at the method's implementation

By the way, when isValidateRoot() method will be brought up to 
Component, I expect the cast to be removed

if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot()))

But, when addInvalidComponent() finds no vaidateRoot,
it immediately returns, and this behavior will be affected

I see no strong reasons to make Windows and Applets to be validate 
roots, just because it won't give us any benefits and may break the 
existing code

Thanks
alexp

> 
> For the window method, shouldn't it be marked as final?
> 
> And what about the AWT ScrollPane? Shouldn't it return true as well?
> 
> Hope this helps,
> -Christopher
> 
> 
> On Thu, Jul 23, 2009 at 1:57 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
>> Hello Swing and AWT teams,
>>
>> So here's the latest version of the fix:
>>
>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/
>>
>> The specification has been modified, some stuff has been moved around.
>> Currently the spec is being reviewed by the CCC at Sun, and therefore is
>> kind of frozen. However, if anyone happen to find major problems with the
>> javadoc, please feel free to speak up.
>>
>> Suggestions for the code changes are still very welcome. Thank you in
>> advance!
>>
>> --
>> best regards,
>> Anthony
>>



From Anthony.Petrov at Sun.COM  Mon Jul 27 17:53:56 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 27 Jul 2009 21:53:56 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6DD8BF.5040505@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com>
Message-ID: <4A6DE9B4.1000203@sun.com>

Hi Alex,

On 7/27/2009 8:41 PM Alexander Potochkin wrote:
> By the way, when isValidateRoot() method will be brought up to 
> Component, I expect the cast to be removed
> 
> if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot()))

A component cannot be a validate root by logical reasons: it has nothing 
to lay out inside itselft, and therefore the state of 
validity/invalidity is not relevant to a component. Moreover, a 
component does not have children, thus it can't be a 'root' at all. 
Therefore I expect the isValidateRoot() method to stay in the Container 
class for quite a long time.

Regarding the mentioned condition, it needs to be changed as 
s/JComponent/Container/, and so needs to be changed the code around it 
to make sure the 'c' is used as a normal AWT container w/o any special 
treatment of it as an instance of the JComponent.


> But, when addInvalidComponent() finds no vaidateRoot,
> it immediately returns, and this behavior will be affected
> 
> I see no strong reasons to make Windows and Applets to be validate 
> roots, just because it won't give us any benefits and may break the 
> existing code

Besides, please consider a situation when one uses a few Swing 
components in an AWT application (which is rare, but not impossible). 
While this is not an 'officially supported' kind of mixing, I don't see 
reasons why it shouldn't generally work. Now suppose one of the Swing 
components is a popup (like a context menu, or a combo box, whatever). 
After displaying the popup, the Swing code is expected to call the 
revalidate() method which works perfectly in case of a Swing 
application. However, since AWT applications normally don't have 
validate roots, the addInvalidComponent() will fail to validate the 
hierarchy, and we may observe some weird stuff (we do in fact: see the 
bug 6862117). That's why I think it is OK to make the Window and the 
Applet classes validate roots. With the changes to the 
addInvalidComponent() described above, everything should work just fine.

Could you please elaborate on possible situations that could break after 
making the Window/Applet the validate root?

--
best regards,
Anthony


From Alexander.Potochkin at Sun.COM  Mon Jul 27 18:18:12 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Mon, 27 Jul 2009 22:18:12 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6DE9B4.1000203@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
Message-ID: <4A6DEF64.7060100@sun.com>

Hello Anthony

> Hi Alex,
> 
> On 7/27/2009 8:41 PM Alexander Potochkin wrote:
>> By the way, when isValidateRoot() method will be brought up to 
>> Component, I expect the cast to be removed
>>
>> if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot()))
> 
> A component cannot be a validate root by logical reasons: it has nothing 
> to lay out inside itselft, and therefore the state of 
> validity/invalidity is not relevant to a component. Moreover, a 
> component does not have children, thus it can't be a 'root' at all. 
> Therefore I expect the isValidateRoot() method to stay in the Container 
> class for quite a long time.

It is actually doesn't matter much

Component is the base class for the whole library
and it is ok for it to have some methods
that only make sense it its subclasses

Component.getBaseline() is a good example

It is so inconvenient to type

if ( (c instanceof JComponent) &&
(((JComponent) c).getBaseline()== somethinng))

so AWT team kindly agreed to brought this method up to the Component
even if it makes no sense for AWT components

isValidateRoot() should be checked from different places both on Swing 
and AWT sides, so it really make sense to add it to the Component class

> 
> Regarding the mentioned condition, it needs to be changed as 
> s/JComponent/Container/, and so needs to be changed the code around it 
> to make sure the 'c' is used as a normal AWT container w/o any special 
> treatment of it as an instance of the JComponent.
> 
> 
>> But, when addInvalidComponent() finds no vaidateRoot,
>> it immediately returns, and this behavior will be affected
>>
>> I see no strong reasons to make Windows and Applets to be validate 
>> roots, just because it won't give us any benefits and may break the 
>> existing code
> 
> Besides, please consider a situation when one uses a few Swing 
> components in an AWT application (which is rare, but not impossible). 
> While this is not an 'officially supported' kind of mixing, I don't see 
> reasons why it shouldn't generally work. Now suppose one of the Swing 
> components is a popup (like a context menu, or a combo box, whatever). 
> After displaying the popup, the Swing code is expected to call the 
> revalidate() method which works perfectly in case of a Swing 
> application. However, since AWT applications normally don't have 
> validate roots, the addInvalidComponent() will fail to validate the 
> hierarchy, and we may observe some weird stuff (we do in fact: see the 
> bug 6862117). That's why I think it is OK to make the Window and the 
> Applet classes validate roots. 
 > With the changes to the
 > addInvalidComponent() described above, everything should work just
 > fine.

Using Swing components in AWT applications is incorrect,
not supported and I doubt it will ever be

Here is the JComponent's javadoc:

  * To use a component that inherits from <code>JComponent</code>,
  * you must place the component in a containment hierarchy
  * whose root is a top-level Swing container.
  * Top-level Swing containers --
  * such as <code>JFrame</code>, <code>JDialog</code>,
  * and <code>JApplet</code> --

So the described scenario is not really relevant

> Could you please elaborate on possible situations that could break after 
> making the Window/Applet the validate root?
> 

Let me describe the "best fix"

1) Bring isValidateRoot() up to the Component class
2) Make it return false
3) Leave all other stuff intact

This proposal is 100% safe and does what we need

Would you agree?

Thanks
alexp

> -- 
> best regards,
> Anthony



From Anthony.Petrov at Sun.COM  Mon Jul 27 18:54:34 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 27 Jul 2009 22:54:34 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6DEF64.7060100@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com>
Message-ID: <4A6DF7EA.2020408@sun.com>

Hi Alex,

On 7/27/2009 10:18 PM Alexander Potochkin wrote:
>> Could you please elaborate on possible situations that could break 
>> after making the Window/Applet the validate root?
>>
> 
> Let me describe the "best fix"
> 
> 1) Bring isValidateRoot() up to the Component class
> 2) Make it return false
> 3) Leave all other stuff intact

The current fix does almost that with a few exceptions. Could you please 
describe at what exact cases promoting the isValidateRoot() to the 
Component instead of the Container might help? Any concrete existing 
methods/examples? Unfortunately I hardly see any, but maybe it's just me...

Also, I would still like to understand how making the Window/Applet 
class a validate root might harm, so I would kindly ask you to describe 
a hypothetical case, please.

--
best regards,
Anthony


From mark at magentatech.com.au  Tue Jul 28 07:44:55 2009
From: mark at magentatech.com.au (Mark Grantham)
Date: Tue, 28 Jul 2009 17:44:55 +1000
Subject: <Swing Dev> 4481516: RFE: JTable should have Excel's "Freeze Panes"
	feature
Message-ID: <4A6EAC77.5090207@magentatech.com.au>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090728/8515bade/attachment.html>

From sergey.malenkov at sun.com  Tue Jul 28 09:19:10 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Tue, 28 Jul 2009 09:19:10 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6864297: Right-to-left oriented
	JScrollPane is	aligned to the wrong direction while resizing
	the container
Message-ID: <20090728091941.971DCEA42@hg.openjdk.java.net>

Changeset: 0ab4157789d9
Author:    malenkov
Date:      2009-07-28 13:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0ab4157789d9

6864297: Right-to-left oriented JScrollPane is aligned to the wrong direction while resizing the container
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java
+ test/javax/swing/JScrollPane/Test6526631.java
+ test/javax/swing/SwingTest.java



From Anthony.Petrov at Sun.COM  Tue Jul 28 09:54:39 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 28 Jul 2009 13:54:39 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6DF7EA.2020408@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
Message-ID: <4A6ECADF.8050505@sun.com>

Hello Alex,

On 07/27/2009 10:54 PM, Anthony Petrov wrote:
>> 1) Bring isValidateRoot() up to the Component class
>> 2) Make it return false
>> 3) Leave all other stuff intact
> 
> The current fix does almost that with a few exceptions. Could you please 
> describe at what exact cases promoting the isValidateRoot() to the 
> Component instead of the Container might help? Any concrete existing 
> methods/examples? Unfortunately I hardly see any, but maybe it's just me...

On the second thought, as far as I can grep, I see that currently only 
RepaintManager.addInvalidComponent(JComponent) uses the isValidateRoot() 
method. So I assume you mean exactly this piece of code, please correct 
me if I'm wrong.

Let me please suggest a couple of possible solutions:

1. What about making the 'c' variable a Container instead of the 
Component at the first loop of the addInvalidComponent() method? Would 
it require promoting isValidateRoot() up to the Component afterwards? 
Obviously, no additional type casting or instanceof-checking is required 
after that change.

2. What about introducing a Component.getValidateRoot() method instead?

I would also like to mention that since you claim that 6862117 is not a 
bug, then there's actually no any known issue that would require any 
changes to the addInvalidComponent() right now - generally we don't have 
any "problem" at all.

Given that:

a) there's already at least three possible solutions to this issue,
b) the issue is not directly relevant to the aims of the RFE 6852592,
c) actually the issue is currently quite ephemeral,
d) the method isValidateRoot() does not seem belonging to the Component 
class logically for some developers,
e) the current solution is fully open to any further enhancements and 
does not bring any restrictions,

perhaps the discussion regarding further promoting of the method might 
be postponed till a later date.

Would you agree?

--
best regards,
Anthony


From Alexander.Potochkin at Sun.COM  Tue Jul 28 16:05:50 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Tue, 28 Jul 2009 20:05:50 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6DF7EA.2020408@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
Message-ID: <4A6F21DE.6070608@sun.com>

Hello Anthony

> Hi Alex,
> 
> On 7/27/2009 10:18 PM Alexander Potochkin wrote:
>>> Could you please elaborate on possible situations that could break 
>>> after making the Window/Applet the validate root?
>>>
>>
>> Let me describe the "best fix"
>>
>> 1) Bring isValidateRoot() up to the Component class
>> 2) Make it return false
>> 3) Leave all other stuff intact
> 
> The current fix does almost that with a few exceptions. Could you please 
> describe at what exact cases promoting the isValidateRoot() to the 
> Component instead of the Container might help? Any concrete existing 
> methods/examples? Unfortunately I hardly see any, but maybe it's just me...
> 
> Also, I would still like to understand how making the Window/Applet 
> class a validate root might harm, so I would kindly ask you to describe 
> a hypothetical case, please.

I believe that I already described one case

As you know the base type that Swing and AWT work with is java.awt.Component

see methods like getParent(), getComponent() etc...

The fix should eliminate the following messy code,
which can be found in JViewport and RepaintManager:

if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot()))

and turn in into

if (c.isValidateRoot())

I also think that, Component.isValidateRoot() will make the fix shorter 
on AWT side, since no casting to Container will be necessary

===

As for the second question about making Window/Applet validate roots,
I just don't see any practical benefits of this

Could you please give more details why it is worth doing?

Thanks
alexp

> 
> -- 
> best regards,
> Anthony



From Alexander.Potochkin at Sun.COM  Tue Jul 28 16:29:02 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Tue, 28 Jul 2009 20:29:02 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6ECADF.8050505@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com>
Message-ID: <4A6F274E.9060702@sun.com>

Hello Anthony

> Hello Alex,
> 
> On 07/27/2009 10:54 PM, Anthony Petrov wrote:
>>> 1) Bring isValidateRoot() up to the Component class
>>> 2) Make it return false
>>> 3) Leave all other stuff intact
>>
>> The current fix does almost that with a few exceptions. Could you 
>> please describe at what exact cases promoting the isValidateRoot() to 
>> the Component instead of the Container might help? Any concrete 
>> existing methods/examples? Unfortunately I hardly see any, but maybe 
>> it's just me...
> 
> On the second thought, as far as I can grep, I see that currently only 
> RepaintManager.addInvalidComponent(JComponent) uses the isValidateRoot() 
> method. So I assume you mean exactly this piece of code, please correct 
> me if I'm wrong.

That's right

You can also found the similar code in JViewport

> 
> Let me please suggest a couple of possible solutions:
> 
> 1. What about making the 'c' variable a Container instead of the 
> Component at the first loop of the addInvalidComponent() method? Would 
> it require promoting isValidateRoot() up to the Component afterwards? 
> Obviously, no additional type casting or instanceof-checking is required 
> after that change.

Hm, getParent() returns Container?!

You are right my friend, this eliminates my main argument about bringing 
this method to the Component

sorry for confusion
:-)

> 
> 2. What about introducing a Component.getValidateRoot() method instead?
> 

Now I am fine with Container.isValidateRoot()

> I would also like to mention that since you claim that 6862117 is not a 
> bug, then there's actually no any known issue that would require any 
> changes to the addInvalidComponent() right now - generally we don't have 
> any "problem" at all.

I didn't claim that 6862117 is not a bug

I actually said that using Swing components in AWT application is incorrect

a type of an application is defined by the type of the top level windows

AWT application:

awt.JFrame with awt.Button inside - OK
awt.JFrame with swing.JButton inside - not supported

Swing application:

swing.JFrame with swing.JButton - OK
swing.JFrame with awt.Button -
the AWT/Swing mixing case, is going to be supported in JDK7

Swing components need a top level RootContainer for various needs

In the test case for 6862117 I can see that Swing and AWT component
are placed inside JFrame, so this is a valid case

> 
> Given that:
> 
> a) there's already at least three possible solutions to this issue,
> b) the issue is not directly relevant to the aims of the RFE 6852592,
> c) actually the issue is currently quite ephemeral,
> d) the method isValidateRoot() does not seem belonging to the Component 
> class logically for some developers,
> e) the current solution is fully open to any further enhancements and 
> does not bring any restrictions,
> 
> perhaps the discussion regarding further promoting of the method might 
> be postponed till a later date.
> 
> Would you agree?

See my comments above

Thanks
alexp

> 
> -- 
> best regards,
> Anthony



From Anthony.Petrov at Sun.COM  Tue Jul 28 17:59:03 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 28 Jul 2009 21:59:03 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6F274E.9060702@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com> <4A6F274E.9060702@sun.com>
Message-ID: <4A6F3C67.80400@sun.com>

Hi Alex, Artem,

On 7/28/2009 8:05 PM Alexander Potochkin wrote:
> As for the second question about making Window/Applet validate roots,
> I just don't see any practical benefits of this
> 
> Could you please give more details why it is worth doing?

As to the Applet class, there's a valid justification: the user does not 
have a direct access to the underlying embedded frame which therefore 
might be left invalid forever. Please see [1] for the detailed description.

Regarding the Window: Artem proposed that at [2]. I didn't come up with 
any failing scenario, so I considered this change harmless and applied 
it. IMO, it isn't technically needed, but is conceptually correct. 
Perhaps Artem might comment on that?


On 7/28/2009 8:29 PM Alexander Potochkin wrote:
>> 1. What about making the 'c' variable a Container instead of the 
>> Component at the first loop of the addInvalidComponent() method? Would 
>> it require promoting isValidateRoot() up to the Component afterwards? 
>> Obviously, no additional type casting or instanceof-checking is 
>> required after that change.
> 
> Hm, getParent() returns Container?!
> Now I am fine with Container.isValidateRoot()

Great to hear that! Usually arguing gives birth to the truth. :)


>> I would also like to mention that since you claim that 6862117 is not 
>> a bug, then there's actually no any known issue that would require any 
>> changes to the addInvalidComponent() right now - generally we don't 
>> have any "problem" at all.
> 
> I didn't claim that 6862117 is not a bug
> I actually said that using Swing components in AWT application is incorrect
> Swing components need a top level RootContainer for various needs
> In the test case for 6862117 I can see that Swing and AWT component
> are placed inside JFrame, so this is a valid case

I guess I got the point. Just my example was sort of wrong. Thanks for 
clarifying that.


[1] http://mail.openjdk.java.net/pipermail/awt-dev/2009-July/000778.html

[2] http://mail.openjdk.java.net/pipermail/awt-dev/2009-July/000765.html

--
best regards,
Anthony


From Alexander.Potochkin at Sun.COM  Tue Jul 28 18:31:15 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Tue, 28 Jul 2009 22:31:15 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6F3C67.80400@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com> <4A6F274E.9060702@sun.com>
	<4A6F3C67.80400@sun.com>
Message-ID: <4A6F43F3.6080607@sun.com>

Hello Anthony

> Hi Alex, Artem,
> 
> On 7/28/2009 8:05 PM Alexander Potochkin wrote:
>> As for the second question about making Window/Applet validate roots,
>> I just don't see any practical benefits of this
>>
>> Could you please give more details why it is worth doing?
> 
> As to the Applet class, there's a valid justification: the user does not 
> have a direct access to the underlying embedded frame which therefore 
> might be left invalid forever. Please see [1] for the detailed description.

If you absolutely need at least one validate root in the hierarchy,
and know how to correctly rewrite the messy code in RepaintManager and 
JViewport, I am fine with that

;-)

> 
> Regarding the Window: Artem proposed that at [2]. I didn't come up with 
> any failing scenario, so I considered this change harmless and applied 
> it. IMO, it isn't technically needed, but is conceptually correct. 
> Perhaps Artem might comment on that?
> 
> 
> On 7/28/2009 8:29 PM Alexander Potochkin wrote:
>>> 1. What about making the 'c' variable a Container instead of the 
>>> Component at the first loop of the addInvalidComponent() method? 
>>> Would it require promoting isValidateRoot() up to the Component 
>>> afterwards? Obviously, no additional type casting or 
>>> instanceof-checking is required after that change.
>>
>> Hm, getParent() returns Container?!
>> Now I am fine with Container.isValidateRoot()
> 
> Great to hear that! Usually arguing gives birth to the truth. :)
> 

Exactly so!

> 
>>> I would also like to mention that since you claim that 6862117 is not 
>>> a bug, then there's actually no any known issue that would require 
>>> any changes to the addInvalidComponent() right now - generally we 
>>> don't have any "problem" at all.
>>
>> I didn't claim that 6862117 is not a bug
>> I actually said that using Swing components in AWT application is 
>> incorrect
>> Swing components need a top level RootContainer for various needs
>> In the test case for 6862117 I can see that Swing and AWT component
>> are placed inside JFrame, so this is a valid case
> 
> I guess I got the point. Just my example was sort of wrong. Thanks for 
> clarifying that.
> 

You are welcome

It is gonna be a good fix
alexp

> 
> [1] http://mail.openjdk.java.net/pipermail/awt-dev/2009-July/000778.html
> 
> [2] http://mail.openjdk.java.net/pipermail/awt-dev/2009-July/000765.html
> 
> -- 
> best regards,
> Anthony



From Anthony.Petrov at Sun.COM  Wed Jul 29 09:56:11 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 29 Jul 2009 13:56:11 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A6F43F3.6080607@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com> <4A6F274E.9060702@sun.com>
	<4A6F3C67.80400@sun.com> <4A6F43F3.6080607@sun.com>
Message-ID: <4A701CBB.3010403@sun.com>

Hi Alex,

On 07/28/2009 10:31 PM, Alexander Potochkin wrote:
>>> As for the second question about making Window/Applet validate roots,
>>> I just don't see any practical benefits of this
>>>
>>> Could you please give more details why it is worth doing?
>>
>> As to the Applet class, there's a valid justification: the user does 
>> not have a direct access to the underlying embedded frame which 
>> therefore might be left invalid forever. Please see [1] for the 
>> detailed description.
> 
> If you absolutely need at least one validate root in the hierarchy,

This is not required. The requirement is to keep the whole hierarchy 
valid. We can achieve that either using validate roots or calling 
validate() on the top-level component. Since applets do not have 
"official" access to/knowledge about their top-level component (the 
embedded frame), we have to workaround that making the Applet a validate 
root.


> and know how to correctly rewrite the messy code in RepaintManager and 
> JViewport, I am fine with that

Hm, what kind of code might work wrong in that classes when the Window 
and the Applet become validate roots? I don't see anything suspicious 
there. In the mentioned snippets looking for a top-level component is 
only used to verify that the whole hierarchy is contained within a 
top-level. Since the search starts exactly from the previously found 
validate root, the code must work perfectly even if there's no validate 
roots between a component and the top-level (i.e. when there's no a 
RootPane at least, which is unlikely for a Swing top-level, ain't it?) 
But as I said, even in that fantastic case everything seems to work OK.


>> Regarding the Window: Artem proposed that at [2]. I didn't come up 
>> with any failing scenario, so I considered this change harmless and 
>> applied it. IMO, it isn't technically needed, but is conceptually 
>> correct. Perhaps Artem might comment on that?

And here comes the technical justification to make the Window a validate 
root. A component in a hierarchy can have two kinds of ancestors: a 
container and an owner. The first one is the physical container as seen 
on the screen (say, a Panel that a Button lays on). The latter is a 
component that is kind of responsible for and/or dependent on the owned 
component (like when the owned component must block its owner in some 
cases, for instance). A perfect example is an owned modal Dialog. Dialog 
does not have a container ancestor, but may indeed have an owner.

Unfortunately the API in AWT does not make any difference between these 
kinds of ancestor: the Component.getParent() is used for both. And 
unfortunately we can't change that now due to backward-compatibility 
issues (that's why it is very important to architect APIs carefully from 
the start.)

That said, the invalidate() method may easily jump to the owner of a 
dialog (or a window) while invalidating the hierarchy of the owned 
window - which is absolutely incorrect. To make sure this never happens, 
we need to stop invalidating on top-level components, hence the need to 
make the Window a validate root.

Sounds reasonable?

--
best regards,
Anthony


From Alexander.Potochkin at Sun.COM  Wed Jul 29 15:59:33 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 29 Jul 2009 19:59:33 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A701CBB.3010403@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com> <4A6F274E.9060702@sun.com>
	<4A6F3C67.80400@sun.com>
	<4A6F43F3.6080607@sun.com> <4A701CBB.3010403@sun.com>
Message-ID: <4A7071E5.3000402@sun.com>

Hello Anthony

> 
> On 07/28/2009 10:31 PM, Alexander Potochkin wrote:
>>>> As for the second question about making Window/Applet validate roots,
>>>> I just don't see any practical benefits of this
>>>>
>>>> Could you please give more details why it is worth doing?
>>>
>>> As to the Applet class, there's a valid justification: the user does 
>>> not have a direct access to the underlying embedded frame which 
>>> therefore might be left invalid forever. Please see [1] for the 
>>> detailed description.
>>
>> If you absolutely need at least one validate root in the hierarchy,
> 
> This is not required. The requirement is to keep the whole hierarchy 
> valid. We can achieve that either using validate roots or calling 
> validate() on the top-level component. Since applets do not have 
> "official" access to/knowledge about their top-level component (the 
> embedded frame), we have to workaround that making the Applet a validate 
> root.
> 
> 
>> and know how to correctly rewrite the messy code in RepaintManager and 
>> JViewport, I am fine with that
> 
> Hm, what kind of code might work wrong in that classes when the Window 
> and the Applet become validate roots? I don't see anything suspicious 
> there. In the mentioned snippets looking for a top-level component is 
> only used to verify that the whole hierarchy is contained within a 
> top-level. Since the search starts exactly from the previously found 
> validate root, the code must work perfectly even if there's no validate 
> roots between a component and the top-level (i.e. when there's no a 
> RootPane at least, which is unlikely for a Swing top-level, ain't it?) 
> But as I said, even in that fantastic case everything seems to work OK.

Here is the current code in RM:

    for(Component c = invalidComponent; c != null; c = c.getParent()) {
    if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot())) {
		validateRoot = c;
		break;
	    }
	}

I'd like to have it rewritten like this:

    for(Container c = invalidComponent; c != null; c = c.getParent()) {
    if (c.isValidateRoot()) {
		validateRoot = c;
		break;
	    }
	}

The next statement is:

	/* There's no validateRoot to apply validate to, so we're done.
	 */
	if (validateRoot == null) {
	    return;
	}


So the code is ready to the situation when there is no validate root

If you make Window a validate root,
the for loop will always find it and the logic will be changed

This is something to keep in mind

> 
>>> Regarding the Window: Artem proposed that at [2]. I didn't come up 
>>> with any failing scenario, so I considered this change harmless and 
>>> applied it. IMO, it isn't technically needed, but is conceptually 
>>> correct. Perhaps Artem might comment on that?
> 
> And here comes the technical justification to make the Window a validate 
> root. A component in a hierarchy can have two kinds of ancestors: a 
> container and an owner. The first one is the physical container as seen 
> on the screen (say, a Panel that a Button lays on). The latter is a 
> component that is kind of responsible for and/or dependent on the owned 
> component (like when the owned component must block its owner in some 
> cases, for instance). A perfect example is an owned modal Dialog. Dialog 
> does not have a container ancestor, but may indeed have an owner.
> 
> Unfortunately the API in AWT does not make any difference between these 
> kinds of ancestor: the Component.getParent() is used for both. And 
> unfortunately we can't change that now due to backward-compatibility 
> issues (that's why it is very important to architect APIs carefully from 
> the start.)

You mean that dialog.getParent() returns the dialog's owner?

Indeed... what a mess!

> 
> That said, the invalidate() method may easily jump to the owner of a 
> dialog (or a window) while invalidating the hierarchy of the owned 
> window - which is absolutely incorrect. To make sure this never happens, 
> we need to stop invalidating on top-level components, hence the need to 
> make the Window a validate root.
> 
> Sounds reasonable?

Yep

alexp

> 
> -- 
> best regards,
> Anthony



From langel at redhat.com  Wed Jul 29 16:34:52 2009
From: langel at redhat.com (Lillian Angel)
Date: Wed, 29 Jul 2009 12:34:52 -0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A5DCA38.2010207@redhat.com>
References: <4A37BE1F.4030300@redhat.com>	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>	<4A3BE58F.70608@redhat.com>	<4A423DF0.8050401@redhat.com>	<4A521C90.6030806@redhat.com>	<4A574AF4.2020207@redhat.com>	<4A574C8C.3010703@Sun.COM>	<4A574D07.50606@redhat.com>
	<4A5DCA38.2010207@redhat.com>
Message-ID: <4A707A2C.5040300@redhat.com>

Lillian Angel wrote:
> Lillian Angel wrote:
>> Sergey Groznyh wrote:
>>>>>>>> Lillian Angel wrote:
>>>>>>>>             
>>>
>>>  
>>>>>> Can someone please review this?         
>>>>> I have updated the patch, can someone please review it again?       
>>>
>>> Sorry Lillian, I was on vacation. Will get to your fix soon.
>>
>>
>> No problem :) Thanks
>
>
> I posted another updated patch for review.

Can someone please review this:
https://bugs.openjdk.java.net/show_bug.cgi?id=100073


Cheers


From gnu_andrew at member.fsf.org  Wed Jul 29 16:59:18 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 29 Jul 2009 17:59:18 +0100
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A707A2C.5040300@redhat.com>
References: <4A37BE1F.4030300@redhat.com>
	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>
	<4A3BE58F.70608@redhat.com> <4A423DF0.8050401@redhat.com>
	<4A521C90.6030806@redhat.com> <4A574AF4.2020207@redhat.com>
	<4A574C8C.3010703@Sun.COM> <4A574D07.50606@redhat.com>
	<4A5DCA38.2010207@redhat.com> <4A707A2C.5040300@redhat.com>
Message-ID: <17c6771e0907290959g476052cbt615df06ea07c971d@mail.gmail.com>

2009/7/29 Lillian Angel <langel at redhat.com>:
> Lillian Angel wrote:
>>
>> Lillian Angel wrote:
>>>
>>> Sergey Groznyh wrote:
>>>>>>>>>
>>>>>>>>> Lillian Angel wrote:
>>>>>>>>>
>>>>
>>>>
>>>>>>>
>>>>>>> Can someone please review this?
>>>>>>
>>>>>> I have updated the patch, can someone please review it again?
>>>>
>>>> Sorry Lillian, I was on vacation. Will get to your fix soon.
>>>
>>>
>>> No problem :) Thanks
>>
>>
>> I posted another updated patch for review.
>
> Can someone please review this:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100073
>
>
> Cheers
>

Please?
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Anthony.Petrov at Sun.COM  Wed Jul 29 18:03:49 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 29 Jul 2009 22:03:49 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A7071E5.3000402@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com> <4A6F274E.9060702@sun.com>
	<4A6F3C67.80400@sun.com>
	<4A6F43F3.6080607@sun.com> <4A701CBB.3010403@sun.com>
	<4A7071E5.3000402@sun.com>
Message-ID: <4A708F05.5050701@sun.com>

On 7/29/2009 7:59 PM Alexander Potochkin wrote:
>> Hm, what kind of code might work wrong in that classes when the Window 
>> and the Applet become validate roots? I don't see anything suspicious 
>> there. In the mentioned snippets looking for a top-level component is 
>> only used to verify that the whole hierarchy is contained within a 
>> top-level. Since the search starts exactly from the previously found 
>> validate root, the code must work perfectly even if there's no 
>> validate roots between a component and the top-level (i.e. when 
>> there's no a RootPane at least, which is unlikely for a Swing 
>> top-level, ain't it?) But as I said, even in that fantastic case 
>> everything seems to work OK.
> 
> Here is the current code in RM:
> 
>    for(Component c = invalidComponent; c != null; c = c.getParent()) {
>    if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot())) {
>         validateRoot = c;
>         break;
>         }
>     }
> 
> I'd like to have it rewritten like this:
> 
>    for(Container c = invalidComponent; c != null; c = c.getParent()) {
>    if (c.isValidateRoot()) {
>         validateRoot = c;
>         break;
>         }
>     }
> 
> The next statement is:
> 
>     /* There's no validateRoot to apply validate to, so we're done.
>      */
>     if (validateRoot == null) {
>         return;
>     }
> 
> 
> So the code is ready to the situation when there is no validate root
> 
> If you make Window a validate root,
> the for loop will always find it and the logic will be changed

Yes! And that seems to be completely correct: we HAVE TO call validate() 
on a validate root (or a top-level component - whichever we find) - no 
matter what is the component that represents the found validate root - 
an old-good Swing RootPane, or the top-level window. So, whichever we 
find - we just schedule the invocation of the validate() method on that 
component, and therefore make the hw/lw mixing-related code happy. :)


> This is something to keep in mind

So I think the current code (including the rewritten version as you 
suggest) perfectly fits to the idea of making top-level windows validate 
roots.


>> Unfortunately the API in AWT does not make any difference between 
>> these kinds of ancestor: the Component.getParent() is used for both. 
>> And unfortunately we can't change that now due to 
>> backward-compatibility issues (that's why it is very important to 
>> architect APIs carefully from the start.)
> 
> You mean that dialog.getParent() returns the dialog's owner?
> 
> Indeed... what a mess!

A sad legacy...


>> That said, the invalidate() method may easily jump to the owner of a 
>> dialog (or a window) while invalidating the hierarchy of the owned 
>> window - which is absolutely incorrect. To make sure this never 
>> happens, we need to stop invalidating on top-level components, hence 
>> the need to make the Window a validate root.
>>
>> Sounds reasonable?
> 
> Yep

Great! And thanks for reviewing the code! By the way, are you proposing 
to apply the suggested chunk of code to the RepaintManager with this 
fix, or is it going to be a separate CR?

--
best regards,
Anthony


From Sergey.Groznyh at Sun.COM  Wed Jul 29 19:22:33 2009
From: Sergey.Groznyh at Sun.COM (Sergey Groznyh)
Date: Wed, 29 Jul 2009 23:22:33 +0400
Subject: <Swing Dev> Word wrap broken in JTextArea
In-Reply-To: <4A707A2C.5040300@redhat.com>
References: <4A37BE1F.4030300@redhat.com>
	<17c6771e0906170839k3ca998a3tcbc93eaebd882f96@mail.gmail.com>
	<4A3BE58F.70608@redhat.com> <4A423DF0.8050401@redhat.com>
	<4A521C90.6030806@redhat.com> <4A574AF4.2020207@redhat.com>
	<4A574C8C.3010703@Sun.COM> <4A574D07.50606@redhat.com>
	<4A5DCA38.2010207@redhat.com> <4A707A2C.5040300@redhat.com>
Message-ID: <4A70A179.4000700@Sun.COM>

Hi,

just returned from a vacation, will review the fix soon.

Thanks,
Sergey


Lillian Angel wrote:
> Lillian Angel wrote:
>   
>> Lillian Angel wrote:
>>     
>>> Sergey Groznyh wrote:
>>>       
>>>>>>>>> Lillian Angel wrote:
>>>>>>>>>             
>>>>>>>>>                   
>>>>  
>>>>         
>>>>>>> Can someone please review this?         
>>>>>>>               
>>>>>> I have updated the patch, can someone please review it again?       
>>>>>>             
>>>> Sorry Lillian, I was on vacation. Will get to your fix soon.
>>>>         
>>> No problem :) Thanks
>>>       
>> I posted another updated patch for review.
>>     
>
> Can someone please review this:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100073
>
>
> Cheers
>   



From yuka.kamiya at sun.com  Thu Jul 30 06:01:28 2009
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Thu, 30 Jul 2009 06:01:28 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6866243: Javadoc for
	java.lang.Character still	refers to Unicode 4 instead of 5
Message-ID: <20090730060159.40861EC00@hg.openjdk.java.net>

Changeset: 4c6a5ea563ba
Author:    peytoia
Date:      2009-07-30 14:45 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/4c6a5ea563ba

6866243: Javadoc for java.lang.Character still refers to Unicode 4 instead of 5
Reviewed-by: okutsu

! src/share/classes/java/lang/Character.java



From Anthony.Petrov at Sun.COM  Thu Jul 30 11:33:24 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 30 Jul 2009 15:33:24 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4A6879AE.4080407@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com>
Message-ID: <4A718504.6000507@sun.com>

On 07/23/2009 06:54 PM, Artem Ananiev wrote:
> This looks like a good idea.
>> And what about the AWT ScrollPane? Shouldn't it return true as well?
> 
> As well as this one.

Legacy AWT applications are supposed to invoke the validate() method on 
the top-level component. After the proposed change the invalidate() will 
stop invalidation on the scroll pane, making the subsequent validate() 
call a no-op because the top-level component will remain valid.

Not only is the change backward-incompatible, but it also tends to leave 
parts of the component hierarchy invalid. That wasn't important before, 
but is important now (and that is the aim of this particular fix, by the 
way.)

Since:

a) almost nobody develops pure AWT applications our days, thus making 
this change unimportant,
b) this change breaks backward compatibility with existing applications,

I'm against making the AWT ScrollPane a validate root. Please provide 
more justification if you strongly feel it is required.

--
best regards,
Anthony

>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/


From Alexander.Potochkin at Sun.COM  Thu Jul 30 12:29:13 2009
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Thu, 30 Jul 2009 16:29:13 +0400
Subject: <Swing Dev> Review request #3: 6852592 (revalidate() must be
 smarter)
In-Reply-To: <4A708F05.5050701@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6DD8BF.5040505@sun.com> <4A6DE9B4.1000203@sun.com>
	<4A6DEF64.7060100@sun.com> <4A6DF7EA.2020408@sun.com>
	<4A6ECADF.8050505@sun.com> <4A6F274E.9060702@sun.com>
	<4A6F3C67.80400@sun.com>
	<4A6F43F3.6080607@sun.com> <4A701CBB.3010403@sun.com>
	<4A7071E5.3000402@sun.com> <4A708F05.5050701@sun.com>
Message-ID: <4A719219.1020106@sun.com>

Hello Anthony

>>
>> So the code is ready to the situation when there is no validate root
>>
>> If you make Window a validate root,
>> the for loop will always find it and the logic will be changed
> 
> Yes! And that seems to be completely correct: we HAVE TO call validate() 
> on a validate root (or a top-level component - whichever we find) - no 
> matter what is the component that represents the found validate root - 
> an old-good Swing RootPane, or the top-level window. So, whichever we 
> find - we just schedule the invocation of the validate() method on that 
> component, and therefore make the hw/lw mixing-related code happy. :)

Ok

> 
> 
>> This is something to keep in mind
> 
> So I think the current code (including the rewritten version as you 
> suggest) perfectly fits to the idea of making top-level windows validate 
> roots.
> 
> 

> 
>>> That said, the invalidate() method may easily jump to the owner of a 
>>> dialog (or a window) while invalidating the hierarchy of the owned 
>>> window - which is absolutely incorrect. To make sure this never 
>>> happens, we need to stop invalidating on top-level components, hence 
>>> the need to make the Window a validate root.
>>>
>>> Sounds reasonable?
>>
>> Yep
> 
> Great! And thanks for reviewing the code! By the way, are you proposing 
> to apply the suggested chunk of code to the RepaintManager with this 
> fix, or is it going to be a separate CR?

I tend to not file extra CR's,
could you please take care of it with this fix?

RM.addInvalidComponent() and JViewport.validateView()
are only methods to be updated

Thanks!
alexp

> 
> -- 
> best regards,
> Anthony



From Artem.Ananiev at Sun.COM  Fri Jul 31 10:19:03 2009
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Fri, 31 Jul 2009 14:19:03 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4A718504.6000507@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com> <4A718504.6000507@sun.com>
Message-ID: <4A72C517.2050409@sun.com>


Anthony Petrov wrote:
> On 07/23/2009 06:54 PM, Artem Ananiev wrote:
>> This looks like a good idea.
>>> And what about the AWT ScrollPane? Shouldn't it return true as well?
>>
>> As well as this one.
> 
> Legacy AWT applications are supposed to invoke the validate() method on 
> the top-level component. After the proposed change the invalidate() will 
> stop invalidation on the scroll pane, making the subsequent validate() 
> call a no-op because the top-level component will remain valid.
> 
> Not only is the change backward-incompatible, but it also tends to leave 
> parts of the component hierarchy invalid. That wasn't important before, 
> but is important now (and that is the aim of this particular fix, by the 
> way.)
> 
> Since:
> 
> a) almost nobody develops pure AWT applications our days, thus making 
> this change unimportant,
> b) this change breaks backward compatibility with existing applications,
> 
> I'm against making the AWT ScrollPane a validate root. Please provide 
> more justification if you strongly feel it is required.

HW/LW mixing has already introduced some backwards incompatibility into 
our code - this is why this discussion appeared. Making SctollPane a 
validate root is at least consistent with the rest of the code (AWT and 
Swing).

Thanks,

Artem

> -- 
> best regards,
> Anthony
> 
>>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/


From chrriis at gmail.com  Fri Jul 31 10:29:59 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Fri, 31 Jul 2009 12:29:59 +0200
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A72C517.2050409@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com> <4A718504.6000507@sun.com>
	<4A72C517.2050409@sun.com>
Message-ID: <4f9903f0907310329w7c8567ckf0953efc90ec8899@mail.gmail.com>

Hi all,

I may be thinking out loud... but talking about incompatibilities:
In a situation where a container has a JScrollPane with a JComponent
somewhere down its hierarchy,
component.invalidate();
container.validate();
// Use some layout related values immediately

... would not have any effect anymore. Under some certain
circumstances, revalidate is not used because of the fact that the
call is deferred. Maybe for those extreme cases it is desirable to
introduce a method:
public Container getValidateRoot()
That method would never return null unless the component is not
connected to a hierarchy leading to an applet or window. The code
above could be converted to:
component.invalidate();
component.getValidateRoot().validate();

Cheers,
-Christopher


From Anthony.Petrov at Sun.COM  Fri Jul 31 10:30:19 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 31 Jul 2009 14:30:19 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4A72C517.2050409@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com> <4A718504.6000507@sun.com>
	<4A72C517.2050409@sun.com>
Message-ID: <4A72C7BB.3050708@sun.com>

On 07/31/2009 02:19 PM, Artem Ananiev wrote:
>> Legacy AWT applications are supposed to invoke the validate() method 
>> on the top-level component. After the proposed change the invalidate() 
>> will stop invalidation on the scroll pane, making the subsequent 
>> validate() call a no-op because the top-level component will remain 
>> valid.
>>
>> Not only is the change backward-incompatible, but it also tends to 
>> leave parts of the component hierarchy invalid. That wasn't important 
>> before, but is important now (and that is the aim of this particular 
>> fix, by the way.)
>>
>> Since:
>>
>> a) almost nobody develops pure AWT applications our days, thus making 
>> this change unimportant,
>> b) this change breaks backward compatibility with existing applications,
>>
>> I'm against making the AWT ScrollPane a validate root. Please provide 
>> more justification if you strongly feel it is required.
> 
> HW/LW mixing has already introduced some backwards incompatibility into 
> our code - this is why this discussion appeared. Making SctollPane a 

To me, the fact that we already managed to break something does not 
imply a permission to go further and ruin as much as we can.


> validate root is at least consistent with the rest of the code (AWT and 
> Swing).

It's been ages since the Swing ScrollPane became a validate root. The 
question is: does anyone needs/wants to use AWT ScrollPanes in new 
applications now? If the answer is 'no', I would like to not break 
existing applications.

--
best regards,
Anthony


From Anthony.Petrov at Sun.COM  Fri Jul 31 10:42:06 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 31 Jul 2009 14:42:06 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4f9903f0907310329w7c8567ckf0953efc90ec8899@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com> <4A718504.6000507@sun.com>
	<4A72C517.2050409@sun.com>
	<4f9903f0907310329w7c8567ckf0953efc90ec8899@mail.gmail.com>
Message-ID: <4A72CA7E.6080609@sun.com>

On 07/31/2009 02:29 PM, Christopher Deckers wrote:
> I may be thinking out loud... but talking about incompatibilities:
> In a situation where a container has a JScrollPane with a JComponent
> somewhere down its hierarchy,
> component.invalidate();
> container.validate();
> // Use some layout related values immediately
> 
> ... would not have any effect anymore. Under some certain
> circumstances, revalidate is not used because of the fact that the
> call is deferred. Maybe for those extreme cases it is desirable to
> introduce a method:
> public Container getValidateRoot()
> That method would never return null unless the component is not
> connected to a hierarchy leading to an applet or window. The code
> above could be converted to:
> component.invalidate();
> component.getValidateRoot().validate();

I'm not an expert in Swing, but AFAIK the paradigm used in Swing is 
calling the revalidate() method rather than making direct calls to the 
validate(). I guess Swing team might provide more details on why it is 
more correct.

Anyway, why immediate validation might be needed?

--
best regards,
Anthony


From Anthony.Petrov at Sun.COM  Fri Jul 31 11:57:05 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 31 Jul 2009 15:57:05 +0400
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
 must be smarter)
In-Reply-To: <4f9903f0907310329w7c8567ckf0953efc90ec8899@mail.gmail.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com> <4A718504.6000507@sun.com>
	<4A72C517.2050409@sun.com>
	<4f9903f0907310329w7c8567ckf0953efc90ec8899@mail.gmail.com>
Message-ID: <4A72DC11.3090509@sun.com>

Hi Chris,

On 07/31/2009 02:29 PM, Christopher Deckers wrote:
> public Container getValidateRoot()
> That method would never return null unless the component is not
> connected to a hierarchy leading to an applet or window. The code

By the way, generally I agree that such method would be useful in the 
Component class, however I would like to avoid re-spinning the API 
approval request that is currently being processed. Perhaps we could add 
the method later under a separate CR.

Also we're going to introduce the package-private method

Container javax.swing.SwingUtilities.getValidateRoot(Container);

with this fix. But this method is going to treat CellRendererPane quite 
specially - please refer to the 
RepaintManager.addInvalidComponent()/JViewport.validateView() methods 
for details. We discussed the issue with the Swing team yesterday and 
came to a conclusion that we are not yet ready to make the 
CellRendererPane a validate root. We could probably rework this later 
with the separate CR as well.

--
best regards,
Anthony


From sergey.malenkov at sun.com  Fri Jul 31 12:51:19 2009
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Fri, 31 Jul 2009 12:51:19 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6865565: Test
	failed:	/test/closed/javax/swing/JInternalFrame/6325652/bug6325652.java
Message-ID: <20090731125146.76334EE1D@hg.openjdk.java.net>

Changeset: 389cecd0ca18
Author:    malenkov
Date:      2009-07-31 16:27 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/389cecd0ca18

6865565: Test failed: /test/closed/javax/swing/JInternalFrame/6325652/bug6325652.java
Reviewed-by: peterz

+ test/javax/swing/JInternalFrame/Test6325652.java
! test/javax/swing/JInternalFrame/Test6505027.java
! test/javax/swing/JInternalFrame/Test6802868.java
! test/javax/swing/JScrollPane/Test6526631.java
! test/javax/swing/SwingTest.java



From chrriis at gmail.com  Fri Jul 31 12:59:54 2009
From: chrriis at gmail.com (Christopher Deckers)
Date: Fri, 31 Jul 2009 14:59:54 +0200
Subject: <Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate()
	must be smarter)
In-Reply-To: <4A72CA7E.6080609@sun.com>
References: <4A685013.7080807@sun.com>
	<4f9903f0907230706r764a75d4t40f8354dd3d915b3@mail.gmail.com>
	<4A6879AE.4080407@sun.com> <4A718504.6000507@sun.com>
	<4A72C517.2050409@sun.com>
	<4f9903f0907310329w7c8567ckf0953efc90ec8899@mail.gmail.com>
	<4A72CA7E.6080609@sun.com>
Message-ID: <4f9903f0907310559l7c7e5f30j8e7ca483a0f65deb@mail.gmail.com>

> I'm not an expert in Swing, but AFAIK the paradigm used in Swing is calling
> the revalidate() method rather than making direct calls to the validate().

If only all Swing developers knew the Swing paradigm. Also, if Swing
did not expose invalidate() and validate() they would probably not end
up being used by Swing developers. The fact is: some developers do it.

> Anyway, why immediate validation might be needed?

Apart from API misuse, there are certain cases where validating serves
as a hack where deeper refactoring is not possible. I just wanted to
stress that the change we are discussing could break some apps, and
having a getValidateRoot() method would help them move their code to a
working version.

I used validation in a Swing app myself a few days ago where a long
running action is taking place on the EDT (!) but the component
hierarchy was wrongly displayed. I had to perform some validations and
explicit sizing depending on some preferred sizes to adjust the UI
before it blocks. Not validating would end up freezing the UI in a way
that looked pretty ugly to the end user (the no-more-gray-rect
improvement makes the UI remain good). I wish I could refactor the
whole thing so threading is used, but this is a very complex app so
this hack was necessary. In that particular case my code would not
break when changing the rules because I kind of know what I am doing
and I was not validating too high up in the hierarchy. Still, this is
not the case for some apps and code I have seen in the past...

> guess Swing team might provide more details on why it is more correct.

And I am waiting for their input because I sense this change can
affect some existing apps where code does not follow the
recommendations.

-Christopher