United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4341785 : unix: List.select(-1) method invocation leads to unexpected result.

Details
Type:
Bug
Submit Date:
2000-05-29
Status:
Closed
Updated Date:
2003-08-26
Project Name:
JDK
Resolved Date:
2003-08-08
Component:
client-libs
OS:
solaris_8,solaris_7,linux,generic,windows_98
Sub-Component:
java.awt
CPU:
itanium,x86,sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.1.7,1.3.0,1.4.0,1.4.1,1.4.2
Fixed Versions:
5.0 (tiger)

Related Reports
Duplicate:

Sub Tasks

Description

Name: iaR10016			Date: 05/29/2000



JDK version:
java version "1.3.0beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0beta-b07)
Java HotSpot(TM) Client VM (build 1.3.0beta-b04, mixed mode)

Java 2 Platform SE v1.3 specification reads about the List.select(int) method:

...
public void select(int index)
       Selects the item at the specified index in the scrolling list.
       Parameters:
              index - the position of the item to select.
       See Also:
              getSelectedItem(), deselect(int), isIndexSelected(int)...
...

Specification does not stay that select(-1) must lead to selecting item with maximum index.

In Linux JDK 1.3 and Solaris JDK 1.3 calling List.select(-1) leads to selecting item with
maximum index. Note that after calling List.select with argument greater then maximum list index
selected item index is not changed.

In Window95 JDK 1.3 calling List.select(-1) leads to the selected item unselecting.

JCK 1.3 runtime test api/java_awt/interactive/ListTests.html#ListTest0005 fails due to this bug.

The following test example creates frame with List component. By clicking button "Select Item -1"
you can call method List.select(-1). After this button clicking item3 becomes selected.

---------------------------------- test.java -------------------------------------------------------

import java.awt.*;
import java.awt.event.*;

public class test extends Frame implements ActionListener
{
    List aList;
    void init() {
        aList= new List();
        aList.add("Test item1");
        aList.add("Test item2");
        aList.add("Test item3");
        Button aButton = new Button("Select Item -1");
        aButton.addActionListener(this);
        Panel aPanel = new Panel();
        aPanel.add(aList);
        aPanel.add(aButton);
        setSize(200,200);
        add(aPanel);
    }

    public static void main(String [] argv)
    {
        test t = new test();
        t.init();
        t.setVisible(true);
    }

    public void actionPerformed(ActionEvent e) {
        System.out.println("Selected item is " + aList.getSelectedIndex());
        aList.select(-1);
        System.out.println("After select(-1) selected item is " + aList.getSelectedIndex());
    }
}

======================================================================

Name: icR10030			Date: 01/15/2002


The other testcase ListTest0006 fails due to the bug too.

======================================================================

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b15

VERIFIED IN:
tiger


                                     
2004-06-14
EVALUATION

It may be too late to make List and Choice work the same, unfortunately, since 
Choice throws an IllegalArgumentException, and we probably should not start 
throwing Exceptions in List that we haven't been throwing before.  

Note that deselect has the same problem as select.  

See 4243707 for another report of this bug.  

eric.hawkes@eng 2000-07-05


The Javadoc for deselect(index) reads: 

     * Deselects the item at the specified index.
     * If the item at the specified index is not selected, or if the
     * index is out of range, then the operation is ignored.

However, this does not happen on Windows or Solaris.  On Windows, all the 
selected items are deselected.  On Solaris, only the last selected item is 
deselected.  Perhaps the safest thing to do would be to ignore the deselect 
in this case, as the Javadoc says.  

Perhaps we should simply ignore a call to select with an index of -1 as well.  

Whatever policy we decide on, we'll need to update the Javadoc for both select() 
and deselect() when this is fixed.  Also, we may need to check the index before 
the call to the peer to avoid replicating the native behavior when it is 
undesirable.  

eric.hawkes@eng 2000-07-05

This bug has been added to the JCK-exclude list.  When we fix it, we should 
make sure to inform the JCK team so they can update the tests appropriately.  

eric.hawkes@eng 2000-07-25
===============================
Reopening the BUG after checking wit Eric.Hawkes.
madhura.dudhgaonkar@eng 2001-07-11

From: "Eric Hawkes" <###@###.###>
To: "Madhura Dudhgaonkar" <###@###.###>
Subject: Re: Reopening 4341897 & 4341785
Date: Wed, 11 Jul 2001 13:23:36 -0700
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hi Madhura, 

>  The evaluation says there is plan to fix these BUGs. 
>  Can I reopen them for Merlin?

Go ahead and reopen 4341785.  I'm not positive we 
can get to it in merlin, but we ought to try to resolve 
the spec issue at some point.  
=====================================



Name: dkR10074			Date: 07/30/2003


This is a problem on Solaris and Linux, but not Windows. There is no
bounds checking for the range in Java. When legal values are passed
into these APIs, all supported platforms work the same, and according
to the spec.  It is only the out of range values that are problematic.  
The default behavior for out of range values in motif lists is
different than that specified for java.awt.List.  
 
Also, the Javadoc does not specify what should happen when there are
multiple selected items in the List, and selection mode is changed from
multiple-selection to single-selection.  Currently on Unix, it appears
that several items remain selected, even though we are in
single-selection mode.  This behavior is misleading to end users, and
inconsistent with behavior on other platforms.

Since we don't want to break binary compatibility, we suggest to change
the description of java.awt.List.select(int) and java.awt.List.deselect(int)
methods to say that unspecified behavior will result if the parameter is
out of range.
 
In the case of changing multiple-selection to single-selection, we propose
to change the native unix code to make such List behavior the same across
supported platforms.  Only the selected item that has the location cursor
will remain selected.  This solution will enforce consistency across
platforms, and will provide a rational interface to developers and users.
###@###.### 2003-07-30

======================================================================
                                     
2003-07-30



Hardware and Software, Engineered to Work Together