[Java Spec Report] JSR 201 autobox comments

I haven't yet had time to pick through the entire autobox public draft 
document, but I do have some top-level questions.

First, my plea to make wrapper classes behave as compile time constants, when 
they are initialized by a constant expression.  In particular, I think it evil 
that these two loops have different compile-time semantics:

import static Boolean.*;
class C {
   void m() {
     while (true);
     //; // unreachable, compiler gives error if line is uncommented
   }
   void n() {
     while (TRUE);
     ; // should be unreachable, but Boolean.TRUE is not constant
   }
}

I would like to see all wrapper classes initialized by a compile-time constant 
expression treated as compile-time constants.  The trickiest part of making 
this work might be extending the .class file format to list the initial value 
for such variables; you will need a new attribute beyond ConstantValue if you 
want to compile to pre-1.5 .class format without breaking old VMs.  Then 
again, since you aren't supporting -source 1.5 -target 1.4 in javac, a 1.4 VM 
will never need to worry about the constant value of a wrapper type because 
wrapper types are not constant in 1.4.  I think this change is valuable, 
because it makes autoboxed wrapper classes behave more like primitives, which 
appears to be your intent.  And it does not change the semantics of any 
existing program, because before autoboxing was introduced, it was impossible 
to assign a compile-time constant (primitive) to a wrapper class (object), as 
well as impossible to use a wrapper type in a context where compile-time
constants made a difference (such as the condition of a while loop).  Also, I 
would keep expressions like Boolean.TRUE.booleanValue() as a
non-compile-time constant, becuase it has an explicit method call.

Second, I wonder why you did not include 15.20.2 in the list of sections 
affected by autoboxing.  Since wrapper classes unbox everywhere else, it seems 
inconsistent that primitive types cannot autobox when used as an argument to 
instanceof.  In other words, since "((Integer) 1) instanceof Integer" is 
legal, why not make "1 instanceof Integer" legal?  You will have to be 
careful, to define definite semantics to "1 < 2 instanceof Boolean": is it "(1 
  < 2) instanceof Boolean" (compiles to true) or "1 < (2 instanceof Boolean)" 
(compile-time error, since 2 can never be Boolean)?

Remember, you already have to tweak the grammar of RelationalExpression 
somewhat to make generics work unambiguously in an LALR(1) grammar.  The CUP 
grammar proposal was to create different precedence levels for {<, <=, >, >=} 
and {instanceof}, since a boolean expression can never be an argument to the 
relational operators but type parameters can appear in the expression argument 
to instanceof.  So while you are tweaking this rule, you should tweak it to 
allow autoboxing of the argument to instanceof.

I also think that now would be a good time to add certain cases of instanceof 
to the list of compile-time constant expressions.  If the compiler can 
statically determine that an instanceof expression would always be false, it 
must give a compile-time error (except for the special case of "null 
instanceof XXX").  So why not require the compiler to treat an instanceof 
expression that will always be true as a compile-time constant (such as "XXX 
instanceof Object")?

Was it an inadvertant error that 15.20.1 was specified (<, <=, >, >=) but not 
15.21 (==, !=)?  In other words, why can I say "1 < new Integer(2)" but not "1 
!= new Integer(2)"?

-- 
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/