Annotations and generic programming

Discussion in 'Java' started by kelvSYC, Apr 30, 2007.

  1. kelvSYC

    kelvSYC Guest

    Now, one of the big criticisms of type-erasure generic programming is
    that - well, it's type erasure generic programming: suppose you have

    public static <T> List<T> doStuff(){
    ...
    }

    Within the body of doStuff(), T.class is an error, and the only way to
    get what T stands for is to use that big backhoe that's reflection and
    somehow get a Class<T> object - which you would do by passing in a
    Class<T>, resulting in...

    public static <T> List<T> doStuff(Class<T> tClass) {
    ...
    }

    Now IMO T.class should really return a Class<T>, just like
    Integer.class gives you Class<Integer>, but I guess that other peoples
    opinions differed (I am not sure about the argument against it, so
    please explain to me what it is).

    Why do I mention this? It seems like annotations and annotation
    processing might be a means to an address this. (If I am wrong about
    annotations or annotation processing, please correct me). It seems
    like there should be an annotation processor that would take code of
    the former form and convert it to code of the latter form (the needed
    Class arguments would be the first arguments passed in).

    Am I ill-informed on this, and if not, is there such an annotation
    processor?
    kelvSYC, Apr 30, 2007
    #1
    1. Advertising

  2. kelvSYC

    Tom Hawtin Guest

    kelvSYC wrote:
    >
    > Now IMO T.class should really return a Class<T>, just like
    > Integer.class gives you Class<Integer>, but I guess that other peoples
    > opinions differed (I am not sure about the argument against it, so
    > please explain to me what it is).


    Existing code would not work if it made use of classes that had been
    generified. There could have been some system where T.class may or may
    not give you the Class, but that would make Java an even bigger language.

    > Why do I mention this? It seems like annotations and annotation
    > processing might be a means to an address this. (If I am wrong about
    > annotations or annotation processing, please correct me). It seems
    > like there should be an annotation processor that would take code of
    > the former form and convert it to code of the latter form (the needed
    > Class arguments would be the first arguments passed in).


    No. No part of the code you quoted actually specifies the class of T.
    There is no way an annotation processor could get that information.

    Tom Hawtin
    Tom Hawtin, Apr 30, 2007
    #2
    1. Advertising

  3. kelvSYC

    Daniel Pitts Guest

    On Apr 29, 10:18 pm, kelvSYC <> wrote:
    > Now, one of the big criticisms of type-erasure generic programming is
    > that - well, it's type erasure generic programming: suppose you have
    >
    > public static <T> List<T> doStuff(){
    > ...
    >
    > }
    >
    > Within the body of doStuff(), T.class is an error, and the only way to
    > get what T stands for is to use that big backhoe that's reflection and
    > somehow get a Class<T> object - which you would do by passing in a
    > Class<T>, resulting in...
    >
    > public static <T> List<T> doStuff(Class<T> tClass) {
    > ...
    >
    > }


    Its not hard to do this anyway.
    List<Foo> foos = doStuff(Foo.class);

    If you wanted to take T.class, thats as much reflection as Foo.class,
    although it does put it in the client code.

    >
    > Now IMO T.class should really return a Class<T>, just like
    > Integer.class gives you Class<Integer>, but I guess that other peoples
    > opinions differed (I am not sure about the argument against it, so
    > please explain to me what it is).


    The argument is that T is not a real type, but a type holder.
    Integer.class is a static constant, T.class could not be a constant,
    since T could represent Integer or FooBob.


    > Why do I mention this? It seems like annotations and annotation
    > processing might be a means to an address this. (If I am wrong about
    > annotations or annotation processing, please correct me). It seems
    > like there should be an annotation processor that would take code of
    > the former form and convert it to code of the latter form (the needed
    > Class arguments would be the first arguments passed in).

    Annotation processors take "@Annotation" annotations, and process
    them. There is no @Annotation in your code anywhere...

    Again, the type of T us up to the caller of doStuff, so you would have
    to know all of the callers before hand. This is not a possible task,
    as the calling code could be written and compiled after the fact.

    > Am I ill-informed on this, and if not, is there such an annotation
    > processor?


    There are annotation processors, and also reflection based frameworks
    which use annotations. They however are no use to your problem.

    It is considered appropriate to pass Class<T> type into methods as a
    type token. It even gives you the ability to call type.cast() if you
    need to.
    Daniel Pitts, Apr 30, 2007
    #3
  4. kelvSYC

    Tom Hawtin Guest

    Daniel Pitts wrote:
    > Annotation processors take "@Annotation" annotations, and process
    > them. There is no @Annotation in your code anywhere...


    That's not necessary. Annotation processors can run on unannotated code,
    deriving information through conventions and defaults.

    Tom Hawtin
    Tom Hawtin, Apr 30, 2007
    #4
  5. kelvSYC

    Daniel Pitts Guest

    On Apr 30, 10:12 am, Tom Hawtin <> wrote:
    > Daniel Pitts wrote:
    > > Annotation processors take "@Annotation" annotations, and process
    > > them. There is no @Annotation in your code anywhere...

    >
    > That's not necessary. Annotation processors can run on unannotated code,
    > deriving information through conventions and defaults.
    >
    > Tom Hawtin


    True, but its still no solution to the OPs problem.
    Daniel Pitts, Apr 30, 2007
    #5
  6. kelvSYC wrote:
    > Within the body of doStuff(), T.class is an error, and the only way to
    > get what T stands for is to use that big backhoe that's reflection and
    > somehow get a Class<T> object - which you would do by passing in a
    > Class<T>, resulting in...


    What about T.getClass()?
    Joshua Cranmer, May 1, 2007
    #6
  7. kelvSYC

    kelvSYC Guest

    On May 1, 3:43 pm, Joshua Cranmer <> wrote:
    > kelvSYC wrote:
    > > Within the body of doStuff(), T.class is an error, and the only way to
    > > get what T stands for is to use that big backhoe that's reflection and
    > > somehow get a Class<T> object - which you would do by passing in a
    > > Class<T>, resulting in...

    >
    > What about T.getClass()?


    T is a type variable. getClass() works in instances. If I passed in
    an instance of T in my code, then we wouldn't need to pass in the
    Class<T>. However, that's a big if...
    kelvSYC, May 3, 2007
    #7
  8. kelvSYC

    Daniel Pitts Guest

    On May 2, 6:35 pm, kelvSYC <> wrote:
    > On May 1, 3:43 pm, Joshua Cranmer <> wrote:
    >
    > > kelvSYC wrote:
    > > > Within the body of doStuff(), T.class is an error, and the only way to
    > > > get what T stands for is to use that big backhoe that's reflection and
    > > > somehow get a Class<T> object - which you would do by passing in a
    > > > Class<T>, resulting in...

    >
    > > What about T.getClass()?

    >
    > T is a type variable. getClass() works in instances. If I passed in
    > an instance of T in my code, then we wouldn't need to pass in the
    > Class<T>. However, that's a big if...


    How would T.class be any less reflective than tObject.getClass()?
    What are you hoping to accomplish?
    Daniel Pitts, May 3, 2007
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Murat Tasan
    Replies:
    1
    Views:
    8,042
    Chaitanya
    Feb 3, 2009
  2. Vidar S. Ramdal

    Annotations and Retention

    Vidar S. Ramdal, Aug 18, 2005, in forum: Java
    Replies:
    2
    Views:
    661
    Vidar S. Ramdal
    Aug 19, 2005
  3. Replies:
    2
    Views:
    435
  4. G.
    Replies:
    3
    Views:
    366
  5. minlearn
    Replies:
    2
    Views:
    454
    red floyd
    Mar 13, 2009
Loading...

Share This Page