Integer.getInteger. Are you kidding me?

Photos and diary are on haitus. Now a little technology.

I just discovered a method introduced in Java 5: the method Integer.getInteger(String):

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Integer.html#getInteger(java.lang.String)

Determines the integer value of the system property with the specified name.

The first argument is treated as the name of a system property. System properties are accessible through the System.getProperty(java.lang.String) method. The string value of this property is then interpreted as an integer value and an Integer object representing this value is returned. Details of possible numeric formats can be found with the definition of getProperty.

So let me see if I understand:

• Integer.valueOf(String) converts a String to a number by assuming the String is a numeric representation. In other words. Integer.valueOf("12345") yields the number 12345.
• Integer.getInteger(String) converts a String to a number by assuming the String is the name of a system property numeric representation. In other words. Integer.getInteger("12345") is likely to yield null.

Why would anybody consider this a sufficient distinction? How many bugs are people going to create by using getInteger when they meant valueOf and vice versa?

This type of overloading is called near-phrase overloading. I just made that term up right now. It's when people use very similar words to mean different things. Consider two words x and y, their general meanings gm(x) and gm(y), and their meanings in a given context, cm(x) and cm(y). If

distance(gm(x), gm(y))< distance(cm(x), cm(y))

then it's a bad use of x and y! Go find another x and y for their contextual uses. Really, they could have called it getIntegerProperty.

This is the worst case of avoidable ambiguity I've seen in Java; I expect better coming out of them.

Update: it turns out there is something worse: Boolean.getBoolean("true") is usually equal to Boolean.FALSE.