Why is using Collection.class illegal?

Question

I am puzzled by generics. You can declare a field like:

Class<Collection<String>> clazz = ...

It seems logical that you could assign this field with:

Class<Collection<String>> clazz = Collection<String>.class;

However, this generates an error:

Syntax error on token ">", void expected after this token

So it looks like the .class operator does not work with generics. So I tried:

  class A<S> { }
  class B extends A<String> { }
  Class<A<String>> c = B.class;

Also does not work, generates:

Type mismatch: cannot convert from Class<Test.StringCollection> to Class<Collection<String>>

Now, I really fail to see why this should not work. I know generic types are not reified, but in both cases it seems to be fully type safe without having access to runtime generic types. Anybody an idea?

See http://stackoverflow.com/questions/2012306/how-to-create-expressions-of-type-classlist — skaffman, Apr 30 '10 at 14:32

score 36 · Answer 1 · edited Jun 20 '20 at 09:12

36

Generics are invariant.

Object o = "someString"; // FINE!
Class<Object> klazz = String.class; // DOESN'T COMPILE!
// cannot convert from Class<String> to Class<Object>

Depending on what it is that you need, you may be able to use wildcards.

Class<? extends Number> klazz = Integer.class; // FINE!

Or perhaps you need something like this:

Class<List<String>> klazz =
   (Class<List<String>>) new ArrayList<String>().getClass();
// WARNING! Type safety: Unchecked cast from
//   Class<capture#1-of ? extends ArrayList> to Class<List<String>>

As for the non-reified at run-time case, you seem to have a good grasp, but here's a quote anyway, from the Java Tutorials on Generics, The Fine Print: A Generic Class is Shared by All Its Invocations:

What does the following code fragment print?
List <String> l1 = new ArrayList<String>();
List<Integer> l2 = new ArrayList<Integer>();
System.out.println(l1.getClass() == l2.getClass());
You might be tempted to say false, but you'd be wrong. It prints true, because all instances of a generic class have the same run-time class, regardless of their actual type parameters.

That is, there's no such thing as List<String>.class or List<Integer>.class; there's only List.class.

This is also reflected in the JLS 15.8.2 Class Literals

A class literal is an expression consisting of the name of a class, interface, array, or primitive type, or the pseudo-type void, followed by a . and the token class.

Note the omission of any allowance for generic type parameters/arguments. Furthermore,

It is a compile time error if any of the following occur:

The named type is a type variable or a parameterized type, or an array whose element type is a type variable or parameterized type.

That is, this also doesn't compile:

void <T> test() {
    Class<?> klazz = T.class; // DOESN'T COMPILE!
    // Illegal class literal for the type parameter T
}

Basically you can't use generics with class literals, because it just doesn't make sense: they're non-reified.

edited Jun 20 '20 at 09:12

Community

1
1

answered Apr 30 '10 at 14:35

polygenelubricants

376,812
128
561
623

Hmm, I think I understand variance and its pitfalls but I fail to see this is relevant here the case here? Notice that a field like: Class> s; is perfectly legal. It is the assignment that fails for mysterious reasons. – Peter Kriens Apr 30 '10 at 14:51
1

Actually, the invariance was the trick: Class extends A> b = B.class worked. Thinks. Guess did not fully understand the invariant yet even after all that time. – Peter Kriens Apr 30 '10 at 15:01
1

@Peter: class literals aren't types. Many genericized types, which are invariant and not assignment-compatible among each other, really are instances of the same class at run-time. It doesn't make any sense to allow generics for class literals. – polygenelubricants Apr 30 '10 at 15:19
2

@Peter: You said "Actually, the invariance was the trick" -- more accurately, using (bounded) wildcards is the "trick". You should read more about how they're used, the PECS (Producer Extends Consumer Super) principle and what it facilitates, etc. – polygenelubricants Apr 30 '10 at 15:23
I still do not understand why Class> cannot be assigned with a literal A.class? while class B extends A {} allows Class extends A> z = B.class. This is in certain cases useful to enforce type consistency. – Peter Kriens May 01 '10 at 09:09
@polygenelubricants "Basically you can't use generics with class literals, because it just doesn't make sense: they're non-reified." Yes I understand erasure but they do make sense in certain cases bu enforcing type constraints during compile. For example: ~~ArrayList ~~test(Class> c) { return new ArrayList~~(100); } Just have no clue how to set this class.~~~~~~ – Peter Kriens May 01 '10 at 09:17
@Peter: see the linked question for more discussion. – polygenelubricants May 01 '10 at 09:22
Instead of `(Class>) new ArrayList().getClass()`, you can do `(Class>) (Class>) List.class`. – trustin May 12 '12 at 14:21

score 1 · Answer 2 · answered May 01 '10 at 09:46

1

I agree with the other answers, and would like to explain one point further:

Class objects represent classes that are loaded into the JVM memory. Each class object is actually an in-memory instance of a .class file. Java generics are not separate classes. They are just a part of the compile-time type-checking mechanism. Therefore, they have no run-time representation in a class object.

answered May 01 '10 at 09:46

Little Bobby Tables

5,261
2
39
49

Generics are constraints during compilation and are mostly not available during runtime. However, I am not looking at having the generic type argument available in runtime. For example, ArrayList.class.newInstance() seems perfectly acceptable. I fail to find where this model fails, all the examples I can think do not introduce the need to have runtime class information of the type parameters. I am looking for an example where the class literal would fail because it would require runtime information ... – Peter Kriens May 01 '10 at 12:26
For full type information at compile time you can look at the Mirrors API - I don't remember the link right now. – Little Bobby Tables May 01 '10 at 17:19
I do not think this is about type (in the class sense) information at compile time, this is only about type constraints, i.e. type parameters. – Peter Kriens May 03 '10 at 06:06

score 0 · Answer 3 · answered May 01 '10 at 09:32

There seems to be a lack in class literals in Java, there is no way to create class literals with generic information while this can be useful in certain cases. Therefore, the following code cannot be called because it is impossible to provide the class literal

class A<S> {}
<S> A<S> foo( Class<A<S>> clazz ) {}
A<String> a = foo( A<String>.class ) // error

However, my main problem was I could also not call it with a class B that extended A. This was caused by the invariance restrictions. This was solved by using a wildcard:

class A<S> {}
class B extends A<String> {}     
<S> A<S> foo( Class<? extends A<S>> clazz ) { return null; }
void test () {
    A<String> s = foo( B.class ); 
}

That said I have not found a reason what the underlying reason is that Class<A<S>>.class is invalid. Neither erasure nor bounds seem require that this is invalid.

Why is using Collection.class illegal?

3 Answers3

Linked