0

Put another way, would achieving strong types without type erasure only require a new language or also a new JVM?

Note: I'm not asking when or how erasure occurs. I'm asking what is demanding it. The inability to change the language or the inability to change the JVM. Or both.

UPDATE:

To be very clear, I am not asking about any implementation details. This question is about legacy. Unless I'm mistaken type erasure has been justified as something we have to live with for the sake of backwards compatibility. How it is currently implemented and when it takes effect are not at issue.

Any answer to this question should make clear if a new specification to a new strongly typed language could do away with type erasure and still run on the JVM as it is currently specified.

candied_orange
  • 5,855
  • 1
  • 24
  • 57
  • 2
    neither, the compiler –  Mar 06 '15 at 19:41
  • 2
    "Type erasure" is a fiction created to make it seem like Java actually supports strong derived types. Whether Java could be "rewound" back to the "pure" state and then modified to have true strong derived types is hard to say. It would probably require updating the JVM if done, though that is not an excuse for having botched the first try, since the JVM can be easily upgraded in a transparent fashion. – Hot Licks Mar 06 '15 at 19:44
  • 1
    (It's hard to imagine how one could implement real derived types without modifying the JVM, since *checkcast* would have to be modified to support them.) – Hot Licks Mar 06 '15 at 19:47
  • @JarrodRoberson Please note my edit. And anyone can write a compiler to do anything. If it doesn't conform the the language spec it's not a java compiler. – candied_orange Mar 06 '15 at 19:48
  • it is a *"feature"* of the compiler that is where the information is *lost* because that information is not supported past the compiler. So when and where it happens is the answer to your question why is **the information is not used past the compiler stage**. That should be pretty clear. –  Mar 06 '15 at 19:54
  • @JarrodRoberson again, I'm not asking how it works. I'm asking what is forcing it to exist. For example it doesn't exist in other languages. – candied_orange Mar 06 '15 at 19:55
  • @CandiedOrange Forces "what" to exist? And "what" doesn't exist in other languages? (Scala is also plagued with type erasure; but has reified types/manifests. C# has reified types and generics without erasure.) – user2864740 Mar 06 '15 at 21:50
  • @user2864740 Forces type erasure to exist. – candied_orange Mar 06 '15 at 22:34
  • @CandiedOrange See Hot Lick's comment - nobody "forced" the approach. .NET 2 (with reified generics) shows one alternative strategy. (Since there are minimum JVM requirements anyway I don't go with the entire source-to-bytecode backward compatibility arguments.) – user2864740 Mar 06 '15 at 22:54
  • @user2864740 As I understand it venders forced it to exist because they didn't want new versions breaking their legacy code. They refused any changes that would force binaries to be recompiled. – candied_orange Mar 06 '15 at 23:00
  • @CandiedOrange Which is a nonsense argument, as .NET showed. – user2864740 Mar 06 '15 at 23:00
  • Then again, .NET still hasn't fixed the null bug - granted that would be a [much] larger undertaking and also dive all the way through the CLR/CLI specification. So there definitely is "people are still willing to put up with it" vs "amount of work to fix" going on. – user2864740 Mar 06 '15 at 23:07
  • @user2864740 what is this "null bug" you speak of? Links to such? –  Mar 09 '15 at 17:50
  • @Will [Speaking at a conference in 2009, Tony Hoare apologised for inventing the null reference..](http://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions) Okay, granted it's technically just a misfeature - and I ultimately blame C# initially trying to replace Java and such similarities - but it is such a prevalent (and unnecessary in strongly-typed languages) source of issues that never should have existed to begin with. It is not a coincidence that several "modern designed" statically typed languages offer some notion of a "non-nullable" type or guard, in various packaging. – user2864740 Mar 09 '15 at 18:23
  • @Will If one doubts how much of a misfeature this is (which is why I do - at great IMOHO - call it a "null bug"), try to implement Code Contracts in a project (or full annotation with ReSharpers nullable attributes) - it might as well be called Null Check Contracts and full static analysis coverage for *just* null-checking requires *excessive* work as such is sadly not incorporated into the C# (but really .NET/CLR) type-systems. – user2864740 Mar 09 '15 at 18:26
  • @user2864740 Ah, understand. However, you're not quite correct--see F#, which only encounters null values via interop or referencing types defined in assemblies written in another language. So, if you're solely developing in F#, you have a statically typed language that runs on the CLR that dispenses with nulls. And, with that, I'll bow out of this convo (OP is getting pinged every time we @ each other) –  Mar 09 '15 at 18:58
  • @Will you're not bothering me. This crippled question might as well entertain someone. – candied_orange Mar 09 '15 at 22:55

0 Answers0