Florian Brunner | 1 Feb 22:10 2009
Picon
Picon

Re: 6179357: Generics: JList: getSelectedValues

Ok, I'll change this.

Do you like the name of the new method? Or do you have a better one?
getSelectedItems

Is the depraction-comment good or do you have some other conventions? Do you 
have a placeholder for the version number or is 1.7 good?
 <at> deprecated As of JDK 1.7, replaced by { <at> link #getSelectedItems()}

Is the since-comment in the new method good? Do you have a placeholder for the 
version number or is 1.7 good?
 <at> since 1.7

-Florian

Am Montag, 19. Januar 2009 schrieb Pavel Porvatov:
> Hi Florian,
>
> > So, does  everybody agree?
> >
> > Would be great to also have opinions from someone working at Sun?
> >
> > Pavel, especially your opinion is quite important since you will probably
> > be the one who will have to eventually accept and commit my patch. :-)
>
> I think we are not able to do anything with the getSelectedValues()
> method. So we should introduce the new method and deprecate the old one.
>
> Regards, Pavel.
>
(Continue reading)

Florian Brunner | 1 Feb 23:28 2009
Picon
Picon

6179357: Generics: JList: Constructors & Model

Hi,

I'm working now on the constructor and model-property of JList:

Here the constructors I how I suggest to change them:

----------------------------------------

public JList(final Object[] listData)

{

this (

new AbstractListModel() {

public int getSize() { return listData.length; }

public Object getElementAt(int i) { return listData[i]; }

}

);

}

--->

public JList(final E[] listData)

{

this (

new AbstractListModel<E>() {

public int getSize() { return listData.length; }

public E getElementAt(int i) { return listData[i]; }

}

);

}

----------------------------------------

public JList() {

this (

new AbstractListModel() {

public int getSize() { return 0; }

public Object getElementAt(int i) { return "No Data Model"; }

}

);

}

--->

public JList() {

this (

new AbstractListModel<E>() {

public int getSize() { return 0; }

public E getElementAt(int i) { throw new IndexOutOfBoundsException("No Data Model"); }

}

);

}

----------------------------------------

public JList(final Vector<?> listData) {

this (

new AbstractListModel() {

public int getSize() { return listData.size(); }

public Object getElementAt(int i) { return listData.elementAt(i); }

}

);

}

--->

public JList(final Vector<? extends E> listData) {

this (

new AbstractListModel<E>() {

public int getSize() { return listData.size(); }

public E getElementAt(int i) { return listData.elementAt(i); }

}

);

}

While we could define the signature also like this:

public JList(final Vector<E> listData)

there is now reason to limit the input - except maybe for consistency (see next constructor)

----------------------------------------

public JList(ListModel dataModel)

{

if (dataModel == null) {

throw new IllegalArgumentException("dataModel must be non null");

}

// Register with the ToolTipManager so that tooltips from the

// renderer show through.

ToolTipManager toolTipManager = ToolTipManager.sharedInstance();

toolTipManager.registerComponent(this);

layoutOrientation = VERTICAL;

this.dataModel = dataModel;

selectionModel = createSelectionModel();

setAutoscrolls(true);

setOpaque(true);

updateUI();

}

--->

public JList(ListModel<E> dataModel)

{

if (dataModel == null) {

throw new IllegalArgumentException("dataModel must be non null");

}

// Register with the ToolTipManager so that tooltips from the

// renderer show through.

ToolTipManager toolTipManager = ToolTipManager.sharedInstance();

toolTipManager.registerComponent(this);

layoutOrientation = VERTICAL;

this.dataModel = dataModel;

selectionModel = createSelectionModel();

setAutoscrolls(true);

setOpaque(true);

updateUI();

}

We could define the signature also like this:

public JList(ListModel<? extends E> dataModel)

but then we would have to define the dataModel-field also with:

private ListModel<? extends E> dataModel

as well as the model-property. I don't think this would be a good idea and thus define the signature as:

public JList(ListModel<E> dataModel)

What do you think?

-Florian

Pavel Porvatov | 3 Feb 16:57 2009
Picon

Re: 6179357: Generics: JList: getSelectedValues

Hi Florian,

> Ok, I'll change this.
> 
> Do you like the name of the new method? Or do you have a better one?
> getSelectedItems
I can suggest to use the "getSelectedValuesList" and return List instead 
of array, because Collections Framework is more useful than arrays.

> Is the depraction-comment good or do you have some other conventions? Do you 
> have a placeholder for the version number or is 1.7 good?
>  <at> deprecated As of JDK 1.7, replaced by { <at> link #getSelectedItems()}
> 
> Is the since-comment in the new method good? Do you have a placeholder for the 
> version number or is 1.7 good?
>  <at> since 1.7

For deprecated methods we use the " <at> deprecated" annotation. For a new 
API we use the next annotation: " <at> since 1.7"

Regards, Pavel.

> 
> -Florian
> 
> Am Montag, 19. Januar 2009 schrieb Pavel Porvatov:
>> Hi Florian,
>>
>>> So, does  everybody agree?
>>>
>>> Would be great to also have opinions from someone working at Sun?
>>>
>>> Pavel, especially your opinion is quite important since you will probably
>>> be the one who will have to eventually accept and commit my patch. :-)
>> I think we are not able to do anything with the getSelectedValues()
>> method. So we should introduce the new method and deprecate the old one.
>>
>> Regards, Pavel.
>>
>>> -Florian
>>>
>>> Am Dienstag, 30. Dezember 2008 schrieb Jonathan Giles:
>>>> 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:
>>>>>
>>>>> ...
>>>>>
>>>>> *  <at> deprecated As of JDK 1.7, replaced by { <at> link #getSelectedItems()}
>>>>>
>>>>> */
>>>>>
>>>>>  <at> Deprecated
>>>>>
>>>>> public Object[] getSelectedValues() {
>>>>>
>>>>> ...
>>>>>
>>>>> }
>>>>>
>>>>> /**
>>>>>
>>>>> * Returns a list of all the selected items, in increasing order based
>>>>>
>>>>> * on their indices in the list.
>>>>>
>>>>> *
>>>>>
>>>>> *  <at> return the selected items, or an empty list if nothing is selected
>>>>>
>>>>> *  <at> see #isSelectedIndex
>>>>>
>>>>> *  <at> see #getModel
>>>>>
>>>>> *  <at> see #addListSelectionListener
>>>>>
>>>>> *
>>>>>
>>>>> *  <at> 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
> 
> 

Pavel Porvatov | 3 Feb 17:38 2009
Picon

Re: 6179357: Generics: JList: Constructors & Model

Hi Florian,

> ----------------------------------------
> 
> public JList(ListModel dataModel)
> 
> {
> 
> if (dataModel == null) {
> 
> throw new IllegalArgumentException("dataModel must be non null");
> 
> }
> 
> // Register with the ToolTipManager so that tooltips from the
> 
> // renderer show through.
> 
> ToolTipManager toolTipManager = ToolTipManager.sharedInstance();
> 
> toolTipManager.registerComponent(this);
> 
> layoutOrientation = VERTICAL;
> 
> this.dataModel = dataModel;
> 
> selectionModel = createSelectionModel();
> 
> setAutoscrolls(true);
> 
> setOpaque(true);
> 
> updateUI();
> 
> }
> 
> --->
> 
> public JList(ListModel<E> dataModel)
> 
> {
> 
> if (dataModel == null) {
> 
> throw new IllegalArgumentException("dataModel must be non null");
> 
> }
> 
> // Register with the ToolTipManager so that tooltips from the
> 
> // renderer show through.
> 
> ToolTipManager toolTipManager = ToolTipManager.sharedInstance();
> 
> toolTipManager.registerComponent(this);
> 
> layoutOrientation = VERTICAL;
> 
> this.dataModel = dataModel;
> 
> selectionModel = createSelectionModel();
> 
> setAutoscrolls(true);
> 
> setOpaque(true);
> 
> updateUI();
> 
> }
> 
> We could define the signature also like this:
> 
> public JList(ListModel<? extends E> dataModel)
> 
> but then we would have to define the dataModel-field also with:
> 
> private ListModel<? extends E> dataModel
> 
> as well as the model-property. I don't think this would be a good idea 
> and thus define the signature as:
> 
> public JList(ListModel<E> dataModel)
> 
> What do you think?
Why do you think that "private ListModel<? extends E> dataModel" is not 
a very good idea?

Regards, Pavel

peter.zhelezniakov | 4 Feb 16:51 2009
Picon

hg: jdk7/swing/jdk: 6588003: LayoutQueue shares mutable implementation across AppContexts

Changeset: 442b563e57c6
Author:    peterz
Date:      2009-02-04 18:48 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/442b563e57c6

6588003: LayoutQueue shares mutable implementation across AppContexts
Summary: DefaultQueue property is made per-AppContext
Reviewed-by: alexp

! src/share/classes/javax/swing/text/LayoutQueue.java
+ test/javax/swing/text/LayoutQueue/Test6588003.java

sergey.malenkov | 5 Feb 13:56 2009
Picon

hg: jdk7/swing/jdk: 4769844: classes in java.beans that are serializable but don't define serialVersionUID

Changeset: 62a84e564a8c
Author:    malenkov
Date:      2009-02-05 14:48 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/62a84e564a8c

4769844: classes in java.beans that are serializable but don't define serialVersionUID
Reviewed-by: peterz, rupashka

! src/share/classes/java/beans/IndexedPropertyChangeEvent.java
! src/share/classes/java/beans/IntrospectionException.java
! src/share/classes/java/beans/PropertyChangeEvent.java
! src/share/classes/java/beans/PropertyVetoException.java
! src/share/classes/java/beans/beancontext/BeanContextEvent.java
! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java
! src/share/classes/java/beans/beancontext/BeanContextServiceAvailableEvent.java
! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedEvent.java
! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/share/classes/sun/beans/editors/ColorEditor.java
! src/share/classes/sun/beans/editors/FontEditor.java

sergey.malenkov | 5 Feb 15:01 2009
Picon

hg: jdk7/swing/jdk: 6669869: Beans.isDesignTime() and other queries should be per-AppContext

Changeset: 27dabbdfdcac
Author:    malenkov
Date:      2009-02-05 17:00 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/27dabbdfdcac

6669869: Beans.isDesignTime() and other queries should be per-AppContext
Reviewed-by: peterz, rupashka

! src/share/classes/java/beans/Beans.java
+ test/java/beans/Beans/6669869/TestDesignTime.java
+ test/java/beans/Beans/6669869/TestGuiAvailable.java

peter.zhelezniakov | 5 Feb 17:20 2009
Picon

hg: jdk7/swing/jdk: 6801769: 6588003 should be backed out from jdk7

Changeset: 0960e96d0de8
Author:    peterz
Date:      2009-02-05 19:16 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0960e96d0de8

6801769: 6588003 should be backed out from jdk7
Reviewed-by: alexp

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

artem.ananiev | 12 Feb 12:24 2009
Picon

hg: jdk7/swing/jdk: 6799345: JFC demos threw exception in the Java Console when applets are closed

Changeset: 794e786306c1
Author:    art
Date:      2009-02-12 14:19 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/794e786306c1

6799345: JFC demos threw exception in the Java Console when applets are closed
Reviewed-by: alexp, peterz

! src/share/classes/javax/swing/SwingWorker.java
! src/share/classes/javax/swing/TimerQueue.java
+ test/javax/swing/system/6799345/TestShutdown.java

Nikolay.Molchanov | 17 Feb 23:20 2009
Picon

Q about a11y

Hello Swing Dev team!

I have a question about an accessibility problem in some standard java
classes.
We are fixing these problems in Analyzer GUI, and noticed that we use
javax.swing.plaf.synth.SynthSplitPaneDivider, which does not implement
Accessible. Here is what Accessibility Helper says:

Doesn't implement Accessible :
   Class: javax.swing.plaf.synth.SynthSplitPaneDivider {  }
   Class: javax.swing.plaf.synth.SynthSplitPaneDivider {  }
   Class: javax.swing.plaf.synth.SynthSplitPaneDivider {  }

Do you know how to find out if this is a known bug?
If yes, probably there is a workaround in the bug report.
If not, I think I have to file a bug against java. Correct?

Thanks,
Nik


Gmane