Why is a Collection<? extends String> an instance of a Collection<? extends Number> ???

		Collection<? extends Number> ref1 = new LinkedList<Integer>();
		Collection<? extends String> ref2 = new ArrayList<String>();
		Collection<String>           ref3 = new ArrayList<String>();
		
		boolean b;
		// true
		b = ref1 instanceof Collection<? extends Number>;
		System.out.println(b);
		
		// >>>>>>  true !!!   <<<<<<
		b = ref2 instanceof Collection<? extends Number>;
		System.out.println(b);
		
		// error: inconvertible types
		// found   : java.util.Collection<java.lang.String>
		// required: java.util.Collection<? extends java.lang.Number>
		b = ref3 instanceof Collection<? extends Number>;

My understanding of Collection<? extends Number> is that it denotes a set of types ranging over all instantiations Collection<T> where T is a subtype of Number.

And the same for Collection<? extends String>. Since String is a final class this set of types has only one element, namely Collection<String>.

Both sets have no overlap. How can an object of a type in the set Collection<? extends String> be an instance of a type in the set Collection<? extends Number>?

 

 

instanceof is a runtime operation and at runtime all these collections are just Collection's. A consequence of erasure along with the inability to do new E[] (where E is a type variable).

 

 

Well, it is obvious that because of type erasure this instanceof expression is not a runtime check, but a compile-time check. The question is: which compile-time check does the compiler perform based on the static type information? Or are you saying that per se the compiler does not perform any compile-time check when it evaluates a cast or an instanceof expression?

 

 

You know, generics by erasure seemed a really cool way to let generic code run on older JVMs. But the more I see problems like this, the more it seems to be a liability, that adds a bunch of gotchas to generic programming, where things don't work the way you expect, and unless you really know what is going on you are likely to write buggy code.

Since the decision was made to break backward compatibility, how much thought was put into not doing erasure? That is, have pointers to the proper class objects within the generic class, so that getClassByName("ArrayList<String>") and getClassByName("ArrayList<Integer>") will return different class objects, with references to the class object for the generic parameters? Seems generating these as needed at runtime would be trivial, and it would solve the "can't instantiate" issue and the "instanceof is broken" issue and the related "casting succeeds when it should fail" issue. I know that it is too late now to get this in by 1.5, but backward compatibility was the only good part about the erasure, and now we don't get that, so the whole erasure idea is an albatross. Was there a good reason to keep it that I don't see?

 

 

The decision about backward compatibility was a decision about the javac compiler only. The decision whether to do erasure or not is covered by JSR-14. Why would a decision about one specific java compiler affect the entire generics proposal?

 

 

I think you are being disingenuous. Sun's javac effectively defines the standard of all java compilers. If the standard java complier won't compile generic code that works on pre-1.5 JVMs, and if the standard java libraries that use generics don't work on pre-1.5 JVMs, then I'd say that it makes a lot of sense to let this "one specific java compiler" affect the entire generics proposal. Your wording makes it sound like the generics propasal is more important than the compiler; I think that saying that any of the JCP proposals is more imporant than the behavior of sun's javac is laughable.

 

 

This is a compiler bug. The compiler should give an error
message when you use instanceof with a generic type on the
right.

 

 

Thanks for the clarification, but I'm not sure that I understand what you are trying to say. Are you saying that use of instanceof with a generic type as the right-hand side operand is illegal in all cases?

That would be in contradiction to the specification. The spec says (section 5.5, page 13):

"Type comparison can involve parameterized types. The rules of casting conversions, as defined in Section 5.4 apply."

In addition, the spec specifies the syntax of instanceof expressions and it gives examples. Perhaps I am misreading the spec, but it does not look like use of generic types in instanceof expressions is in general illegal. I guess that's not what you were trying to say.

What exactly is the compiler bug? Only the treatment of the second instanceof expression is surprising. The compiler accepts it although it can ascertain statically that this cast can never succeed.

Collection<? extends String> ref2 = new ArrayList<String>();
boolean b = ref2 instanceof Collection<? extends Number>;

Section 5.4 rules out (for cast and instanceof expressions) whether and when an error message must be issued. It says:

"A value of type S can be cast to a parameterized type T if one of the following conditions holds:
1.) T is a subtype of S, and there are no other subtypes of S with the same erasure as T.
2.) T is a supertype of S. [ ... ]"

Applied to the example it means: a value of type ArrayList<String> can be cast (or compared) to the parameterized type Collection<? extends Number> if (1) Collection<? extends Number> is a subtype of ArrayList<String> or (2) Collection<? extends Number> is a supertype of ArrayList<String>. Since none of the conditions holds an error message must be issued.

I don't understand why the spec talks of "a value of type S"; I would expect that the type of the reference variable would be used, not the type of the value referred to. But in the example it doesn't make a difference anyway. The type Collection<? extends String> is in no super- or subtype relationship to type Collection<? extends Number> either.

I would expect an error message. The compiler does not issue the expected message - due to a compiler bug. Is this what you are saying?




By the way, is this a compiler bug, too?

clas X<T> {
  void f(T arg) { boolean b = arg instanceof T; }
}

The compiler mumbles something regarding "unexpected type, found : T, required: class or array". It looks to me as though the compiler would in general reject the use of type variables as the right-hand side operand of instanceof expressions. The spec however allows it. See the syntax productions; it permits "RelationalExpression instanceof ReferenceType" and a ReferenceType can be a TypeVariable. The compiler can only reject the instanceof expression above on the ground of section 5.4, which it can't do in this case because the static type of arg is T.

 

 

I didn't say so. It's just that the fact that version 1.5 source code compiled with javac will not run on version 1.4 JVMs does not mean that "the decision was made to break backward compatibility."

I would also say that, in general, standards are more important than any one specific implementation of the standard. The way any one implementation implements a standard is by definition an implementation detail. Is how one particular JVM performs garbage collection more important than how the JLS explains garbage collection occurs, for example? I would say that the JCP proposals certainly are more important than the behavior of Sun's javac compiler.

 

 

Why? Because someone someday MAY develop a compiler for the 1.5 generic specification that generates code that does run on 1.4 VMs?

Is that a realisitic hope or merely wishful thinking and semantic hair splitting?

 

 

We don't break backward compatibility. Existing source (and byte) code will compile (and run) under a Java system that includes support for Generics. We've explored the design space of including runtime access to generic types, and none of the points in the design space retain backward compatibility.

Perhaps you're talking about what I've called forward compatibility: writing programs for the 1.5 platform and then running them on a 1.4 platform. We haven't provided that kind of compatibility in any feature release of the platform in the past.

 

 

I'm sorry, I should be clearer. I know that Sun puts great effort into making sure any JVM will run code produced by previous javac compilers. This is admirable! But let's call it "JVM backwards compaitibility". When I said "backwards compatilibity" in a post talking about the generics, I meant the abilitiy of a compiler to compile java source that used generics, and emit bytecode that could be used in an older JVM.

Neil, I'm really not trying to needle you here - I'm always impressed that you come by and take the time to clear things up. Since you seem to be the most authoritative person in this from on what decisions were made and why, can you please answer, since javac will not be able to compile geneics code into pre-1.5 bytecode, was any thought given to not doing erasure? Was there another reason to keep erasure, besides working on pre-1.5 bytecode, was it decided that it was too late to make such a major change in the generics proposal, or was there another reason to keep it? Thanks so much for any answer.

 

 

My understanding is that the type-erasure design (raw types, in particular) easily allows interoperability with unparameterized legacy code: you can "retrofit" modern type signatures to existing code without changing the implementation and in generate pass parameterized-typed data in and out of existing code without problems. This was the primary motivation for the type erasure design, and is not affected by the classfile format decisions.

 

 

But does it require type erasure? After all, the retrofit produces new class files, doesn't it?

 

 

The retrofit process does not reify type parameters in the
generated class files. It could not do so and retain support
for backwards compatibility.