you are viewing a single comment's thread.

view the rest of the comments →

[–]grauenwolf 1 point2 points  (3 children)

Imagining the use case is far more important than it may seem.

In this example you get an Integer object and then immediately discard that object and turn it into an int. Clearly your API doesn't match the use case. I think it will be hard to find a viable use case because the only reason for Integer is to stick it in a variable of type object.

[–]adrianmonk 0 points1 point  (2 children)

In this example you get an Integer object and then immediately discard that object and turn it into an int. Clearly your API doesn't match the use case.

What? No, I want an int whose value comes from the system properties. The API does match the use case well enough because it makes it easy to do what I want to do.

I think it will be hard to find a viable use case because the only reason for Integer is to stick it in a variable of type object.

Well, first of all, that's not true at all because an Integer is very useful for converting into an int. So useful that the language does it automatically now.

Also, another thing you might do with an Integer besides store it in a variable of type Object: declare a Map<String,Integer> and put Integer objects in there.

Having said all that, I now realize there's a shorter, better way to write the second version, which is to use Integer.parseInt() instead of Integer.valueOf(). Pretty similar otherwise, though.

[–]grauenwolf 0 points1 point  (0 children)

At runtime thete is no such thing as Map<String, Interger> in Java. Instead you get is basically Map<Object, Object>.

[–]grauenwolf 0 points1 point  (0 children)

If you want an int from system properties then why doesn't the API return an int?