From roman.kennke at aicas.com  Wed Dec  3 16:26:43 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Wed, 03 Dec 2008 17:26:43 +0100
Subject: <Swing Dev> Problem in Swing Timer
Message-ID: <1228321603.6305.80.camel@moonlight>

Hi,

I see a small problem in the Swing timer. If you have a look in
TimerQueue.java, you'll see the following startup code:

    synchronized void start() {
        if (running) {
            throw new RuntimeException("Can't start a TimerQueue " +
                                       "that is already running");
        }
        else {
            final ThreadGroup threadGroup =
                AppContext.getAppContext().getThreadGroup();
            java.security.AccessController.doPrivileged(
                new java.security.PrivilegedAction() {
                public Object run() {
                    Thread timerThread = new Thread(threadGroup,
TimerQueue.this,
                                                    "TimerQueue");
                    timerThread.setDaemon(true);
                    timerThread.setPriority(Thread.NORM_PRIORITY);
                    timerThread.start();
                    return null;
                }
            });
            running = true;
        }
    }

and the actual thread loop looks like this:

    public void run() {
        while (running) {
            // Do stuff.
        }
    }

You see that the running field is set _after_ the thread has been
started. It can happen that the started thread kicks off immediately,
sees that running is (still) false, and stops again, and only then is
running set to true. I think it's safer to set the running field
_before_ actually starting the thread:


    synchronized void start() {
        if (running) {
            throw new RuntimeException("Can't start a TimerQueue " +
                                       "that is already running");
        }
        else {
            final ThreadGroup threadGroup =
                AppContext.getAppContext().getThreadGroup();
            java.security.AccessController.doPrivileged(
                new java.security.PrivilegedAction() {
                public Object run() {
                    Thread timerThread = new Thread(threadGroup,
TimerQueue.this,
                                                    "TimerQueue");
                    timerThread.setDaemon(true);
                    timerThread.setPriority(Thread.NORM_PRIORITY);
                    running = true;
                    timerThread.start();
                    return null;
                }
            });
        }
    }

What do you think?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Igor.Kushnirskiy at Sun.COM  Wed Dec  3 17:16:51 2008
From: Igor.Kushnirskiy at Sun.COM (Igor Kushnirskiy)
Date: Wed, 03 Dec 2008 12:16:51 -0500
Subject: <Swing Dev> Problem in Swing Timer
In-Reply-To: <1228321603.6305.80.camel@moonlight>
References: <1228321603.6305.80.camel@moonlight>
Message-ID: <4936BF03.7030701@sun.com>

Hi Roman,

There was a bug which covered this problem - 6623943 
[javax.swing.TimerQueue's thread occasionally fails to start] 
http://bugs.sun.com/view_bug.do?bug_id=6623943.
It was fixed in the jdk7 b38:
changeset fc09152d5cf6
http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fc09152d5cf6

The fix has not been backported to 6-open and I guess this is where your 
sources came from.

Thanks,
   Igor

Roman Kennke wrote:
> Hi,
> 
> I see a small problem in the Swing timer. If you have a look in
> TimerQueue.java, you'll see the following startup code:
> 
>     synchronized void start() {
>         if (running) {
>             throw new RuntimeException("Can't start a TimerQueue " +
>                                        "that is already running");
>         }
>         else {
>             final ThreadGroup threadGroup =
>                 AppContext.getAppContext().getThreadGroup();
>             java.security.AccessController.doPrivileged(
>                 new java.security.PrivilegedAction() {
>                 public Object run() {
>                     Thread timerThread = new Thread(threadGroup,
> TimerQueue.this,
>                                                     "TimerQueue");
>                     timerThread.setDaemon(true);
>                     timerThread.setPriority(Thread.NORM_PRIORITY);
>                     timerThread.start();
>                     return null;
>                 }
>             });
>             running = true;
>         }
>     }
> 
> and the actual thread loop looks like this:
> 
>     public void run() {
>         while (running) {
>             // Do stuff.
>         }
>     }
> 
> You see that the running field is set _after_ the thread has been
> started. It can happen that the started thread kicks off immediately,
> sees that running is (still) false, and stops again, and only then is
> running set to true. I think it's safer to set the running field
> _before_ actually starting the thread:
> 
> 
>     synchronized void start() {
>         if (running) {
>             throw new RuntimeException("Can't start a TimerQueue " +
>                                        "that is already running");
>         }
>         else {
>             final ThreadGroup threadGroup =
>                 AppContext.getAppContext().getThreadGroup();
>             java.security.AccessController.doPrivileged(
>                 new java.security.PrivilegedAction() {
>                 public Object run() {
>                     Thread timerThread = new Thread(threadGroup,
> TimerQueue.this,
>                                                     "TimerQueue");
>                     timerThread.setDaemon(true);
>                     timerThread.setPriority(Thread.NORM_PRIORITY);
>                     running = true;
>                     timerThread.start();
>                     return null;
>                 }
>             });
>         }
>     }
> 
> What do you think?
> 
> /Roman
> 


From fbrunnerlist at gmx.ch  Thu Dec  4 09:53:00 2008
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Thu, 04 Dec 2008 10:53:00 +0100
Subject: <Swing Dev> [PATCH] 6179357-related: warnings removal
In-Reply-To: <492EB781.6090305@sun.com>
References: <200811200134.42744.fbrunnerlist@gmx.ch> <492EB781.6090305@sun.com>
Message-ID: <4937A87C.9040108@gmx.ch>

Hi Pavel,

great! :-)

I started now with adding generics to the Swing classes. I decided to 
start with JList/ ListModel. OK?

Soon I'll get in touch with you again.

-Florian

Pavel Porvatov schrieb:
> Hi Florian,
>
> I've committed your fix in jdk7. It's available here:
> http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5784f5dfe3ac
>
> Thank you for your hard work!
>
> Regards, Pavel.
>
>> Hi,
>>
>> here another patch to remove warnings in the Swing classes.
>>
>> 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 112 to 95.
>>
>> 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.)
>>
>> In this past year we could reduce the number of reported warnings 
>> from ca. 1277 to 95 when compiling with
>> -Xlint -J-Xms80m -J-Xmx256m -Xlint:-serial -Xlint:-deprecation 
>> -Xlint:-fallthrough -Xmaxwarns 2300
>>
>> When this patch will be commited, I will finally start working on the 
>> actual task: adding generics to the Swing-framework. With 'only' 95 
>> warnings left, it should be much easier now to see if I introduce new 
>> warnings while working on this task (especially unchecked and cast 
>> warnings).
>> -Florian
>>
>



From Pavel.Porvatov at Sun.COM  Mon Dec  8 14:55:32 2008
From: Pavel.Porvatov at Sun.COM (Pavel Porvatov)
Date: Mon, 08 Dec 2008 17:55:32 +0300
Subject: <Swing Dev> [PATCH] 6179357-related: warnings removal
In-Reply-To: <4937A87C.9040108@gmx.ch>
References: <200811200134.42744.fbrunnerlist@gmx.ch> <492EB781.6090305@sun.com>
	<4937A87C.9040108@gmx.ch>
Message-ID: <493D3564.4020301@sun.com>

Hi Florian,

Fine. Try to avoid large fixes and divide them into several logical 
parts if possible, please.

Regards, Pavel.

> Hi Pavel,
> 
> great! :-)
> 
> I started now with adding generics to the Swing classes. I decided to 
> start with JList/ ListModel. OK?
> 
> Soon I'll get in touch with you again.
> 
> -Florian
> 
> Pavel Porvatov schrieb:
>> Hi Florian,
>>
>> I've committed your fix in jdk7. It's available here:
>> http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5784f5dfe3ac
>>
>> Thank you for your hard work!
>>
>> Regards, Pavel.
>>
>>> Hi,
>>>
>>> here another patch to remove warnings in the Swing classes.
>>>
>>> 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 112 to 95.
>>>
>>> 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.)
>>>
>>> In this past year we could reduce the number of reported warnings 
>>> from ca. 1277 to 95 when compiling with
>>> -Xlint -J-Xms80m -J-Xmx256m -Xlint:-serial -Xlint:-deprecation 
>>> -Xlint:-fallthrough -Xmaxwarns 2300
>>>
>>> When this patch will be commited, I will finally start working on the 
>>> actual task: adding generics to the Swing-framework. With 'only' 95 
>>> warnings left, it should be much easier now to see if I introduce new 
>>> warnings while working on this task (especially unchecked and cast 
>>> warnings).
>>> -Florian
>>>
>>
> 



From lbrtchx at gmail.com  Sun Dec 21 01:52:25 2008
From: lbrtchx at gmail.com (Albretch Mueller)
Date: Sat, 20 Dec 2008 20:52:25 -0500
Subject: <Swing Dev> freely floating (and dockable) Windows
Message-ID: <9ef66fac0812201752o22661e8akd6e5e426ceb67b99@mail.gmail.com>

 Hi,
~
 I recently started a thread on comp.lang.java.gui:
~
 "dockable windows"
~
 you may find interesting
~
 It is basically about swing only letting you float around JToolBars only
~
 Is there a technical reason for it? (I mean, other than a design decision?)
~
 Thanks
 lbrtchx


From sergey.malenkov at sun.com  Mon Dec 22 14:41:43 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Mon, 22 Dec 2008 14:41:43 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 4864117: RFE: Make XMLDecoder API
	more reusable
Message-ID: <20081222144155.844D3DD20@hg.openjdk.java.net>

Changeset: 50a9a4db3500
Author:    malenkov
Date:      2008-12-22 17:42 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/50a9a4db3500

4864117: RFE: Make XMLDecoder API more reusable
Reviewed-by: peterz, loneid

- src/share/classes/com/sun/beans/ObjectHandler.java
+ src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java
+ src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ByteElementHandler.java
+ src/share/classes/com/sun/beans/decoder/CharElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ClassElementHandler.java
+ src/share/classes/com/sun/beans/decoder/DocumentHandler.java
+ src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ElementHandler.java
+ src/share/classes/com/sun/beans/decoder/FalseElementHandler.java
+ src/share/classes/com/sun/beans/decoder/FieldElementHandler.java
+ src/share/classes/com/sun/beans/decoder/FloatElementHandler.java
+ src/share/classes/com/sun/beans/decoder/IntElementHandler.java
+ src/share/classes/com/sun/beans/decoder/JavaElementHandler.java
+ src/share/classes/com/sun/beans/decoder/LongElementHandler.java
+ src/share/classes/com/sun/beans/decoder/MethodElementHandler.java
+ src/share/classes/com/sun/beans/decoder/NewElementHandler.java
+ src/share/classes/com/sun/beans/decoder/NullElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java
+ src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ShortElementHandler.java
+ src/share/classes/com/sun/beans/decoder/StringElementHandler.java
+ src/share/classes/com/sun/beans/decoder/TrueElementHandler.java
+ src/share/classes/com/sun/beans/decoder/ValueObject.java
+ src/share/classes/com/sun/beans/decoder/ValueObjectImpl.java
+ src/share/classes/com/sun/beans/decoder/VarElementHandler.java
+ src/share/classes/com/sun/beans/decoder/VoidElementHandler.java
+ src/share/classes/com/sun/beans/finder/AbstractFinder.java
! src/share/classes/com/sun/beans/finder/ClassFinder.java
+ src/share/classes/com/sun/beans/finder/ConstructorFinder.java
+ src/share/classes/com/sun/beans/finder/FieldFinder.java
+ src/share/classes/com/sun/beans/finder/MethodFinder.java
! src/share/classes/com/sun/beans/finder/PrimitiveTypeMap.java
+ src/share/classes/com/sun/beans/finder/PrimitiveWrapperMap.java
+ src/share/classes/com/sun/beans/finder/Signature.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/ReflectionUtils.java
! src/share/classes/java/beans/XMLDecoder.java
! src/share/classes/javax/swing/plaf/synth/SynthParser.java
+ test/java/beans/XMLDecoder/Test4864117.java
! test/java/beans/XMLDecoder/Test6341798.java
+ test/java/beans/XMLDecoder/spec/AbstractTest.java
+ test/java/beans/XMLDecoder/spec/TestArray.java
+ test/java/beans/XMLDecoder/spec/TestBoolean.java
+ test/java/beans/XMLDecoder/spec/TestByte.java
+ test/java/beans/XMLDecoder/spec/TestChar.java
+ test/java/beans/XMLDecoder/spec/TestClass.java
+ test/java/beans/XMLDecoder/spec/TestDouble.java
+ test/java/beans/XMLDecoder/spec/TestFalse.java
+ test/java/beans/XMLDecoder/spec/TestField.java
+ test/java/beans/XMLDecoder/spec/TestFloat.java
+ test/java/beans/XMLDecoder/spec/TestInt.java
+ test/java/beans/XMLDecoder/spec/TestJava.java
+ test/java/beans/XMLDecoder/spec/TestLong.java
+ test/java/beans/XMLDecoder/spec/TestMethod.java
+ test/java/beans/XMLDecoder/spec/TestNew.java
+ test/java/beans/XMLDecoder/spec/TestNull.java
+ test/java/beans/XMLDecoder/spec/TestObject.java
+ test/java/beans/XMLDecoder/spec/TestProperty.java
+ test/java/beans/XMLDecoder/spec/TestShort.java
+ test/java/beans/XMLDecoder/spec/TestString.java
+ test/java/beans/XMLDecoder/spec/TestTrue.java
+ test/java/beans/XMLDecoder/spec/TestVar.java



From sergey.malenkov at sun.com  Thu Dec 25 18:05:19 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 25 Dec 2008 18:05:19 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6736248: EnumEditor bug. Class
	check incorrect
Message-ID: <20081225180531.52D3CDF0D@hg.openjdk.java.net>

Changeset: 2b8a0d8b5cbb
Author:    malenkov
Date:      2008-12-25 20:43 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2b8a0d8b5cbb

6736248: EnumEditor bug. Class check incorrect
Reviewed-by: rupashka, alexp

! src/share/classes/sun/beans/editors/EnumEditor.java
+ test/java/beans/PropertyEditor/TestEnumSubclass.java
+ test/java/beans/PropertyEditor/TestEnumSubclassJava.java
+ test/java/beans/PropertyEditor/TestEnumSubclassNull.java
+ test/java/beans/PropertyEditor/TestEnumSubclassValue.java



From mahogny at areta.org  Mon Dec 29 19:42:05 2008
From: mahogny at areta.org (Johan Henriksson)
Date: Mon, 29 Dec 2008 20:42:05 +0100
Subject: <Swing Dev> awful JButton
Message-ID: <4959280D.2040401@areta.org>

Hello!

I've become tempted at some openjdk hacking. the JButton has pissed me
off for a long time. it doesn't work very well when shrunk:

* The text is replaced by ... even when ... takes almost more or as much
space
* instead of removing slack space at the sides of the text, it starts to
throw away the label

work-arounds in GUIs that has to be compact are really awful. I wouldn't
mind trying to fix this myself if someone gives me a few pointers (I'm
totally confused about AWT, java2d, any sort of acceleration and gtk(?))
but first:

1. would changing the behaviour break anything? (or enough to stop the
change?)
2. what's your opinion? would a patch be accepted?

/Johan


From david.gilbert at object-refinery.com  Tue Dec 30 11:05:31 2008
From: david.gilbert at object-refinery.com (David Gilbert)
Date: Tue, 30 Dec 2008 12:05:31 +0100
Subject: <Swing Dev> awful JButton
In-Reply-To: <4959280D.2040401@areta.org>
References: <4959280D.2040401@areta.org>
Message-ID: <495A007B.7040506@object-refinery.com>

Johan Henriksson wrote:
> Hello!
>
> I've become tempted at some openjdk hacking. the JButton has pissed me
> off for a long time. it doesn't work very well when shrunk:
>
> * The text is replaced by ... even when ... takes almost more or as much
> space
> * instead of removing slack space at the sides of the text, it starts to
> throw away the label
>
> work-arounds in GUIs that has to be compact are really awful. I wouldn't
> mind trying to fix this myself if someone gives me a few pointers (I'm
> totally confused about AWT, java2d, any sort of acceleration and gtk(?))
> but first:
>
> 1. would changing the behaviour break anything? (or enough to stop the
> change?)
> 2. what's your opinion? would a patch be accepted?
>
> /Johan
>   
Hi Johan,

You can control the button margins within the look and feel (LAF), at 
least for LAFs derived from BasicLookAndFeel (I never studied the Synth 
look and feel so I don't know if the same applies for LAFs based on 
Synth).  The property key is "Button.margin" and the default value is 
InsetsUIResource(2, 14, 2, 14).  Maybe you just want to reduce the left 
and right margins for your app...or customise the ButtonUI class to 
adjust the margins dynamically according to the available space.

Regards,

Dave Gilbert
http://www.jfree.org/




From fbrunnerlist at gmx.ch  Tue Dec 30 20:55:14 2008
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Tue, 30 Dec 2008 21:55:14 +0100
Subject: <Swing Dev> 6179357: Generics: JList: getSelectedValues
Message-ID: <200812302155.14405.fbrunnerlist@gmx.ch>

Hi,

I hope you all had a Merry Christmas! I started now to add generics to ListModel and JList. While adding generics to the ListModel is quite straightforward, I think, there 
are some issues with JList, I would like to dicuss. I start here with the first issue: getSelectedValues

Am I right, that there is no way to change the signature of this method to:
public E[] getSelectedValues()
where E is the type parameter of the class?
(Because of generic array creation, which is not supported by Java.)

Here is the current implementation:

public Object[] getSelectedValues() {
        ListSelectionModel sm = getSelectionModel();
        ListModel dm = getModel();

        int iMin = sm.getMinSelectionIndex();
        int iMax = sm.getMaxSelectionIndex();

        if ((iMin < 0) || (iMax < 0)) {
            return new Object[0];
        }

        Object[] rvTmp = new Object[1+ (iMax - iMin)];
        int n = 0;
        for(int i = iMin; i <= iMax; i++) {
            if (sm.isSelectedIndex(i)) {
                rvTmp[n++] = dm.getElementAt(i);
            }
        }
        Object[] rv = new Object[n];
        System.arraycopy(rvTmp, 0, rv, 0, n);
        return rv;
    }

If this is not possible I propose to add a new method:
public List<E> getSelectedItems()

and deprecate getSelectedValues:

...
     * @deprecated As of JDK 1.7, replaced by {@link #getSelectedItems()}
     */
    @Deprecated
    public Object[] getSelectedValues() {
...
}

 /**
     * Returns a list of all the selected items, in increasing order based
     * on their indices in the list.
     *
     * @return the selected items, or an empty list if nothing is selected
     * @see #isSelectedIndex
     * @see #getModel
     * @see #addListSelectionListener
     * 
     * @since 1.7
     */
    public List<E> getSelectedItems() {
        ListSelectionModel sm = getSelectionModel();
        ListModel<? extends E> dm = getModel();

        int iMin = sm.getMinSelectionIndex();
        int iMax = sm.getMaxSelectionIndex();

        if ((iMin < 0) || (iMax < 0)) {
            return Collections.emptyList();
        }

        List<E> selectedItems = new ArrayList<E>();
        for(int i = iMin; i <= iMax; i++) {
            if (sm.isSelectedIndex(i)) {
                selectedItems.add(dm.getElementAt(i));
            }
        }
        return selectedItems;
    }

Note: Ignore for now 'E' vs '? extends E', I will start another thread for this. I'm just interested if you think it's a good idea to add the getSelectedItems method and to 
deprecate getSelectedValues.

So I wish you a Happy New Year and hope to hear from you soon.

-Florian

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

From jo at jogiles.co.nz  Tue Dec 30 20:59:09 2008
From: jo at jogiles.co.nz (Jonathan Giles)
Date: Wed, 31 Dec 2008 09:59:09 +1300
Subject: <Swing Dev> 6179357: Generics: JList: getSelectedValues
In-Reply-To: <200812302155.14405.fbrunnerlist@gmx.ch>
References: <200812302155.14405.fbrunnerlist@gmx.ch>
Message-ID: <495A8B9D.9080804@JoGiles.co.nz>

Florian,

Your proposed solution of deprecating the old method and referring to 
the new method seems like a good idea to me.

Cheers,
Jonathan Giles

Florian Brunner wrote:
>
> Hi,
>
> I hope you all had a Merry Christmas! I started now to add generics to 
> ListModel and JList. While adding generics to the ListModel is quite 
> straightforward, I think, there are some issues with JList, I would 
> like to dicuss. I start here with the first issue: getSelectedValues
>
> Am I right, that there is no way to change the signature of this 
> method to:
>
> public E[] getSelectedValues()
>
> where E is the type parameter of the class?
>
> (Because of generic array creation, which is not supported by Java.)
>
> Here is the current implementation:
>
> public Object[] getSelectedValues() {
>
> ListSelectionModel sm = getSelectionModel();
>
> ListModel dm = getModel();
>
> int iMin = sm.getMinSelectionIndex();
>
> int iMax = sm.getMaxSelectionIndex();
>
> if ((iMin < 0) || (iMax < 0)) {
>
> return new Object[0];
>
> }
>
> Object[] rvTmp = new Object[1+ (iMax - iMin)];
>
> int n = 0;
>
> for(int i = iMin; i <= iMax; i++) {
>
> if (sm.isSelectedIndex(i)) {
>
> rvTmp[n++] = dm.getElementAt(i);
>
> }
>
> }
>
> Object[] rv = new Object[n];
>
> System.arraycopy(rvTmp, 0, rv, 0, n);
>
> return rv;
>
> }
>
> If this is not possible I propose to add a new method:
>
> public List<E> getSelectedItems()
>
> and deprecate getSelectedValues:
>
> ...
>
> * @deprecated As of JDK 1.7, replaced by {@link #getSelectedItems()}
>
> */
>
> @Deprecated
>
> public Object[] getSelectedValues() {
>
> ...
>
> }
>
> /**
>
> * Returns a list of all the selected items, in increasing order based
>
> * on their indices in the list.
>
> *
>
> * @return the selected items, or an empty list if nothing is selected
>
> * @see #isSelectedIndex
>
> * @see #getModel
>
> * @see #addListSelectionListener
>
> *
>
> * @since 1.7
>
> */
>
> public List<E> getSelectedItems() {
>
> ListSelectionModel sm = getSelectionModel();
>
> ListModel<? extends E> dm = getModel();
>
> int iMin = sm.getMinSelectionIndex();
>
> int iMax = sm.getMaxSelectionIndex();
>
> if ((iMin < 0) || (iMax < 0)) {
>
> return Collections.emptyList();
>
> }
>
> List<E> selectedItems = new ArrayList<E>();
>
> for(int i = iMin; i <= iMax; i++) {
>
> if (sm.isSelectedIndex(i)) {
>
> selectedItems.add(dm.getElementAt(i));
>
> }
>
> }
>
> return selectedItems;
>
> }
>
> Note: Ignore for now 'E' vs '? extends E', I will start another thread 
> for this. I'm just interested if you think it's a good idea to add the 
> getSelectedItems method and to deprecate getSelectedValues.
>
> So I wish you a Happy New Year and hope to hear from you soon.
>
> -Florian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20081231/f85dd74c/attachment.html>