I'm not getting it. I would expect that code not to compile, since Java does not allow two methods in the same class that differ only by return type (right?).
From a pure OOD perspective, they arguably aren't two methods but in fact one, and can be safely merged, just as interfaces are always merged (but classes are not, allowing only single inheritance).
This merging ought only to exist at the compiler level - it shouldn't be noticable at runtime, unless you use reflection (at which point there is food for debate about what signatures should be returned on particular searches for methods).
I'm not saying "it mustn't be like it is now", only that "it didn't need to be the way it is now, and I struggle to see any advantage to java developers of the present design AND I'm confident *I* could write a compiler that handled this so surely Sun (who are a million times better at it than me

) could have too".
PS I'm thinking of writing an article "1.5: syntactic sugar and boilerplate elimination? No way!", showing how most of the 1.5 changes are actually really heavy-duty stuff not lightweight eye-candy (as they seem to come across to many people). I can cite hardcore use-cases for quite a lot of the things that I at first thought "neat; will save a little time; not really *essential* though, is it?" and eventually realised were "without this, it's practically impossible to write application BLAH (and BLAH is only mildly specialized/niche)"