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