It's not that they can't update the VM, it's that they don't want to force a painful migration to reified versions of libraries that aren't backwards compatible. But I don't know why they can't just do what that last comment said: extend the old interfaces for reification without breaking them, using Object as the default type parameter.
i think the last comment's suggestion wasn't acceptable because it will break type safety for previously compiled code. perhaps this was too much to stomach for those making the decision?
it would remain binary compatible tho, so it would seem to be a possible solution.
for java to really advance forward it needs to be done in a manner where the principal is the future, not the past. if this means rendering old code as non-type-stafe then this is a small price for a whole new programming paradigm, or even two.
i've struggled with generics since they were added and the problem is that all the potential they propose is only possible if they're reified. as they stand they are worthless and just move a cast from the value to the class but they allude to far more, which is a rat hole.
java's had full backward compatibility for decades. code is a depreciating asset and worth less with every year since compilation. it's an incumbent now, slowing, even mutating, progress.
if some legacy code is so valuable, it should have earned its scars enough to have type safety turned off.
It's not that they can't update the VM, it's that they don't want to force a painful migration to reified versions of libraries that aren't backwards compatible. But I don't know why they can't just do what that last comment said: extend the old interfaces for reification without breaking them, using Object as the default type parameter.