Re: [Java Spec Report] Re: JSR 201 autobox comments

Neal Gafter wrote:
> Eric Blake wrote:
> 
>>I agree that they are not constant according to JLS2, and by the public draft 
>>of JSR 201.  But that was my complaint.  I think that these SHOULD be made 
>>constant, as part of JSR 201, final version.
> 
> 
> Why?

As I explained in my first email of this thread, I think it is silly for the 
semantics of these two statements to differ:

while (false); // the ; is unreachable, compile error
while (Boolean.FALSE); // the ; is reachable, compile proceeds

Likewise, the semantics of these statements:

int i, j;
if (true) i = 1; // i definitely assigned
if (Boolean.TRUE) j = 1; // j not definitely assigned
i = i; // legal
j = j; // illegal, by current rules

There are many other examples where the current proposal for autounboxing a 
Boolean has different semantics than using a compile-time constant boolean. 
In my eyes, part of making Boolean an acceptable replacement for boolean in 
control statements (and elsewhere) is making Boolean capable of being a 
compile-time constant, so that there are no semantic distinctions.  And by 
extension, if Boolean can be constant, then so should all the wrapper types. 
I am arguing for a forward-compatible change - a wrapper class is only 
constant if it is initialized by a constant expression.  No existing 1.4 code 
will be broken by this change.

-- 
Someday, I might put a cute statement here.

Eric Blake             [email protected]



To unsubscribe from this mailing list, send an email to:
[email protected]
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/java-spec-report/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/