JDK-4341785 : unix: List.select(-1) method invocation leads to unexpected result.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.1.7,1.3.0,1.4.0,1.4.1,1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,solaris_7,solaris_8,windows_98
  • CPU: x86,sparc,itanium
  • Submitted: 2000-05-29
  • Updated: 2017-05-16
  • Resolved: 2003-08-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
5.0 tigerFixed
Related Reports
Duplicate :  

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.
              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");
        Panel aPanel = new Panel();

    public static void main(String [] argv)
        test t = new test();

    public void actionPerformed(ActionEvent e) {
        System.out.println("Selected item is " + aList.getSelectedIndex());
        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.


CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b15 VERIFIED IN: tiger

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 ======================================================================