javac TestC1.java
TestC1.java:4: name clash: compareTo(java.lang.Object) in TestC1 and compareTo(T) in java.lang.Comparable<TestC1> have the same erasure, yet neither overrides the other
public class TestC1 implements Comparable<TestC1>, Comparator {
^
1 error
Stephan van Hulst wrote:It's because of type erasure. The compiler throws away generic type arguments. After compilaton, compareTo(TestC1) would look the same as compareTo(Object), because TestC1 is a generic type argument. Since you already have a compareTo(Object) defined, the compiler throws that error because you're not allowed to overload a method if the signatures are the same.
Stephan van Hulst wrote:As far as the compiler is concerned, your compareTo(TestC1) method is actually a <T> compareTo(T) method. T is replaced by Object after the compiler checks that you are really using TestC1 everywhere, instead of just any other type.
Stephan van Hulst wrote:Yes, the JVM compiles bytecode to native code before it executes the code.
Stephan van Hulst wrote:Well, verifying whether your code is legal comes before actually compiling it. Ideally, you want to do all the checking before a single piece of byte code is written, so the JVM can assume that .class files are always correct. Wouldn't it be annoying that you only found out your program was wrong when you started the JVM, instead of when you call javac?
The fact that javac doesn't immediately remove generic types, doesn't mean that it can't determine how the method signatures will end up looking when erasure does take place.
Stephan van Hulst wrote:I'm not exactly sure what you mean by your last question. Do you mean you want to see the actual code that the JVM runs? At this point, it looks nothing like Java anymore, and a Java program can't easily be reconstructed from it.
Andreas Svenkson wrote:Obviously, stupid me, how else would the plattform-independancy be possible
[...]
Right... what I was after was seeing what the code looks like after the type-erasure, but I guess that might not be possible. It's funny, I never really considered how the JVM actually handles the byte code, I just thought of it as a program that "knew how to run java programs compiled to byte code" and that was that.
It just annoys me, I guess I would practically have to be able to read machine-level binary code to really know what the cpu sees when it executes the program.
It's just like a fortune cookie, but instead of a cookie, it's pie. And we'll call it ... tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|