0

I understand meaning of generic part of Class when we have Class<T>, but is there any diffrence between Class and Class<?> ? Or is there any way of casting Class<?> to, for example, Class<? extends T> ?

Krever
  • 1,371
  • 1
  • 13
  • 32

2 Answers2

2

About the difference Raw / <?>

is there any difference between Class and Class<?>?

There is indeed a difference between Raw Types and Unbounded Wildcards types.

You shouldn't use raw types. Basically, raw types are just legacy regarding Java before JDK 5.0, when there were no generics. They should be avoided, because some checks are not performed at compile time when using them, unlike unbounded wildcard types.

Collections example

The example of collections is the best example of a difference between raw type and unbounded wildcard type:

List listRaw = new LinkedList<Integer>();
List<?> listUnknown  = listRaw; // allowed at compile time

listRaw.add("blah blah");     // allowed at compile time
listUnknown.add("blah blah"); // compile error

And here, you won't have any runtime error, because of type erasure: generics are just syntax sugar to generate compile errors, but any list is just a list of objects at runtime.

Back to the Class example

For the type Class, I would say such problem is hardly noticeable, as no method in Class<T> takes a parameter of type T. Therefore, you won't have a method call that would raise a compile error with Class<?> but not with Class (well, I didn't find any case where that happens, I would be glad to hear it if someone finds one).

About the cast question

Or is there any way of casting Class<?> to, for example, Class<? extends T> ?

Casting is just a tool that allows you to tell the compiler that you know the runtime type of the class, in order to enable you to use methods that are specific to that type. What would you do with your object, once cast, that you couldn't do before casting it?

UPDATE: my reply to your comment

It isnt about functionality, but about type knowledge. When I get Class<? extends Foo> i know i can safely get methods of this interface by reflection.

I don't understand why you find it safer:

  • If the runtime type is right, you don't need the cast to use reflection.
  • If the runtime type is wrong, what's the difference for you betweeen handling the ClassCastException or handling the NoSuchMethodException?
Joffrey
  • 32,348
  • 6
  • 68
  • 100
  • I completly understand idea of generics and raw types. My problem is to specialize(cast) Class> in some checked way. – Krever May 16 '14 at 17:17
  • Ok I see your problem, but why would you need such a cast? Casting is basically nothing at runtime, so are generics. – Joffrey May 16 '14 at 17:24
  • Would you like your program to crash during your cast when you try to cast `Class>` to `Class extends Something>`? – Joffrey May 16 '14 at 17:26
  • I would like to ensure more type safty. For example from collection of Class> i would like to check which ones implement Foo and return new collection of Class extends Foo>. – Krever May 16 '14 at 17:30
  • You have a `getInterfaces` or `getSuperclass` method for that, though I'm no expert in using them ^^ – Joffrey May 16 '14 at 17:34
  • I don't think I can help you more on that, but I don't know why you would need such a behaviour in your project. You probably have other ways of accomplishing your main goal. What would you do on your new list that you couldn't on the previous list anyway? – Joffrey May 16 '14 at 17:38
  • It isnt about functionality, but about type knowledge. When I get Class extends Foo> i know i can safely get methods of this interface by reflection... – Krever May 16 '14 at 19:04
  • Reflection is intrinsically not about safety :) – Joffrey May 16 '14 at 21:47
  • I updated my answer to be clearer about what I meant. – Joffrey May 20 '14 at 13:03
  • You dont understand me probably. In one place I check class type with isAssignableFrom() and let go only this classess that confirm to my requirements. Then i pass list of it to another part of code where i would like not to worry about checking again... This would also make code more readable – Krever May 20 '14 at 16:11
0

It's known as an unbounded type parameter.

http://docs.oracle.com/javase/tutorial/java/generics/unboundedWildcards.html

Chad
  • 164
  • 10
  • 4
    They're very different. A `Class` means "a class of `Object`, exactly," while a `Class>` means "a class of some type." For instance, if you have a `List>`, you can't add a `Class>` to it. Similarly, `Class> c = Integer.class` compiles, but `Class c = Integer.class` doesn't. – yshavit May 16 '14 at 16:45
  • Okay, I've edited my original answer... Really?? A down vote? – Chad May 16 '14 at 17:00
  • 1
    Retracted the downvote. But yes, really, it was a downvote. The [voting guidelines](http://stackoverflow.com/help/privileges/vote-down) suggest downvotes for "an answer that is clearly and perhaps dangerously incorrect," and your answer was clearly incorrect. The myth that `Foo` and `Foo>` are the same is prevalent, and it needs to be corrected. If somebody came across your previous answer, saw the downvote, and read up on _why_ they're different, then the downvote did its job. Anyway, you corrected your answer, and so, no more downvote. – yshavit May 16 '14 at 17:09