jvm wishes and gripes

Mon Feb 4 16:21:00 GMT 2002

Per Bothner wrote:
> Adam Megacz wrote:
>>>>> Oh yeah, one more thing... why doesn't the Java Language spec allow
>> this:
>>>> class A {
>> A foo() { return null; }
>> }
>>>> class B extends A {
>> B foo() { return null; }
>> }
>>>> Plenty of other languages (Haskell, ML) 
>> and C++
>>> let you do stuff like
>> this... the code above can't violate typing rules (even if B.foo()
>> returned actual instances of B instead of just null).
>>> They did want to add it, but implementation issues made it awkward to
> implement, and they were under get-it-out-the-door pressure. 

IIRC, specializing the return type of an overloading method is sneaking 
back in as part of the generic types specification.
Apart from that I tend to agree with Adam's complaints about the GT 
stuff. Done right, generics could improve efficiency by eliminating the 
need for many runtime cast checks. In Java they will do the opposite 
because runtime checks must still get silently introduced.
The problem is that its perfectly legal to assign say a List to a 
List<String> without any type of cast, so the compiler must still 
translate a "get(..)" on a List<String> to "(String) get(..)". Instances 
of a generic class carry no information at runtime about their parameter 
types, so it isn't possible to check that a cast from List to 
List<String> is legal.
Still, there isn't any way they could have done any better (except 
perhaps for C++ style "template instantiation" which has its own 
problems) given the constraints of backwards compatibility with the 
existing bytecode and VMs. Having an extra layer of compile-time type 
safety certainly isn't a bad thing.
regards
Bryce.