Why support for both int.class and Integer.TYPE?

Discussion in 'Java' started by Brian J. Sayatovic, Sep 4, 2003.

  1. 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.
     
    Brian J. Sayatovic, Sep 4, 2003
    #1
    1. Advertisements

  2. Brian J. Sayatovic

    Chris Uppal Guest

    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).
     
    Chris Uppal, Sep 5, 2003
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.