File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes int[] to Set<Integer> -- no direct methods, right? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "int[] to Set<Integer> -- no direct methods, right?" Watch "int[] to Set<Integer> -- no direct methods, right?" New topic
Author

int[] to Set<Integer> -- no direct methods, right?

Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1049
    
  15
Hi,

I have a method that returns an int[]. I need to check if this int array ( unsorted ) contains a few numbers.

I guess the Collection API( Java 1.6) does not have anything like Arrays.asList(<the array>) that can convert an int[] to a Set<Integer> or to a List<Integer> or to even an Integer[]. Or would it?

If not, then the only way I have is to scan the array element by element and then check if it has those numbers. Right?

Would you know of an alternative or a better approach. Let me know if I should provide more details.

Thanks.




Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1049
    
  15
Chan Ag wrote:
If not, then the only way I have is to scan the array element by element and then check if it has those numbers. Right?



Not quite. I can scan the array in a loop to add the elements to a Set<Integer>. Then the look up will become easier.

I guess there are no direct methods in Java 1.6 for converting an int[] to a Set<Integer>. I think I can write a utility method that will do this.

Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

Chan Ag wrote:Would you know of an alternative or a better approach. Let me know if I should provide more details.

Well, one that springs to mind would be to have your method return an Integer[] (or - possibly even better - a List<Integer>). Then you can use Arrays.asList() (or nothing at all). Personally, I rarely use primitive arrays these days, unless I know I'm going to be doing a lot of modification on it; and I certainly try to avoid returning them from public APIs, for exactly the reasons you're running into.

HIH

Winston

PS: It seems that you've answered your own question. Is this some sort of "personal dialogue"?

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1049
    
  15
Thanks for responding, Winston.

Actually I wished I could change that method to return an Integer[]. But we have the code freeze period now. Also I think otherwise also my seniors won't allow me to change this method. It is called by many methods in the application. I'm currently writing a test case that must invoke this method. And the validation needs to be done on some expected int values. I'll keep this point in mind though while coding a method that must return more than one integers.

P.S - Nope, I didn't intend it to be a personal dialogue but it turned out to be one, I guess. I was just a little unsure. And many times I have seen that there are smart techniques that I am not aware of but that others know of. So I posted my question here although I was almost sure that Java 6 does not have any such method. Then I chanced upon this topic in StackOverflow.com. So that answered a part of my question. I should have browsed better before posting my question. :-) I'll do that next time. :-)
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

Chan Ag wrote:Thanks for responding, Winston.
Actually I wished I could change that method to return an Integer[]. But we have the code freeze period now...I'll keep this point in mind though while coding a method that must return more than one integers.

Ah, good old change control...

Just FYI, I've found a fairly good rule of thumb is "once an Integer, always an Integer" - ie, once you have an Integer, don't convert it back to a primitive unless you absolutely have to. The performance hit you get from combining the two is generally when you're constantly switching back and forth (and it can be quite significant).

So, if you have a List<Integer>, avoid statements like:
int i = intList.get(n);

and if you need a mutable integer object, there's always AtomicInteger; although I also have a couple of specialised ones of my own, like Count.

Nope, I didn't intend it to be a personal dialogue but it turned out to be one, I guess.

No probs, I often talk to myself when I've got noone to bounce ideas off. You just did it in written form.

Winston
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39788
    
  28
Don't they call that rubber duck programming?
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1049
    
  15
Thanks, Winston. I'll remember that as well. Sorry, I can't quote your post right now. I think for converting Integer to an int, the right way ( at least till Java 7 ) is to get the Integer, do the null check, and then use one of the Integer class methods like intValue.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

Chan Ag wrote:I think for converting Integer to an int, the right way ( at least till Java 7 ) is to get the Integer, do the null check, and then use one of the Integer class methods like intValue.

Sure, or just unbox. The latter has the advantage that it will almost certainly use the correct method for conversion.

And nulls? That's a tricky one; and in the absence of any other requirement, my inclination is to just let the method throw an NPE.

Alternatively, you could create a "default":although some people might call it overkill.
The thing is, you could then use it as a "policy" for a utility method, viz:As always with this stuff, it's just one way to do it though.

However, I thought your question was about converting the other way.

Winston
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1049
    
  15
Winston Gutkowski wrote:
However, I thought your question was about converting the other way.

Winston


Yeah, but that's not important. I liked the generic Default class a lot. Neat, really. I so wish to use your idea somewhere. I mean not just for nulls...

I mean the idea of having these generic classes/interfaces that define the generic policies for your implementation -- whether it be how to handle nulls, certain exceptional conditions, uncaught exceptions -- is really cool.

I will think through it and try to come up with better ways to implement things I have implemented. Thanks a lot.

And yes, I didn't miss the part about unboxing always using the correct method for conversion.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: int[] to Set<Integer> -- no direct methods, right?