Java Generics - type declaration

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 follo开发者_C百科wing:

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

---

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.

---

This is called a raw type. You should be able to turn on warnings to make it complain at you - listen to those warnings.

For example, here's what I get when I run

javac -Xlint Test.java

with your code (wrapping the raw type reference into a Test class):

C:\Users\Jon\Test>javac -Xlint Test.java
Test.java:7: warning: [rawtypes] found raw type: Response
    Response response = new Response();
    ^
  missing type parameters for generic class Response<T>
  where T is a type-variable:
    T extends Object declared in class Response
Test.java:7: warning: [rawtypes] found raw type: Response
    Response response = new Response();
                            ^
  missing type parameters for generic class Response<T>
  where T is a type-variable:
    T extends Object declared in class Response
2 warnings

If you don't have those warnings at the moment, I suggest you do whatever it takes to see them in your environment. That will depend on the IDE / compiler you're using, but if you can't find the relevant setting, let us know which one you're using and I'm sure someone will be able to find it for you.

See the raw types section of Angelika Langer's Java Generics FAQ for more information.

---

I think that by not specifying a template class in the bottom line, you are causing the compiler to automatically substitute type Object. That's not wrong, it's just not very effective at enforcing a type.

---

This will compile fine. If it didn't you'd have issues with legacy code. For example, since HashMap is now declared as HashMap<K, V>, what would you do with all of that code that declares an (unparameterized) hashmap?

You'll only get the error when you try to use the parameterized value:

class Response<T>
{ public T get()... }

String s= new Reponse().get(); //breaks - or requires a cast
String s= new Response<String>().get();