From pavel.porvatov at sun.com  Mon Jun  2 15:13:15 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Mon, 02 Jun 2008 15:13:15 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6709530: There are unnecessary code
	in slider	classes, such as in JSlider and SliderUIs
Message-ID: <20080602151334.A231228E21@hg.openjdk.java.net>

Changeset: be7d7a297c3d
Author:    rupashka
Date:      2008-06-02 19:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/be7d7a297c3d

6709530: There are unnecessary code in slider classes, such as in JSlider and SliderUIs
Summary: Removed unnecessary code like unused variables, castings, imports etc
Reviewed-by: peterz

! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java



From pavel.porvatov at sun.com  Tue Jun  3 14:04:15 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Tue, 03 Jun 2008 14:04:15 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 4987336: JSlider doesn't show
	label's animated	icon
Message-ID: <20080603140436.46D2A28E63@hg.openjdk.java.net>

Changeset: af37dad9022d
Author:    rupashka
Date:      2008-06-03 18:00 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/af37dad9022d

4987336: JSlider doesn't show label's animated icon
Summary: JSlider registers as an image observer of label's icon
Reviewed-by: alexp

! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
+ test/javax/swing/JSlider/4987336/box.gif
+ test/javax/swing/JSlider/4987336/bug4987336.html
+ test/javax/swing/JSlider/4987336/bug4987336.java
+ test/javax/swing/JSlider/4987336/cupanim.gif



From Alexander.Potochkin at Sun.COM  Tue Jun  3 15:40:19 2008
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Tue, 03 Jun 2008 19:40:19 +0400
Subject: <Swing Dev> JViewport Performance issues
In-Reply-To: <EB116665D9667A4283EF4142702E0B7265EC70@pprmail.plugpower.com>
References: <EB116665D9667A4283EF4142702E0B7265EC70@pprmail.plugpower.com>
Message-ID: <484565E3.4080703@sun.com>

Hello Chen

Thanks for the information

I wonder if JViewport in the BACKINGSTORE_SCROLL_MODE
works better in this case?

Could you please give more details about the workaround
from JadeDisplay which you mentioned below ?

Thanks
alexp

> Hello Swing Dev,
> 
>  
> 
> Could we get some visibility on bugs 4478765 and 4486696?
> 
>  
> 
> I noticed there are a lot of flash based applications that use the mouse 
> drag to scroll in all directions.  This is a great user interface 
> device, but it currently cannot be implemented in Swing due to 
> performance bug 4486696.
> 
>  
> 
> The current work around is to do something like what JadeDisplay did 
> using their JViewportImage
> 
> http://downloads.openchannelsoftware.org/JadeDisplay/jade_display_2_0.tar.gz
> 
>  
> 
> If you look at the implementation, you?ll see that bug 4478765 made it 
> very difficult.
> 
>  
> 
> This is one of those bugs that developers run into and just continue to 
> think Java has poor performance, while this is actually just an API 
> performance issue.  I?ve tested JViewportImage, and while it only works 
> for opaque components (but can be implemented to work with all 
> components), it improved perceived performance by an order of magnitude 
> when implementing drag scroll.
> 
>  
> 
> Thanks,
> 
> **Ronald Chen**
> 
>  
> 



From pavel.porvatov at sun.com  Wed Jun  4 14:55:39 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Wed, 04 Jun 2008 14:55:39 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6571802: 'Shared Documents' listed
	in-between C, D drives in the JFileChooser,
	does not match with native
Message-ID: <20080604145559.820B628F17@hg.openjdk.java.net>

Changeset: f36f0f189064
Author:    rupashka
Date:      2008-06-04 18:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f36f0f189064

6571802: 'Shared Documents' listed in-between C,D drives in the JFileChooser, does not match with native
Summary: now sun.awt.shell.ShellFolder#sort uses system sorting instead of alphabetical
Reviewed-by: loneid, peterz

! 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/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java



From linuxhippy at gmail.com  Wed Jun  4 15:05:19 2008
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 4 Jun 2008 17:05:19 +0200
Subject: <Swing Dev> <AWT Dev> Inefficiencies with custom
	TableCellRenderer and Applets
In-Reply-To: <483670E3.1080909@sun.com>
References: <194f62550805030800tad50359racbcfbec30230de9@mail.gmail.com>
	<4835C808.9030009@sun.com> <48366E59.2060509@sun.com>
	<483670E3.1080909@sun.com>
Message-ID: <194f62550806040805j406dbb3et81c8064d8cf676f6@mail.gmail.com>

Hi Artem,

Sorry, I haven't been monitoring this discussion the last two weeks or so.
Thanks a lot for looking into it, and for filing the bug.

Clemens

2008/5/23 Artem Ananiev <Artem.Ananiev at sun.com>:
>
> Artem Ananiev wrote:
>>
>> Shannon Hickey wrote:
>>>
>>> Clemens Eisserer wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've created a library which has to use custom TableCellRenderers for
>>>> its tables.
>>>> I experienced a large performance difference between running my
>>>> application as Application inside an JFrame and as an JApplet.
>>>> Parented inside of the JFrame scrolling the table was smooth, however
>>>> scrolling inside the applet was slow, especially if the mouse is over
>>>> the table while scrolling.
>>>>
>>>> I did some profiling with netbeans-profiler and found the root-cause:
>>>>
>>>> BasicTableUI.paintCell->CellRendererPane.paintComponent->Container.validate->Component.updateCursorImmediatly->GlobalCursorManager.updateCursorImmediatly()->_updateCursor....
>>>>
>>>> The updateCursorImmediatly was called both times about 16.000 times,
>>>> with JFrame it consumed 22% of the cycles which is already
>>>> inefficient.
>>>> As JApplet it calls into getLocationOnScreen() which calls down till
>>>> XBaseWindow.toOtherWindow even slower which is about as slow as
>>>> updating the Cursor itself, so as applet it consumes 48% of all EDT
>>>> cycles.
>>
>> What a sad story... I will file a bug against AWT about this problem.
>
> The bug ID is 6706534 - it must be visible in the web in a couple of days.
>
> Artem
>
>>>> The DefaultTableCellRenderer simply overrides validate with an empty
>>>> method, therefor no such calls are done.
>>>> But why does CellRendererPane.paintComponent() call validate at all?
>>>
>>> CellRendererPain takes an argument that dictates whether or not it
>>> validates. In most cases it's told to validate by the caller since the
>>> renderer may need to do layout on its children.
>>>
>>> I suggest you override validate() on your custom renderer to do nothing,
>>> the same way the DefaultTableCellRenderer does.
>>>
>>>> If it cannot be avoided, is there no way to cache stuff in
>>>> XBaseWindow.toOtherWindow at all?
>>
>> We have some kind of caching for this call, however in the case of applets
>> (embedded frames) it doesn't work very well...
>>
>> Artem
>>
>>> You'll have to ask the AWT team about this. I've CC'd them.
>>>
>>> Shannon
>>>
>>>>
>>>> Thanks, lg Clemens
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Very simple TableCellRenderer which triggers the slowness:
>>>>      JLabel renderer = new JLabel();
>>>>      public Component getTableCellRendererComponent(JTable table, Object
>>>> value,
>>>>          boolean isSelected, boolean hasFocus, int row, int column) {
>>>>         renderer.setText((String)value);
>>>>         renderer.setOpaque(true);
>>>>        return renderer;
>>>>      }
>>>
>


From pavel.porvatov at sun.com  Thu Jun  5 09:42:26 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Thu, 05 Jun 2008 09:42:26 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6688110: JSlider has incorrect
	javadoc for the	setValueIsAdjusting method
Message-ID: <20080605094250.F00282800B@hg.openjdk.java.net>

Changeset: e26917dd7b7c
Author:    rupashka
Date:      2008-06-05 13:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e26917dd7b7c

6688110: JSlider has incorrect javadoc for the setValueIsAdjusting method
Summary: The sentence about ChangeEvents generation was removed
Reviewed-by: peterz

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



From nathell at bach.ipipan.waw.pl  Mon Jun  9 17:33:37 2008
From: nathell at bach.ipipan.waw.pl (Daniel Janus)
Date: Mon, 9 Jun 2008 19:33:37 +0200
Subject: <Swing Dev> Polish translation of JFileChooser,
	JColorChooser and JOptionPane
Message-ID: <20080609173337.GA16041@bach.ipipan.waw.pl>

Dear list,

Let me introduce myself since this is my first (and hopefully not last)
post here.  I'm Daniel Janus, the current maintainer and one of the
developers of Poliqarp, the open-source concordancer for large
collections of texts.  

The GUI client of Poliqarp is written in Java and is currently
undergoing a major rewrite.  The GUI in question is bilingual,
completely translated to English and Polish (with an Ukrainian
translation coming soon), which means that not only are the system's own
messages translated to Polish, but so are some of the standard Swing
dialogs provided by the JRE (JFileChooser, to be more precise, since
it's the only one that's currently used).  I had produced a crude
translation of the latter sometime in early 2006; this involved creating
a Polish version of some .properties files under
com.sun.swing.internal.plaf.

Because the Poliqarp code is currently being reviewed and most of the
JDK went open source since then, I would like to take this opportunity,
complete the translation, synchronize it with the latest OpenJDK code
and contribute to the community.  I checked out the Mercurial
repositories, and if I am not mistaken this will involve providing a
patch that will add the translated .properties files in
jdk/src/share/classes/com/sun/swing/internal/plaf/{basic,metal,synth}/resources.

If there is anybody that would be willing to guide me through the
process of submitting such a patch, or else direct me to the more
proper place where it might be considered, I will be extremely grateful.

Best regards,
Daniel Janus


From Phil.Race at Sun.COM  Mon Jun  9 17:43:41 2008
From: Phil.Race at Sun.COM (Phil Race)
Date: Mon, 09 Jun 2008 10:43:41 -0700
Subject: <Swing Dev> Polish translation of JFileChooser,
	JColorChooser and JOptionPane
In-Reply-To: <20080609173337.GA16041@bach.ipipan.waw.pl>
References: <20080609173337.GA16041@bach.ipipan.waw.pl>
Message-ID: <484D6BCD.2060207@sun.com>

The process for making openjdk contributions is documented here :
http://openjdk.java.net/contribute/

My sense here is that it would be preferable to have translations
for all messages that are localised into other languages, not
just the ones in these particular dialogs.

Also since dialogs change, then an ongoing commitment to
translate new strings would be best.

-phil.

Daniel Janus wrote:
> Dear list,
> 
> Let me introduce myself since this is my first (and hopefully not last)
> post here.  I'm Daniel Janus, the current maintainer and one of the
> developers of Poliqarp, the open-source concordancer for large
> collections of texts.  
> 
> The GUI client of Poliqarp is written in Java and is currently
> undergoing a major rewrite.  The GUI in question is bilingual,
> completely translated to English and Polish (with an Ukrainian
> translation coming soon), which means that not only are the system's own
> messages translated to Polish, but so are some of the standard Swing
> dialogs provided by the JRE (JFileChooser, to be more precise, since
> it's the only one that's currently used).  I had produced a crude
> translation of the latter sometime in early 2006; this involved creating
> a Polish version of some .properties files under
> com.sun.swing.internal.plaf.
> 
> Because the Poliqarp code is currently being reviewed and most of the
> JDK went open source since then, I would like to take this opportunity,
> complete the translation, synchronize it with the latest OpenJDK code
> and contribute to the community.  I checked out the Mercurial
> repositories, and if I am not mistaken this will involve providing a
> patch that will add the translated .properties files in
> jdk/src/share/classes/com/sun/swing/internal/plaf/{basic,metal,synth}/resources.
> 
> If there is anybody that would be willing to guide me through the
> process of submitting such a patch, or else direct me to the more
> proper place where it might be considered, I will be extremely grateful.
> 
> Best regards,
> Daniel Janus


From nathell at bach.ipipan.waw.pl  Mon Jun  9 18:14:59 2008
From: nathell at bach.ipipan.waw.pl (Daniel Janus)
Date: Mon, 9 Jun 2008 20:14:59 +0200
Subject: <Swing Dev> Polish translation of JFileChooser,
	JColorChooser and JOptionPane
In-Reply-To: <484D6BCD.2060207@sun.com>
References: <20080609173337.GA16041@bach.ipipan.waw.pl>
	<484D6BCD.2060207@sun.com>
Message-ID: <20080609181459.GA17229@bach.ipipan.waw.pl>

Thanks for replying so fast!

> The process for making openjdk contributions is documented here :
> http://openjdk.java.net/contribute/

Yes, I've read that document.  Sorry for not having mentioned it.

While we're at it, the document mentions supplying a unit test.  Does
that also apply to the kind of contributions we're discussing here?
If so, any hints how such a unit-test might look like (i.e., what
should it test)?

> My sense here is that it would be preferable to have translations
> for all messages that are localised into other languages, not
> just the ones in these particular dialogs.
> 
> Also since dialogs change, then an ongoing commitment to
> translate new strings would be best.

I agree that this situation would be ideal.  In reality, however,
translations tend to have omissions -- in the German translation for
JFileChooser, for instance, some items are left untranslated.  And 
I probably can't cope with single-handedly translating the sheer volume
of .properties floating around the JDK code, much as I'd like to.

So probably I'll just submit a mercurial changeset within the next few
days or so, and then let the maintainers decide what to do with it.
Does that sound right?

Best regards,
Daniel Janus


From pavel.porvatov at sun.com  Tue Jun 10 10:25:02 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Tue, 10 Jun 2008 10:25:02 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 5035693: "Open" button should be a
	default one in	JFileChooser under Windows XP LAF
Message-ID: <20080610102526.B59512876B@hg.openjdk.java.net>

Changeset: 5083f5c15103
Author:    rupashka
Date:      2008-06-06 13:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5083f5c15103

5035693: "Open" button should be a default one in JFileChooser under Windows XP LAF
Summary: The "Open" button was made default button of FileChooser dialog windows
Reviewed-by: loneid, peterz

! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/plaf/FileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java



From fbrunnerlist at gmx.ch  Tue Jun 17 22:55:29 2008
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Wed, 18 Jun 2008 00:55:29 +0200
Subject: <Swing Dev> [PATCH] 6179357-related: warnings removal
In-Reply-To: <482A9529.4060508@sun.com>
References: <200708262033.16074.fbrunnerlist@gmx.ch>
	<200805132336.44357.fbrunnerlist@gmx.ch> <482A9529.4060508@sun.com>
Message-ID: <200806180055.30107.fbrunnerlist@gmx.ch>

Hi Pavel,

I just wanted to ask what the status of my patches is. I would like to 
continue to provide patches once those could be integrated.

Thanks.
-Florian

Am Mittwoch, 14. Mai 2008 schrieb Pavel Porvatov:
> Hi Florian,
>
> Great! I'll start work on it shortly.
>
> Thanks, Pavel.
>
> > Hi Pavel,
> >
> > it took a little longer than I thought, but now I've updated my patches
> > to base on http://hg.openjdk.java.net/jdk7/swing/jdk and removed all the
> > tabs.
> >
> > Unfortunatly it wasn't easily possible to port all patches. So I send
> > here the big part and after integration I will try to remove some of the
> > other warnings again before I start with adding generics to the Swing
> > framework.
> >
> > When compiling with
> > -Xlint -J-Xms80m -J-Xmx256m -Xlint:-serial -Xlint:-deprecation
> > -Xlint:-fallthrough -Xmaxwarns 2300
> > this patch reduces the number of reported warnings from 1263 to 240.
> >
> > Again, I tried only to change things related to the warnings and not to
> > change any public or protected APIs in public or protected classes in
> > this patch.
> >
> > At many places I tried to add type parameters as meaningful as possible,
> > but with some cases I just used Object, if a more meaningful type
> > parameter was not so trivial. You might want to refactor this if needed.
> > (Though everything should work as it is.)
> >
> > -Florian
> >
> > Am Dienstag, 29. April 2008 schrieb Florian Brunner:
> >> Hi Pavel,
> >>
> >>> Send me all remaining fixes at once. I changed my opinion because
> >>> 1. I don't want to produce a lot of CRs for every part of fix
> >>> 2. I'm going to do a small correction (if needed of course) in your
> >>> fix myself. It'll save a lot of our time
> >>
> >> Ok, great, I will do that as soon as I find some spare time (probably
> >> during the coming long week-end).
> >>
> >> -Florian




From sergey.malenkov at sun.com  Wed Jun 18 15:17:16 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Wed, 18 Jun 2008 15:17:16 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6708550: LTP: XMLEncoder does not
	encode	instances of the File class
Message-ID: <20080618151735.1509F28D3D@hg.openjdk.java.net>

Changeset: ec9c8e73ae53
Author:    malenkov
Date:      2008-06-18 19:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ec9c8e73ae53

6708550: LTP: XMLEncoder does not encode instances of the File class
Reviewed-by: peterz, loneid

! src/share/classes/java/io/File.java
+ test/java/beans/XMLEncoder/java_io_File.java



From Pavel.Porvatov at Sun.COM  Wed Jun 18 16:18:28 2008
From: Pavel.Porvatov at Sun.COM (Pavel Porvatov)
Date: Wed, 18 Jun 2008 20:18:28 +0400
Subject: <Swing Dev> [PATCH] 6179357-related: warnings removal
In-Reply-To: <200806180055.30107.fbrunnerlist@gmx.ch>
References: <200708262033.16074.fbrunnerlist@gmx.ch>
	<200805132336.44357.fbrunnerlist@gmx.ch> <482A9529.4060508@sun.com>
	<200806180055.30107.fbrunnerlist@gmx.ch>
Message-ID: <48593554.4040501@sun.com>

Hi Florian,

I'm working on your patches and now completed about 30%. There are 
really many changes in your fix and I made changes in your changes, so 
it's not very fast...

Regards, Pavel.


> Hi Pavel,
> 
> I just wanted to ask what the status of my patches is. I would like to 
> continue to provide patches once those could be integrated.
> 
> Thanks.
> -Florian
> 
> Am Mittwoch, 14. Mai 2008 schrieb Pavel Porvatov:
>> Hi Florian,
>>
>> Great! I'll start work on it shortly.
>>
>> Thanks, Pavel.
>>
>>> Hi Pavel,
>>>
>>> it took a little longer than I thought, but now I've updated my patches
>>> to base on http://hg.openjdk.java.net/jdk7/swing/jdk and removed all the
>>> tabs.
>>>
>>> Unfortunatly it wasn't easily possible to port all patches. So I send
>>> here the big part and after integration I will try to remove some of the
>>> other warnings again before I start with adding generics to the Swing
>>> framework.
>>>
>>> When compiling with
>>> -Xlint -J-Xms80m -J-Xmx256m -Xlint:-serial -Xlint:-deprecation
>>> -Xlint:-fallthrough -Xmaxwarns 2300
>>> this patch reduces the number of reported warnings from 1263 to 240.
>>>
>>> Again, I tried only to change things related to the warnings and not to
>>> change any public or protected APIs in public or protected classes in
>>> this patch.
>>>
>>> At many places I tried to add type parameters as meaningful as possible,
>>> but with some cases I just used Object, if a more meaningful type
>>> parameter was not so trivial. You might want to refactor this if needed.
>>> (Though everything should work as it is.)
>>>
>>> -Florian
>>>
>>> Am Dienstag, 29. April 2008 schrieb Florian Brunner:
>>>> Hi Pavel,
>>>>
>>>>> Send me all remaining fixes at once. I changed my opinion because
>>>>> 1. I don't want to produce a lot of CRs for every part of fix
>>>>> 2. I'm going to do a small correction (if needed of course) in your
>>>>> fix myself. It'll save a lot of our time
>>>> Ok, great, I will do that as soon as I find some spare time (probably
>>>> during the coming long week-end).
>>>>
>>>> -Florian
> 
> 



From sergey.malenkov at sun.com  Thu Jun 19 14:03:18 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 19 Jun 2008 14:03:18 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 4114658: DOC: Unspecified behaviour
	for	java.beans.PropertyEditorSupport
Message-ID: <20080619140330.327D328E56@hg.openjdk.java.net>

Changeset: fa7147a26cd2
Author:    malenkov
Date:      2008-06-19 18:03 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fa7147a26cd2

4114658: DOC: Unspecified behaviour for java.beans.PropertyEditorSupport
Reviewed-by: peterz, loneid

! src/share/classes/java/beans/PropertyEditor.java
! src/share/classes/java/beans/PropertyEditorSupport.java



From igor.kushnirskiy at sun.com  Mon Jun 23 19:28:01 2008
From: igor.kushnirskiy at sun.com (igor.kushnirskiy at sun.com)
Date: Mon, 23 Jun 2008 19:28:01 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6623943: javax.swing.TimerQueue's
	thread	occasionally fails to start
Message-ID: <20080623192822.EB74D281A6@hg.openjdk.java.net>

Changeset: fc09152d5cf6
Author:    idk
Date:      2008-06-23 15:21 -0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fc09152d5cf6

6623943: javax.swing.TimerQueue's thread occasionally fails to start
Reviewed-by: alexp

! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/TimerQueue.java



From sergey.malenkov at sun.com  Thu Jun 26 11:13:15 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 26 Jun 2008 11:13:15 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6718964: Swing border tests should
	be open source
Message-ID: <20080626111327.90CB428414@hg.openjdk.java.net>

Changeset: 282c86389114
Author:    malenkov
Date:      2008-06-26 15:11 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/282c86389114

6718964: Swing border tests should be open source
Reviewed-by: peterz

+ test/javax/swing/border/Test4120351.java
+ test/javax/swing/border/Test4124729.java
+ test/javax/swing/border/Test4243289.html
+ test/javax/swing/border/Test4243289.java
+ test/javax/swing/border/Test4247606.html
+ test/javax/swing/border/Test4247606.java
+ test/javax/swing/border/Test4252164.html
+ test/javax/swing/border/Test4252164.java
+ test/javax/swing/border/Test6461042.java



From sergey.malenkov at sun.com  Thu Jun 26 11:38:32 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 26 Jun 2008 11:38:32 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6718965: Swing color chooser tests
	should be open	source
Message-ID: <20080626113844.9B31C2841C@hg.openjdk.java.net>

Changeset: 581440ba714a
Author:    malenkov
Date:      2008-06-26 15:39 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/581440ba714a

6718965: Swing color chooser tests should be open source
Reviewed-by: peterz

+ test/javax/swing/JColorChooser/Test4165217.java
+ test/javax/swing/JColorChooser/Test4177735.java
+ test/javax/swing/JColorChooser/Test4193384.java
+ test/javax/swing/JColorChooser/Test4234761.java
+ test/javax/swing/JColorChooser/Test4380468.html
+ test/javax/swing/JColorChooser/Test4380468.java
+ test/javax/swing/JColorChooser/Test4461329.java
+ test/javax/swing/JColorChooser/Test4711996.java
+ test/javax/swing/JColorChooser/Test4759306.html
+ test/javax/swing/JColorChooser/Test4759306.java
+ test/javax/swing/JColorChooser/Test4759934.html
+ test/javax/swing/JColorChooser/Test4759934.java
+ test/javax/swing/JColorChooser/Test4887836.html
+ test/javax/swing/JColorChooser/Test4887836.java



From fbrunnerlist at gmx.ch  Mon Jun 30 21:22:42 2008
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Mon, 30 Jun 2008 23:22:42 +0200
Subject: <Swing Dev> [PATCH] 6179357-related: warnings removal
In-Reply-To: <48593554.4040501@sun.com>
References: <200708262033.16074.fbrunnerlist@gmx.ch>
	<200806180055.30107.fbrunnerlist@gmx.ch> <48593554.4040501@sun.com>
Message-ID: <200806302322.42961.fbrunnerlist@gmx.ch>

Ok, no problem.

-Florian

Am Mittwoch, 18. Juni 2008 schrieb Pavel Porvatov:
> Hi Florian,
>
> I'm working on your patches and now completed about 30%. There are
> really many changes in your fix and I made changes in your changes, so
> it's not very fast...
>
> Regards, Pavel.
>
> > Hi Pavel,
> >
> > I just wanted to ask what the status of my patches is. I would like to
> > continue to provide patches once those could be integrated.
> >
> > Thanks.
> > -Florian
> >
> > Am Mittwoch, 14. Mai 2008 schrieb Pavel Porvatov:
> >> Hi Florian,
> >>
> >> Great! I'll start work on it shortly.
> >>
> >> Thanks, Pavel.
> >>
> >>> Hi Pavel,
> >>>
> >>> it took a little longer than I thought, but now I've updated my patches
> >>> to base on http://hg.openjdk.java.net/jdk7/swing/jdk and removed all
> >>> the tabs.
> >>>
> >>> Unfortunatly it wasn't easily possible to port all patches. So I send
> >>> here the big part and after integration I will try to remove some of
> >>> the other warnings again before I start with adding generics to the
> >>> Swing framework.
> >>>
> >>> When compiling with
> >>> -Xlint -J-Xms80m -J-Xmx256m -Xlint:-serial -Xlint:-deprecation
> >>> -Xlint:-fallthrough -Xmaxwarns 2300
> >>> this patch reduces the number of reported warnings from 1263 to 240.
> >>>
> >>> Again, I tried only to change things related to the warnings and not to
> >>> change any public or protected APIs in public or protected classes in
> >>> this patch.
> >>>
> >>> At many places I tried to add type parameters as meaningful as
> >>> possible, but with some cases I just used Object, if a more meaningful
> >>> type parameter was not so trivial. You might want to refactor this if
> >>> needed. (Though everything should work as it is.)
> >>>
> >>> -Florian
> >>>
> >>> Am Dienstag, 29. April 2008 schrieb Florian Brunner:
> >>>> Hi Pavel,
> >>>>
> >>>>> Send me all remaining fixes at once. I changed my opinion because
> >>>>> 1. I don't want to produce a lot of CRs for every part of fix
> >>>>> 2. I'm going to do a small correction (if needed of course) in your
> >>>>> fix myself. It'll save a lot of our time
> >>>>
> >>>> Ok, great, I will do that as soon as I find some spare time (probably
> >>>> during the coming long week-end).
> >>>>
> >>>> -Florian