Yeah, thats what I read in the JSR. The reasoning that its that way in C++ makes perfect sense, but being a C++ engineer for a living I couldn't help but question why its that way there. So far, still no technical reason, simply that it'd make it more intricate.
I used to get screwed over by several such "features" of java, which are REALLY useful (one might even say "essential") when developing libraries. The other major one was the lack of parametric function despatch (it's complex to explain, but according to the design of OO as a concept it's reasonable and arguably logical to expect).
Only have vague memories now, but ... In all my attempts to find reasons why these weren't supported by java, the best answers I remember getting were along the lines of "think about how you'd implement the method despatcher, and the performance penalty you'd pay for the extra work for the VM to decide which method to call".
ISTR that, like with goto's, there were optimizations that couldn't be done if you allowed this in the JLS. I can't remember what they were any more
, although IIRC parametric fn-despatch made it difficult to keep lookups down to single pointer indirection in a typical fn-table implementation.
...but I always hoped the JVM's would evolve enough that we could have a more powerful JLS (v.3.0?).
As for clarity, it's certainly a two-edged sword; it gives power to make some really hard to debug mistakes, but OTOH this level of polymorphishness (!??) makes 3rd-party library dev sooooo much easier (and eliminates several of the hacks you currently have to do to work around these "features" in the JLS