Question

class Response<T>
{ ... }

Response response = new Response();

The above code compiles. I don’t understand what’s implied though. Shouldn’t the compiler require a type specification for ‘T’? e.g. something like the following:

Response<String> response = new Response<String>(); 

Answer 1

Technically, it should/ought to. However, for backwards compatibility with Java 5, this is not done and so a generic parameter is not required. And since generics are implemented by erasure anyway, the bytecode emitted is identical regardless of whether you declare the parameters or not – all you’re missing out on is some compile-time checks.

(Note that if you call methods on your response object, the compiler will warn you about using “raw types”, meaning that you’re using a generic class in a non-generic way so it can’t enforce any of the constraints for you.)

Edit: Regarding backwards compatibility, it’s a balancing act, and Sun have clearly sacrificed some aspects in order to improve/maintain others. Breaking backwards compatibility would be quite a big deal – it would mean that migrating to the latest version of Java would be a non-trivial project, and would create even more resistance within businesses to upgrading.

The big decision here was to implement generics via erasure, such that they’re a “compile-time only” construct and the generated bytecode is identical to the previous version. This has the advantage that e.g. java.util.HashMap in 1.5 can still be accessed by code written in 1.4 (and of course this advantage extends to your own classes too). However, there are lots of view, especially from those used to generics in other languages who want to use similar techniques, that this was not the best decision and has crippled the usefulness of generics. I’m not going to weigh in on that here.

As for whether it subverts the checks the compiler wants to enforce; I don’t think it’s quite as bad as you think. Yes, you can write code such that the compiler doesn’t do any generics checks, and such that you can deliberately subvert the intended semantics. However, the compile-time checks aren’t meant to be some sort of security feature, they’re simply there to help you, as a form of static analysis that will pick up certain classes of error. If you want to subvert them, feel free to do so. But if you write your generic classes properly, then you’ll get the compile-time checks that you desire.

Especially since the compiler (can) give you warnings about raw types, there’s a clear upgrade path from 1.4 to 5. Upgrade your JDK – your old code still compiles albeit with warnings. Then use these warnings to chase down violations, and generify your old code as and when needed. In my opinion, that’s much better than simply refusing to compile the old (presumably functional!) code until every statement has had appropriate generics added.

Most IDEs will let you classify the severity of different warning types, such that if you’re developing a Java 5 application from scratch, you can tell it to treat all raw type warnings as full-on stop-the-build errors.