Why support for both int.class and Integer.TYPE?  
Index ‹ java-programmer
Author Message
trin
PostPosted: 2003-9-5 4:47:00 Top
java-programmer, Why support for both int.class and Integer.TYPE? Years ago, when I first searched on how to get the class for a
primitive type, I learned the Integer.TYPE convention. At the time, I
assumed this was the only way, but it turns out it was the first way I
happened to find in my search results. You can also do int.class.

But why support both?

The Integer.TYPE javadocs say it's been around since JDK 1.1. I did
some Googling and found that the universal ".class" notation has also
been around since JDK 1.1. I could understand if one pre-dated the
other and they wanted to later add a better solution and not get rid
of the old one, but that doesn't appear to be the case.

So, again, why did we reach the point where both are supported?

Regards,
Brian.
 
Chris Uppal
PostPosted: 2003-9-5 16:32:00 Top
java-programmer >> Why support for both int.class and Integer.TYPE? Brian J. Sayatovic wrote:
> Years ago, when I first searched on how to get the class for a
> primitive type, I learned the Integer.TYPE convention. At the time, I
> assumed this was the only way, but it turns out it was the first way I
> happened to find in my search results. You can also do int.class.
>
> But why support both?

The int.class expression is a hack introduced in the compiler which expands it
to Integer.TYPE.

There are a number of such hacks, some have real value, some are debatable,
some are clearly mistakes. I'd put int.class somewhere between the first two:
there is no real need for it but it does maintain consistancy with the
<classname>.class syntax that was introduced at the same time* (itself a hack,
of course, but probably worthwhile -- at least if you like the kitchen-sink
approach to language design).

*Real* Java -- by which I mean "what the JVM sees" -- has no such construction.

-- chris

[*] In java 1.2, IIRC (which is doubtfull).


 
 
Index ‹ java-programmer