Java Vector or ArrayList for Primitives

Question

Is there an expandable array class in the Java API equivalent to the Vector or ArrayList class that can be used with primitives (int, char, double, etc)?

I need a quick, expandable array for integers and it seems wasteful to have to wrap them in the Integer class in order to use them with Vector or ArrayList. My google-fu is failing me.

Solution 1

There is unfortunately no such class, at least in the Java API. There is the Primitive Collections for Java 3rd-party product.

It's pretty dangerous to use auto-boxing together with existing collection classes (in particular List implementations). For example:

List<Integer> l = new ArrayList<Integer>();
l.add(4);

l.remove(4); //will throw ArrayIndexOutOfBoundsException
l.remove(new Integer(4)); //what you probably intended!

And it is also a common source of mysterious NullPointerExceptions accessing (perhaps via a Map):

Map<String, Integer> m = new HashMap<String, Integer>();
m.put("Hello", 5);
int i = m.get("Helo Misspelt"); //will throw a NullPointerException

Solution 2

http://trove4j.sourceforge.net/

The Trove library provides high speed regular and primitive collections for Java.

Note that because Trove uses primitives, the types it defines do not implement the java.util collections interfaces.

(LGPL license)

Solution 3

Modern Java supports autoboxing of primitives, so you can say

List<Integer> lst = new ArrayList<Integer>;
lst.add(42);

That at least avoids the syntactic vinegar of new Integer(42).

Solution 4

Joda-Primitives.

There is also Primitive Collections for Java but it's a bit out of date.

Solution 5

Eclipse Collections has primitive ArrayLists for all primitive types, as well as primitive Sets, Bags, Stacks and Maps. There are immutable versions of all of the primitive container types as well.

Note: I am a committer for Eclipse Collections.

View more solutions

Comments

[kevinarpe]

+1 for "My google-fu is failing me."

[Daniel Bingham]

This is for commercial software development. While I think we're okay to use LGPL'd code I'd have to check with people, and in that case it'd probably be easier to just write my own class. I'll make note of the library for future Open Source stuff I write though, thanks!

[oxbow_lakes]

This is dangerous (reasons given below)

[skaffman]

If LGPL is off-limits, that rules out the a very large proportion of open-source libraries. What were you expecting?

[Daniel Bingham]

Just needed to know whether or not I was missing something in the JDK. LGPL isn't off limits, but I can write my own class in this case in less time than it would take to get the okay on the library, get it integrated and then write the code using it.

[Daniel Bingham]

So in other words, use one of the third party libraries or write your own. Got it, thanks! :)

[Thom Smith]

Indeed -- some methods of Java collections are overloaded, and when autoboxing is involved, Java may resolve invocations that are conceptually ambiguous by selecting the non-autoboxed option rather than generating a compile-time error. Conceptually, the reason for this is that int and Integer are isomorphic, but there exists no subtype relationship between them. This kind of relationship exists nowhere else in Java but autoboxing (and a few esoteric issues with generics and type erasure).

[starblue]

new Integer(42) is the wrong thing to do, use Integer.valueOf(42) for boxing.

[Thom Smith]

The nice thing about autoboxing is that I don't have to remember that. ;-)

[Admin]

+ 1 for the remove(4) remove(new Integer(4)) example!

[Stephan]

Primitive Collections for Java has been flagged as deleted on SourceForge.

[Ayushi Jain]

@oxbow_lakes why does l.remove throws a error? What is the reason behind this?

[Pradeep Gollakota]

@ayushi it's because List has two remove() methods. remove(int) and remove(E)... l.remove(4) says "remove the fourth element of the list". Whereas, l.remove(new Integer(4)) says "remove the first occurrence of '4' in the list wherever that is". Check out the linked java docs for more detailed info.

[Ayushi Jain]

@PradeepGollakota Thanks for the answer.. Recently, I got a detailed answer over here

[Roshana Pitigala]

Just to make things clear, the NullPointerException thrown in line int i = m.get("Helo Misspelt"); is not because of the get() method cannot find the key in the Map, but because of the auto-unboxing which happens while trying to assign the Integer value to primitive int. Integer i = m.get("Helo Misspelt"); will not throw a NullPointerException.

[delrocco]

I've never heard the term syntactic vinegar before. Can't wait to use that. Thanks!