Integer.getInteger() why there?

[Yogo]

Hello,

There are in the Integer wrapper class methods named getInteger which return
an Integer containing a system property value.

Now, I really wonder what a system property method does in the Integer
wrapper class? Shouldn't these methods be in the System class or the
Properties class??? The methods are not deprecated so I guess there is / was
a good reason to put them there but I really can't think of any.

Yogo

 

[Paul Lutus]

Hello,

There are in the Integer wrapper class methods named getInteger which
return an Integer containing a system property value.

Now, I really wonder what a system property method does in the Integer
wrapper class? Shouldn't these methods be in the System class or the
Properties class??? The methods are not deprecated so I guess there is /
was a good reason to put them there but I really can't think of any.

They are located as they are because they have to do with the behavior of
Integer instances. They are system properties because they can change from
platform to platform. So you see, an argument can be made for their
location in either class, but on its merits, the present location won out
over the alternative.

 

[Yogo]

They are located as they are because they have to do with the behavior of

Integer instances.

Hmm, what do you mean?

I can create a system property with any name I want that holds whatever
int-value I want.

The getInteger method just calls the System.getProperty method and converts
the returned String to an Integer.

What does this have to do with the behavior of Integers?


Yogo

 

[Paul Lutus]

Hmm, what do you mean?

The returned value is an Integer instance. So it makes sense that the method
is located in the Integer class.

I can create a system property with any name I want that holds whatever
int-value I want.

But these properties are returned as Integer instances. It is obvious that
they should be located in the Integer class.

 

[andreas kinell]

Hmm, what do you mean?

I can create a system property with any name I want that holds whatever
int-value I want.

The getInteger method just calls the System.getProperty method and
converts the returned String to an Integer.

What does this have to do with the behavior of Integers?

it clearly doesn't belong to the System class.
also, there is no Property class. if there was a class Property, one could
argue that
getInteger(String nm) should be a method of Property rather than of Integer.

why isn't it in class Properties? because Properties extends a HashTable for
(String, String) pairs. key and value are Strings, Integer has nothing to do
with it.

instead, methods extracting an Integer from a String are static methods of
Integer.
following your argumentation,

static Integer decode(String nm)
static Integer valueOf(String s)

should be offered by String.


andreas

 

[Jacob]

The returned value is an Integer instance. So it makes sense that the method
is located in the Integer class.

If this was a general principle Integer would end as
a mighty class (not to mention String...)

Actually Yogo is quite right. The methods mentioned has
absolutely nothing to do with "Integerness". Having a
general Integer class that knows about "System" is simply
very bad modelling.

Also the methods have wrong names ("getInteger" instead of
"getSystemProperty") and the public parameters have bad
names ("nm" instead of "name" (or "key" as it is called
in System) and "val" instead of "defaultValue").

The correct solution would be to keep this logic along with
the general (String based) getProperty. To make it complete
there should also be a double version even if there are
currently no floating point properties.

Class System:

String getProperty (String key)
String getProperty (String key, String defaultValue)
Integer getPropertyAsInteger (String key)
Integer getPropertyAsInteger (String key, int defaultValue)
Double getPropertyAsDouble (String key)
Double getPropertyAsDouble (String key double defaultValue)

I see no reason for the integer version taking an Integer as
input as default value (as it does today in Integer). The one
with int is sufficient as the method _without_ default value
parameter handles the null case. Same with double.

For the exception handling I am in doubt. The current version
returns null if the property value exists but cannot be correctly
converted to an int. It would probably be conceptually more
correct to throw a NumberFormatException instead, even if this
makes the method more cumbersome to use.