F****n
发帖数: 3271 | 1 After some research, it seems that the "type erasure" problem is due to a
Java bug: javac should NOT be able to compile two methods with same
signature but different return types.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182950
According to the link below, this misbehavior is fixed in some Eclipse
version, which is correct while javac is wrong.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273862 | m****r
发帖数: 6639 | 2 this makes sense to me. since you can always do
Object o = f(x), then, we'd be confused.
what does java says about
f(A) and f(B) where A extends B?
【在 F****n 的大作中提到】
: After some research, it seems that the "type erasure" problem is due to a
: Java bug: javac should NOT be able to compile two methods with same
: signature but different return types.
: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182950
: According to the link below, this misbehavior is fixed in some Eclipse
: version, which is correct while javac is wrong.
: https://bugs.eclipse.org/bugs/show_bug.cgi?id=273862
| s******n
发帖数: 876 | 3 well, the language spec has dedicated 50 pages for
this subject alone. we thought java is supposed
to be simpler than c++...
http://java.sun.com/docs/books/jls/third_edition/html/expressio
15.12 Method Invocation Expressions
15.12.1 Compile-Time Step 1: Determine Class or Interface to Search
15.12.2 Compile-Time Step 2: Determine Method Signature
15.12.2.1 Identify Potentially Applicable Methods
15.12.2.2 Phase 1: Identify Matching Arity Methods Applicable by
Subtyping
15.12.2.3 Phase 2: Identify Matching Arity Methods Applicable by
Method Invocation Conversion
15.12.2.4 Phase 3: Identify Applicable Variable Arity Methods
15.12.2.5 Choosing the Most Specific Method
15.12.2.6 Method Result and Throws Types
15.12.2.7 Inferring Type Arguments Based on Actual Arguments
15.12.2.8 Inferring Unresolved Type Arguments
15.12.2.9 Examples
15.12.2.10 Example: Overloading Ambiguity
15.12.2.11 Example: Return Type Not Considered
15.12.2.12 Example: Compile-Time Resolution
15.12.3 Compile-Time Step 3: Is the Chosen Method Appropriate?
15.12.4 Runtime Evaluation of Method Invocation
15.12.4.1 Compute Target Reference (If Necessary)
15.12.4.2 Evaluate Arguments
15.12.4.3 Check Accessibility of Type and Method
15.12.4.4 Locate Method to Invoke
15.12.4.5 Create Frame, Synchronize, Transfer Control
15.12.4.6 Example: Target Reference and Static Methods
15.12.4.7 Example: Evaluation Order
15.12.4.8 Example: Overriding
15.12.4.9 Example: Method Invocation using super
【在 m****r 的大作中提到】
: this makes sense to me. since you can always do
: Object o = f(x), then, we'd be confused.
: what does java says about
: f(A) and f(B) where A extends B?
| g*****g
发帖数: 34805 | 4 well, most of us are not JVM developer and we don't
need to know details of this level. We should just happily
fix whatever compiler says no and don't second guess on it.
【在 s******n 的大作中提到】
: well, the language spec has dedicated 50 pages for
: this subject alone. we thought java is supposed
: to be simpler than c++...
: http://java.sun.com/docs/books/jls/third_edition/html/expressio
: 15.12 Method Invocation Expressions
: 15.12.1 Compile-Time Step 1: Determine Class or Interface to Search
: 15.12.2 Compile-Time Step 2: Determine Method Signature
: 15.12.2.1 Identify Potentially Applicable Methods
: 15.12.2.2 Phase 1: Identify Matching Arity Methods Applicable by
: Subtyping
| s******n
发帖数: 876 | 5 apparently the spec has changed since then.
in the current spec, the relevant section is 8.4.2
http://java.sun.com/docs/books/jls/third_edition/html/classes.h
which has a weaker restriction on when m1 and m2 cannot
be declared in the same class:
# m2 has the same signature as m1, or
# the signature of m1 is the same as the erasure of the signature of m2.
List and List are different, and neither is
the same as the erasure of another, i.e. List is
not the same as the erasure of List, which is List.
List is not the same as List.
The bug references "JLS3 draft 8.4.8.3: ... both methods have
same erasure", these words are not present in current spec.
" | s******n
发帖数: 876 | 6 Nobody should care, except for fun.
Java is catching up with C++ on the time wasted by
programmers arguing about arcane language details.
【在 g*****g 的大作中提到】
: well, most of us are not JVM developer and we don't
: need to know details of this level. We should just happily
: fix whatever compiler says no and don't second guess on it.
|
|
