Runtime Type Safety and Inheritance for Generics - what they should've been
First of all, sorry if this is a duplicate idea, I did not have enough time to go through all forum.
Currently, generics are just syntactic sugar (more or less). We all know that.
Parameterized object instances and declarations should retain their type parameters at runtime. Instead of explaining why, I give you an example:
When you say
new ArrayList() you mean new object contains Strings and nothing else. Parameterized class should include checkcast wherever type parameter is used to enforce ClassCastException.
Rationale behind this suggestion is clear:
If we can do this:
<br /> Object obj = "hello";<br /> Number num = (Number) obj; // throws CCE<br />
we fooled compiler but not runtime (we get ClassCastException). Then wen should be able to do this:
<br /> Object obj = new ArrayList();<br /> List nums = ( List ) obj; // should throw CCE<br />
and we should get CCE again at runtime (although we fooled compiler again).
<br /> List l = new ArrayList();<br /> l.add(new Integer(1)); // should throw CCE<br />
Yet another: inheritance.
You cannot do this:
<br /> List numbers = new ArrayList();<br />
Why oh why? if you can do
Number n = new Integer(0)
why? Who understands this?
Just because compiler cannot guarantee type safety and data integrity (dangerous add() on downcasted variable?) Oh my! so let runtime handle it and you don't need such stupid restrictions! Did you left hand knew what right hand was doing???
Definitelly this is a must: runtime type safety for Java genericsm, full logical inheritance in well-established and well-understood context
I don't care what it costs or what Sun dreamt about while designing generics. All I know is that current solution is poorly designed, ambiguous, and no newbie will ever understand that - and it definitelly stands in the way of wider adoption of generics.
If you need to change JVM, do it. If you need to change bytecode, just do it. Don't hesistate.
But finish things properly.
Bugs can be fixed. Design flaws usually cannot. They become must-live-with legacy features Is this what you want?
J2EE Software Architect
Cleverlance - The Clever Enterprise Solutions
Pod Pekárnami 7/161
190 00 Praha 9
phone: +420 266 177 166
mobile: +420 608 040 445
fax: +420 266 177 155