FULL PRODUCT VERSION :
java version "1.6.0_10-beta"
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux lin3 2.6.9-67.0.7.ELsmp #1 SMP Wed Feb 27 04:47:23 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
JLS3 page 444 (top) says "- If the generic invocation includes explicit type parameters, and the member is a generic method, then the number of actual type parameters is equal to the number of formal type parameters."
This and the discussion section that follows that paragraph indicate that explicit type arguments are permitted and ignored if the method is not actually generic.
javac does not seem to implement this rule. This example should be accepted but is not.
class A {
void f() {
this.<Double> f();
new <Double> A();
}
}
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the example shown in the description.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Successful compilation.
ACTUAL -
t1.java:3: f() in A cannot be applied to <java.lang.Double>()
this.<Double> f();
^
t1.java:4: cannot find symbol
symbol : constructor <java.lang.Double>A()
location: class A
new <Double> A();
^
2 errors
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
class A {
void f() {
this.<Double> f();
new <Double> A();
}
}
---------- END SOURCE ----------
java version "1.6.0_10-beta"
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b12, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux lin3 2.6.9-67.0.7.ELsmp #1 SMP Wed Feb 27 04:47:23 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
JLS3 page 444 (top) says "- If the generic invocation includes explicit type parameters, and the member is a generic method, then the number of actual type parameters is equal to the number of formal type parameters."
This and the discussion section that follows that paragraph indicate that explicit type arguments are permitted and ignored if the method is not actually generic.
javac does not seem to implement this rule. This example should be accepted but is not.
class A {
void f() {
this.<Double> f();
new <Double> A();
}
}
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the example shown in the description.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Successful compilation.
ACTUAL -
t1.java:3: f() in A cannot be applied to <java.lang.Double>()
this.<Double> f();
^
t1.java:4: cannot find symbol
symbol : constructor <java.lang.Double>A()
location: class A
new <Double> A();
^
2 errors
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
class A {
void f() {
this.<Double> f();
new <Double> A();
}
}
---------- END SOURCE ----------
- duplicates
-
JDK-5081782 type arguments to non-generic methods
-
- Closed
-