 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Autoboxing support for the Javatm Programming LanguageThe need to explicitly convert data of primitive type to reference arises frequently and is often burdensome. The most typical examples are adding primitive data to collections. �The explicit conversions required are verbose and induce clutter in the program text. We propose to modify the JavaTM programming language to allow automatic conversion of data of primitive type to the corresponding wrapper type. This proposal �eliminates� annoying casts and conversions from source code, and synergizes with the planned addition of generics to the language. The mechanism for achieving this is the introduction of a new conversion, known as boxing conversion, which may be used as part of assignment conversion �and method invocation conversion (and possibly elsewhere). This proposal does not include the dual facility of auto-unboxing. �However, the expert group may choose to contemplate that facility as well, if its inclusion can be done in a manner that is not overly disruptive to the language as a whole. Proposed Changes to Java Language SpecificationThis section provides draft text for sections of the Java Language Specification (JLS) that will need to be changed if this proposal is adopted. This text is tentative, and there may be additional sections of the JLS, not included here,� that may require modification. Nevertheless, these sections provide a good depature point for the work of the expert group.// New section, after current 5.1.6 � JLS 5.1.7 Boxing ConversionBoxing conversion converts values of primitive type to corresponding values of reference type. The precise rules are as follows: If i is a value of type boolean, then boxing conversion converts i into a reference r of class and type Boolean, such that r.value() == i. If i is a value of type byte, then boxing conversion converts i into a reference r of class and type Byte, such that r.value() == i. If i is a value of type char, then boxing conversion converts i into a reference r of class and type Character, such that r.value() == i. If i is a value of type short, then boxing conversion converts i into a reference r of class and type Short, such that r.value() == i. If i is a value of type int, then boxing conversion converts i into a reference r of class and type Integer, such that r.value() == i. If i is a value of type long, then boxing conversion converts i into a reference r of class and type Long, such that r.value() == i. If i is a value of type float, then boxing conversion converts i into a reference r of class and type Float, such that r.value() == i. If i is a value of type double, then boxing conversion converts i into a reference r of class and type Double, such that r.value() == i. If i is a value of any other type, boxing conversion is equivalent to an identity conversion (5.1.1). // Comment: // Note that this formulation disallows any assumptions about the identity of the boxed values on the // programmer's part.� This would allow (but not require) sharing of some or all of these references // (canonical booleans, for example). // New section, before current 5.1.7 JLS 5.1.8. Unboxing conversionUnboxing conversion converts values of reference type to corresponding values of primitive type. The precise rules are as follows: If r is a reference of type Boolean, then unboxing conversion converts r into a value v of type boolean, such that r.value() == v. If r is a reference of type Byte, then unboxing conversion converts r into a value v of type byte, such that r.value() == v. If r is a reference of type Character, then unboxing conversion converts r into a value v of type char, such that r.value() == v. If r is a reference of type Short, then unboxing conversion converts r into a value v of type short, such that r.value() == v. If r is a reference of type Integer, then unboxing conversion converts r into a value v of type int, such that r.value() == v. If r is a reference of type Long, then unboxing conversion converts r into a value v of type long, such that r.value() == v. If r is a reference of type Float, then unboxing conversion converts r into a value v of type float, such that r.value() == v. If r is a reference of type Double, then unboxing conversion converts r into a value v of type double, such that r.value() == v. // Corrections to 5.1.5 Forbidden conversions (some forbidden conversions are no longer forbidden). // Specifically, bullets 1, 2, 5 and 6 are dropped. The resulting section follows. // Was 5.1.7; renumbered 5.1.9 Forbidden ConversionsThere is no permitted conversion from the null type to any primitive type. There is no permitted conversion to the null type other than the identity conversion. There is no permitted conversion other than string conversion from class type S to a different class type T if S is not a subclass of T and T is not a subclass of S. There is no permitted conversion from class type S to interface type K if S is final and does not implement K. There is no permitted conversion from class type S to any array type if S is not Object. There is no permitted conversion other than string conversion from interface type J to class type T if T is final and does not implement J. There is no permitted conversion from interface type J to interface type K if J and K contain methods with the same signature but different return types. There is no permitted conversion from any array type to any class type other than Object or String. There is no permitted conversion from any array type to any interface type, except to the interface types java.io.Serializable and Cloneable, which are implemented by all arrays. There is no permitted conversion from array type SC[] to array type TC[] if there is no permitted conversion other than a string conversion from SC to TC. JLS 5.2 Assignment ConversionAssignment conversion occurs when the value of an expression is assigned (�15.26) to a variable: the type of the expression must be converted to the type of the variable. Assignment contexts allow the use of an identity conversion (�5.1.1) , a widening primitive conversion (�5.1.2) , a widening reference conversion (�5.1.4) ,� or boxing conversion (�5.1.7). JLS 5.3 Method Invocation ConversionMethod invocation conversion is applied to each argument value in a method or constructor invocation (�15.9 , �15.12): the type of the argument expression must be converted to the type of the corresponding parameter. Method invocation contexts allow the use of an identity conversion (�5.1.1), a widening primitive conversion (�5.1.2), a widening reference conversion (�5.1.4),� or boxing conversion (�5.1.7) . // Effects on overloading are discussed in JLS 15.12.2.2, see below JLS 5.5 Casting Conversion// Comment: Add references to boxing and unboxing conversion. // The first few paragraphs of the section are given below Casting conversion is applied to the operand of a cast operator (15.16): the type of the operand expression must be converted to the type explicitly named by the cast operator. Casting contexts allow the use of an identity conversion (5.1.1), a widening primitive conversion (5.1.2), a narrowing primitive conversion (5.1.3), a widening reference conversion (5.1.4), a narrowing reference conversion (5.1.5), a boxing conversion (5.1.7) or an unboxing conversion (5.1.8). Thus casting conversions are more inclusive than assignment or method invocation conversions: a cast can do any permitted conversion other than a string conversion. Value set conversion (5.1.10) is applied after the type conversion. Some casts can be proven incorrect at compile time; such casts result in a compile-time error. A value of a primitive type can be cast to another primitive type by identity conversion, if the types are the same, or by a widening primitive conversion or a narrowing primitive conversion. A value of a primitive type can be cast to a reference type by boxing conversion (5.1.7). A value of a reference type can be cast to a primitive type by unboxing conversion (5.1.8). JLS 15.12.2.2� Choose the Most Specific MethodIIf more than one method declaration is both accessible and applicable to a method invocation, it is necessary to choose one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most specific method is chosen. The informal intuition is that one method declaration is more specific than another if any invocation handled by the first method could be passed on to the other one without a compile-time type error. The precise definition is as follows. Let m be a name and suppose that there are two declarations of methods named m, each having n parameters. Suppose that one declaration appears within a class or interface T and that the types of the parameters are T1, . . . , Tn; suppose moreover that the other declaration appears within a class or interface U and that the types of the parameters are U1, . . . , Un. Then the method m declared in T is more specific than the method m declared in U if and only if both of the following are true: � � A method is said to be maximally specific for a method invocation if it is applicable and accessible and there is no other applicable and accessible method that is more specific. If there is exactly one maximally specific method, then it is in fact the most specific method; it is necessarily more specific than any other method that is applicable and accessible. It is then subjected to some further compile-time checks as described in �15.12.3 . It is possible that no method is the most specific, because there are two or more maximally specific methods. In this case: �
Otherwise, we say that the method invocation is ambiguous, and a compile-time error occurs. Copyright 2001-2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303 U.S.A. All rights reserved. |
