Details
-
Type:
Enhancement
-
Status: Closed
-
Priority:
P4
-
Resolution: Fixed
-
Affects Version/s: 5.0
-
Fix Version/s: 7
-
Component/s: specification
-
Labels:
-
Subcomponent:
-
Resolved In Build:rc
-
CPU:x86
-
OS:windows_2000
-
Verification:Verified
Description
A DESCRIPTION OF THE REQUEST :
This is from the text of JLS 3rd edition (proposed) 15.12.1:
"If the form is Primary . Identifier, then the name of the method is the Identifier. Let T be the type of the Primary expression; then the class or interface to be searched is T if T is a class or interface type, or the upper bound of T if T is a type variable."
This does not say what happens if T is a primitive type. We may guess that this means we don't *have* a type to search, and thus the end of 15.12.2.1 requires a compile-time error. And of course that's what happens when we compile. But the JLS is rather more vague than it needs to be on this point.
JUSTIFICATION :
This was a problem in previous editions of the JLS, however I believe it's more of an issue now thanks to autoboxing and unboxing. There are now many contexts in which a primitive may be treated as a reference type, and we need to be told explicitly that this is not one of them. Compare 15.11.1 where it's made quite clear that for field access, you can't dereference a primitive.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Add one sentence in 15.12.1 (the bullet point on Primary.Identifier invocation): "It is a compile-time error if T is a primitive type."
ACTUAL -
Vagueness. Confusion. Bad craziness.
---------- BEGIN SOURCE ----------
class Test {
int x = Math.PI.hashCode();
}
// Obviously this results in a compile error, as it should.
// It's just the JLS explanation thats the problem
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Learn how Java works from the compiler rather than from JLS.
###@###.### 2005-04-25 19:45:28 GMT
This is from the text of JLS 3rd edition (proposed) 15.12.1:
"If the form is Primary . Identifier, then the name of the method is the Identifier. Let T be the type of the Primary expression; then the class or interface to be searched is T if T is a class or interface type, or the upper bound of T if T is a type variable."
This does not say what happens if T is a primitive type. We may guess that this means we don't *have* a type to search, and thus the end of 15.12.2.1 requires a compile-time error. And of course that's what happens when we compile. But the JLS is rather more vague than it needs to be on this point.
JUSTIFICATION :
This was a problem in previous editions of the JLS, however I believe it's more of an issue now thanks to autoboxing and unboxing. There are now many contexts in which a primitive may be treated as a reference type, and we need to be told explicitly that this is not one of them. Compare 15.11.1 where it's made quite clear that for field access, you can't dereference a primitive.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Add one sentence in 15.12.1 (the bullet point on Primary.Identifier invocation): "It is a compile-time error if T is a primitive type."
ACTUAL -
Vagueness. Confusion. Bad craziness.
---------- BEGIN SOURCE ----------
class Test {
int x = Math.PI.hashCode();
}
// Obviously this results in a compile error, as it should.
// It's just the JLS explanation thats the problem
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Learn how Java works from the compiler rather than from JLS.
###@###.### 2005-04-25 19:45:28 GMT
Attachments
Issue Links
- relates to
-
JDK-8251914 15.12.1: Remember to search an array type, not just a class or interface
-
- Open
-