How can I convert int[] to Integer[] in Java?

Question

I'm new to Java and very confused.

I have a large dataset of length 4 int[] and I want to count the number of times that each particular combination of 4 integers occurs. This is very similar to counting word frequencies in a document.

I want to create a Map<int[], double> that maps each int[] to a running count as the list is iterated over, but Map doesn't take primitive types.

So I made Map<Integer[], Double>.

My data is stored as an ArrayList<int[]>, so my loop should be something like:

ArrayList<int[]> data = ... // load a dataset`

Map<Integer[], Double> frequencies = new HashMap<Integer[], Double>();

for(int[] q : data) {

    // **DO SOMETHING TO convert q from int[] to Integer[] so I can put it in the map

    if(frequencies.containsKey(q)) {
    frequencies.put(q, tfs.get(q) + p);
    } else {
        frequencies.put(q, p);
    }
}

I'm not sure what code I need at the comment to make this work to convert an int[] to an Integer[]. Or maybe I'm fundamentally confused about the right way to do this.

Solution 1

Native Java 8 (one line)

With Java 8, int[] can be converted to Integer[] easily:

int[] data = {1,2,3,4,5,6,7,8,9,10};

// To boxed array
Integer[] what = Arrays.stream( data ).boxed().toArray( Integer[]::new );
Integer[] ever = IntStream.of( data ).boxed().toArray( Integer[]::new );

// To boxed list
List<Integer> you  = Arrays.stream( data ).boxed().collect( Collectors.toList() );
List<Integer> like = IntStream.of( data ).boxed().collect( Collectors.toList() );

As others stated, Integer[] is usually not a good map key. But as far as conversion goes, we now have a relatively clean and native code.

Solution 2

If you want to convert an int[] to an Integer[], there isn't an automated way to do it in the JDK. However, you can do something like this:

int[] oldArray;

... // Here you would assign and fill oldArray

Integer[] newArray = new Integer[oldArray.length];
int i = 0;
for (int value : oldArray) {
    newArray[i++] = Integer.valueOf(value);
}

If you have access to the Apache lang library, then you can use the ArrayUtils.toObject(int[]) method like this:

Integer[] newArray = ArrayUtils.toObject(oldArray);

Solution 3

Convert int[] to Integer[]:

    import java.util.Arrays;
    ...

    int[] aint = {1,2,3,4,5,6,7,8,9,10};
    Integer[] aInt = new Integer[aint.length];

    Arrays.setAll(aInt, i -> aint[i]);

Solution 4

Using regular for-loop without external libraries:

Convert int[] to Integer[]:

int[] primitiveArray = {1, 2, 3, 4, 5};
Integer[] objectArray = new Integer[primitiveArray.length];

for(int ctr = 0; ctr < primitiveArray.length; ctr++) {
    objectArray[ctr] = Integer.valueOf(primitiveArray[ctr]); // returns Integer value
}

Convert Integer[] to int[]:

Integer[] objectArray = {1, 2, 3, 4, 5};
int[] primitiveArray = new int[objectArray.length];

for(int ctr = 0; ctr < objectArray.length; ctr++) {
    primitiveArray[ctr] = objectArray[ctr].intValue(); // returns int value
}

Solution 5

Presumably you want the key to the map to match on the value of the elements instead of the identity of the array. In that case you want some kind of object that defines equals and hashCode as you would expect. Easiest is to convert to a List<Integer>, either an ArrayList or better use Arrays.asList. Better than that you can introduce a class that represents the data (similar to java.awt.Rectangle but I recommend making the variables private final, and the class final too).

View more solutions

Comments

[newacct]

"I want to create a Map<int[], double> ... but Map doesn't take primitive types." As one of the posts below pointed out, int[] is not a primitive type, so that is not the real problem. The real problem is that arrays do not override .equals() to compare the elements. In that sense converting to Integer[] (as your title says) does not help you. In the code above, frequencies.containsKey(q) would still not work as you expect because it uses .equals() to compare. The real solution is to not use arrays here.

[Mureinik]

Don't want to spam with another answer, but worth noting there's now a documentation example about this.

[Admin]

Many thanks for your reply I tried this first and it compiled fine, but it seems like frequencies.containsKey(q) would always be false even if I've put the same array twice - is there some glitch here involving java's definition of equality with int[]'s?

[Brett]

Oh, here's an array conversion question, just the other way around: stackoverflow.com/questions/564392/…

[Brett]

(Hint, (new int[0]).equals(new int[0]) is false; (new ArrayList<Integer>()).equals(new ArrayList<String>()) is true.

[sleske]

Bad idea, as array comparison is based on reference equality. That's why Arrays.equals() exists...

[Brett]

I'd make the class final, and the field private final. Make a defensive copy of the array in the constructor (clone). And just return the value from Arrays.equals rather than have that peculiar if statement. toString would be nice.

[Brett]

Oh and throw an NPE from the constructor (probably calling clone) for null data, and not have the check in hashCode.

[Mihai Toader]

True .. But the code for equals, hashCode is generated by IDEA :-). It works correctly.

[James Becwar]

thats a nasty way to do a for loop.

[Dahaka]

This is a perfectly normal for each... I don't see the nasty part.

[lcn]

@Dahaka, the nastiness is in using an iterator of value while the indexing variable i is there.

[Eddie]

@Icn, I can see why some people wouldn't prefer that style, but what makes it so undesirable as to be nasty?

[eldur]

With Guava I would prefer List<Integer> intList = Ints.asList(oldArray);

[Zero3]

I don't see much value in keeping this answer "for reference" when it doesn't work. The documentation for System.arraycopy() even states that it won't work for this purpose.

[daiscog]

@icn, @Dahaka: The nastiness is that since you're already using an incrementing index variable, there's no need to use a for-each, too; although it looks pretty and simple in the code, behind the scenes that involves unnecessary overhead. A traditional for (int i...) loop would be more efficient here.

[aw-think]

That's meanwhile the correct way. If you need the Integer-Array as a list you could write: List<Integer> list = IntStream.of(q).boxed().collect(Collectors.toList());

[YoYo]

to convert to an Integer[] I would actually suggest using following syntax: Integer[] boxed = IntStream.of(unboxed).boxed().toArray(); In the similar fashion as @NwDx

[Sheepy]

@JoD. Yes, that works. But IntStream.of calls Arrays.stream anyway. I think it comes down to personal preference - I prefer one overridden function, some love using more explicit class.

[YoYo]

Fix the signature of toArray in your example, and then we are in agreement. As a matter of fact, I might prefer your version instead.

[Sheepy]

@JoD. Yes it is sad. But as long as the stream is boxed (i.e. not an IntStream), toArray will always need a constructor, regardless of the source.

[Sheepy]

@JoD. I got compilation error Object[] cannot be converted to Integer[]. Both on my pc and on ideone: ideone.com/uagsSd

[aw-think]

@Sheepy: I prefer the usage of IntStream, because it is more related to the type of data in that stream. The Arrays class is more to manipulate arrays and not streams (even if some methods create streams). So if a third person is reading your code, he/she exactly knows whats going on. It's more readable to say: Make an IntStream of that int array, box it, and make an array or collect a list. As if you say: Arrays make a stream from that int array (what type of?) and box it (to what?). But all of this is a matter of taste.

[YoYo]

I am eating my shoe. I was simply wrong - I thought I tried it out, but obviously didn't. boxed(), just returns a typed Stream<Integer>, but still needs a typed array generator for the toArray to return the correctly typed Array, otherwise it is going to be Object[]. I guess that has it benefits too, plus there is probably no other way.

[Sheepy]

Thanks for supporting JoD. I start from the parameter type which is an array, and it is uniform as you an handle most arrays with one function. But I just figured that I can add both syntaxes in the answer :p @NwDx

[YoYo]

@NwDx somehow I also instinctively use IntStream.of, but I think Arrays.stream will be favored by many because it's type neutrality due to the overloading.

[aw-think]

@JoD. Full ack. If one don't know the type of data than he/she is not able to create an Array of Integer, as you need the type of data for creation. Only untyped lists with the collectors are possible. Or am I wrong?

[YoYo]

We need to think JEP 169 where explicit primitive typed classes will be likely deprecated.

[Sheepy]

@JoD. I do not see where did JEP 169 mention deprecation of boxed primitive class. Plus it has low priority and progress is non-existent.

[Sheepy]

@NwDx Well, compared with Arrays.stream, IntStream.of and other primitive streams also require you to know the data type. In fact if the data type change, the later just result in more code change.

[YoYo]

@Sheepy part of project Valhalla. The deprecation was just my interpolation of things to come.

[Holger]

This IntArrayWrapper definitely is the right approach for using an int[] array as hash key, but it should be mentioned that such a type already exists… You can use it to wrap an array and not only has it hashCode and equals, it’s even comparable.

[Globox]

Can this be applied to 2D array? Can int[][] data converted to Integer[][] whatever?

[Sheepy]

@Chetan It is possible to apply to multiple dimensions, but I strongly advise against it (better use proper loop), because this approach doesn't scale at all: Integer[][] newData = Arrays.stream( data ).map( row -> Arrays.stream( row ).boxed().toArray( Integer[]::new ) ).toArray( Integer[][]::new ) -

[Eel Lee]

This is rather inaccurate due to autoboxing. In 1st example you can simply do newArray[i] = ids[i]; and in 2nd one newArray[i] = WrapperArray[i] :)

[Vijay Chavda]

What is this new syntax: Integer[]::new?

[Sheepy]

@VijayChavda The new syntax, called method references, was introduced in 2014 with Java 8 as part of lambda (JSR 335 Part C). It means the "new" method (constructor) of the Integer[] class.

[forkdbloke]

Hi Tunaki, can you please explaing the above code for me? when i run through debugger, i see that get and size method gets called automatically, i.e with out them being called explicitely !! how so?! can you please explain?

[mcvkr]

I saw almost same nastiness in our professor's solution to a homework, it was in C, 17 years ago. My experience showed me almost never trying to write some code shorter really helps anymore.

[mcvkr]

want to see something as nasty : stackoverflow.com/questions/1642028/…

[Peter Mortensen]

Even if it worked like a charm, an explanation would be in order. E.g., what is the idea/gist? On what system (incl. versions) and with what version of Java was it tested on? From the Help Center: "...always explain why the solution you're presenting is appropriate and how it works". Please respond by editing (changing) your answer, not here in comments (without "Edit:", "Update:", or similar - the answer should appear as if it was written today).