Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6438838
Votes 3
Synopsis (coll) Add Arrays.in(T e, T... elements)
Category java:classes_util
Reported Against
Release Fixed
State 5-Cause Known, request for enhancement
Priority: 4-Low
Related Bugs
Submit Date 14-JUN-2006
Description
A DESCRIPTION OF THE REQUEST :
Create a method to verify if an element is in a arrays of elements, like Collection.contains(). The code can be:

public static <T> boolean in(T e, T ... elements) {
	//An element wasnīt in an empty array
	if (elements==null || elements.length==0) {
		return false;
	}
	
	for (T t : elements) {
		if ( (e==null && t==null) || (t!=null && t.equals(e))) {
			return true;
		}
	}
	return false;
}


Example use code:

String[] names = {"Jose", "Joao", "Maria"};
if (java.util.Arrays.in("Jose", names) {
    //do something
}


Itīs can be modified to create an indexOf() instead.


JUSTIFICATION :
Some times we need to verify if an element is in a array of elements without sort it. The java.util.Arrays class provide method to search the element with binarySearch, but in search the array must be sorted.
Posted Date : 2006-06-14 22:24:29.0
Work Around
N/A
Evaluation
Doesn't really seem very compelling.
Does this feature "pull its weight"?

What about 

Arrays.asList(a).contains(x)

Probably will close as Will Not Fix.
Posted Date : 2006-06-14 23:26:57.0

From an SDN comment:

"The main objection to Arrays.asList(a).contains(x) is that it doesn't work on arrays of primitive types. (Even worse, it doesn't give an error in this case, it just fails silently.)

In addtion, Arrays.in() or Arrays.contains() would be more readable. I have wanted this feature several times."

The failure to work with primitive arrays is a good point.

The name "contains" seems more compelling than "in" for cognitive compatibility
with the Collection class.
Posted Date : 2006-09-03 02:52:40.0

Jason writes, very reasonably:

"I would think indexOf and lastIndexOf operations would be more useful than a contains operation.   Contains can be determined by checking the returned index as being non negative."

More generally, since an array can be regarded as a fixed-length List,
we could go through all of the List methods, and implement the usual
8 static methods in Arrays for every List operation that does not already
have an array equivalent or an Arrays set of static methods, and does not
change the length of the List.

If we do that, the obvious course of action is to add 3 sets of overloadings:

contains
indexOf
lastIndexOf

Other methods, such as hashCode, already have such sets of overloadings.

We should avoid doing anything for e.g. add, clear, remove, 
since, unlike the reading methods the expected semantics are unclear
(return a new modified array?) and it would encourage the writing of O(N*N)
algorithms for O(N) problems.
Posted Date : 2006-09-23 21:49:35.0
Comments
  
  Include a link with my name & email   

Submitted On 01-SEP-2006
axlrosen
The main objection to Arrays.asList(a).contains(x) is that it doesn't work on arrays of primitive types. (Even worse, it doesn't give an error in this case, it just fails silently.)

In addtion, Arrays.in() or Arrays.contains() would be more readable. I have wanted this feature several times.


Submitted On 22-SEP-2006
Jason-Mehrens
I would think indexOf and lastIndexOf operations would be more useful than a contains operation.   Contains can be determined by checking the returned index as being non negative.



PLEASE NOTE: JDK6 is formerly known as Project Mustang