Name: boT120536 Date: 12/05/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20000623 (JIT enabled:
jitc))


The JLS (2nd edition) needs to specify the behavior of the following lines of
code. Currently, there is no definitive description of what is to happen when
the null literal appears as an argument to the + or += operator, and various
compilers (I tested JDK1.3, JDK1.2.2, and IBM's jikes, version 1.12) treat these
examples differently.

==========
import java.io.Serializable;

public class Null {
  public static void main(String[] args) {
    Object o;
    Serializable[] ser;
    String s;

    o = null;
    s = o + null; // jikes complains that the type of o is not numeric
// jdk 1.2.2 complained that it can't convert o or null to int, and can't
// assign int to s
    printResult("Object (null) + null", s);
    o = new Integer(1);
    s = o + null; // same complaints
    printResult("Object (non-null) + null", s);
    ser = new Integer[1];
    s = ser[0] + null; // same complaints
    printResult("Serializable[0] + null", s);
    s = 1 + null; // same complaints
    printResult("Native + null", s);
    s = null + null; // same complaints
    printResult("null + null", s);

    o = "";
    o += null; // jikes complains that the type of o is not primitive
// jdk1.2.2 complains that o and null can't be converted to int
    printResult("Object (\"\") += null", o);
    o = null;
    o += null; // same complaints
    printResult("Object (null) += null", o);
    o = new Integer(0);
    o += null; // same complaints
    printResult("Object (Integer) += null", o);
    o = new Object[1];
    o += null; // same complaints
    printResult("Object (Object[1]) += null", o);
    
    ser = new String[1];
    ser[0] += null; // same complaints
    printResult("Serializable[0] (String) += null", ser[0]);
    ser = new Serializable[1];
    ser[0] += null; // same complaints
    printResult("Serializable[0] (Serializable) += null", ser[0]);
    ser = new Integer[1];
    try {
      ser[0] += null; // same complaints
      printResult("Serializable[0] (Integer) += null", ser[0]);
    } catch (ArrayStoreException e) {
      printResult("Serializable[0] (Integer) += null, caught " + e + ".",
ser[0]);
    }

    boolean b = "null" == "null" + "";
    printResult("\"null\" == \"null\" + \"\"", b);
    b = "1" == 1 + "";
    printResult("\"1\" == 1 + \"\"", b);
    b = "true" == true + "";
    printResult("\"true\" == true + \"\"", b);
    b = "null" == null + "";
    printResult("\"null\" == null + \"\"", b);
    b = "null" == (String)null + "";
    printResult("\"null\" == (String)null + \"\"", b);
    b = "nullnull" == null + null; // jikes complains the type is not numeric
    printResult("\"nullnull\" == null + null", b);
    b = "null1" == null + 1; // same complaints
    printResult("\"null1\" == null + 1", b);
    b = "null2" == null + new Integer(2); // same complaints
    printResult("\"null2\" == null + new Integer(2)", b);
  }
  
  static void printResult(String description, Object o) {
    System.out.println(description + ": " +
(o == null ? "null reference" :
(o instanceof String) ? "string \"" + o + "\"" : "non-string " + o));
  }
  static void printResult(String description, boolean b) {
    System.out.println(description + ": " + b);
  }
    
}
==========
Output with JDK1.3 compilation and VM:
Object (null) + null: string "nullnull"
Object (non-null) + null: string "1null"
Serializable[0] + null: string "nullnull"
Native + null: string "1null"
null + null: string "nullnull"
Object ("") += null: string "null"
Object (null) += null: string "nullnull"
Object (Integer) += null: string "0null"
Object (Object[1]) += null: string "[Ljava.lang.Object;@ea3952a7null"
Serializable[0] (String) += null: string "nullnull"
Serializable[0] (Serializable) += null: string "nullnull"
Serializable[0] (Integer) += null, caught java.lang.ArrayStoreException: .: null
reference
"null" == "null" + "": true
"1" == 1 + "": true
"true" == true + "": true
"null" == null + "": false
"null" == (String)null + "": false
"nullnull" == null + null: false
"null1" == null + 1: false
"null2" == null + new Integer(2): false

==========
Note that modifying the program to use casts solves some of the problems, but
not all. For example, jikes and JDK1.2.2 both compile:
  s = 1 + (String)null;
  ser = new String[1];
  ((String[])ser)[0] += null;

However, they still have problems with:
  o = "";
  o += (String)null; // o is not a primitive type

=========


Further, compare the output of this program with different compilers;
========
class Null1 {
  public static void main(String[] args) {
    boolean b;
    b = "null" == "null" + "";
    printResult("\"null\" == \"null\" + \"\"", b);
    b = "null" == null + "";
    printResult("\"null\" == null + \"\"", b);
    b = "null" == (String)null + "";
    printResult("\"null\" == (String)null + \"\"", b);
    b = "truenull" == "" + true + null;
    printResult("\"truenull\" == \"\" + true + null", b);
  }
  
  static void printResult(String description, boolean b) {
    System.out.println(description + ": " + b);
  }
    
}
========
Output when compiled under JDK1.2.2 or jikes:
"null" == "null" + "": true
"null" == null + "": true
"null" == (String)null + "": true
"truenull" == true + (String)null: true

Output when compiled under JDK1.3:
"null" == "null" + "": true
"null" == null + "": false
"null" == (String)null + "": false
"truenull" == true + (String)null: false

==========


The confusion comes from here:
JLS (2nd ed.) 15.18:
"If the type of either operand of a + operator is String, then the operation is
string concatenation.

"Otherwise, the type of each of the operands of the + operator must be a
primitive numeric type, or a compile-time error occurs."

15.26.2:
"All compound assignment operators require both operands to be of primitive
type, except for +=, which allows the right-hand operand to be of any type if
the left-hand operand is of type String.

"A compound assignment expression of the form E1 op= E2 is equivalent to E1 =
(T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only
once. Note that the implied cast to type T may be either an identity conversion
or a narrowing primitive conversion....:

"Otherwise, consider the array component selected in the previous step, whose
value was saved. This component is a variable; call its type S. Also, let T be
the type of the left-hand operand of the assignment operator as determined at
compile time....
" If T is a reference type, then it must be String. Because class String is
a final class, S must also be String. Therefore the run-time check that is
sometimes required for the simple assignment operator is never required for a
compound assignment operator.
" The saved value of the array component and the value of the right-hand
operand are used to perform the binary operation (string concatenation)
indicated by the compound assignment operator (which is necessarily +=). If this
operation completes abruptly, then the assignment expression completes abruptly
for the same reason and no assignment occurs.
" Otherwise, the String result of the binary operation is stored into the
array component."

5.1.4:
"The following conversions are called the widening reference conversions:...
      From the null type to any class type, interface type, or array type...."

5.4:
"String conversion applies only to the operands of the binary + operator when
one of the arguments is a String. In this single special case, the other
argument to the + is converted to a String, and a new String which is the
concatenation of the two strings is the result of the +. String conversion is
specified in detail within the description of the string concatenation +
operator."

15.28:
"A compile-time constant expression is an expression denoting a value of
primitive type or a String that is composed using only the following:

" Literals of primitive type and literals of type String
      Casts to primitive types and casts to type String
      The unary operators +, -, ~, and ! (but not ++ or --)
      The multiplicative operators *, /, and %
      The additive operators + and -
      The shift operators <<, >>, and >>>
      The relational operators <, <=, >, and >= (but not instanceof)
      The equality operators == and !=
      The bitwise and logical operators &, ^, and |
      The conditional-and operator && and the conditional-or operator ||
      The ternary conditional operator ? :
      Simple names that refer to final variables whose initializers are constant
expressions
      Qualified names of the form TypeName . Identifier that refer to final
variables whose initializers are constant expressions"

3.10.5:
"Each string literal is a reference to an instance of class String. String
objects have a constant value. String literals-or, more generally, strings that
are the values of constant expressions-are "interned" so as to share unique
instances, using the method String.intern."



  From these quotes, it appears JDK1.2.2 and jikes are correct in not treating
null + non-String reference as valid, because neither operand is a String, and
both operands are not native (15.18, 5,4). However, it could be argued that
since the null type is always castable to the String type (5.1.4), and the
String type is the only valid reference type appearing as an operand of +, that
an implicit widening conversion takes place as in JDK1.3; just as it would when
passing null as a parameter to a method that expects a String, when no method
overload causes null to be ambiguous.

Likewise, JDK1.2.2 and jikes seem to argue that if the left-hand argument of +=
is not a variable of native type or type String, that it is illegal (15.26.2,
first paragraph). However, when considering the second paragraph of the same
section, it only seems reasonable that o += s would correspond to
 o = (Object) (o + s); which is legal. Therefore, it sounds like the specs
should be modified to state that any variable of a type assignable from String
(Object, Serializable, Comparable, and String) may appear on the left of the +=
operator if the right-hand is of type String, as done in JDK1.3. Applying the
same argument as before, the null type can be implicitly widened to String.

All three compilers refused to compile o1 += o2 when neither operand is of type
String. However, you could consider making this another case for string
conversion of the right-hand argument, when the left-hand operand is of type
Object, Serializable, or Comparable, so that o1 += o2 corresponds to
 o1 = String.valueOf(o1) + o2. (Be careful when o2 is of type char[] to do the
right thing).

As for an array reference on the left-hand side of the += operator, you would
need to modify 15.26.2 to explicitly state that an ArrayStoreException is thrown
if the base type of the array being stored to is incompatible with the String
result produced by the operator.

Finally, it appears that JDK1.3 is strictly following the rules of compile-time
constants when any expression involving the literal null is not interned as a
constant (15.28, 3.10.5). However, it is certainly more convenient to do as in
JDK1.2.2 and jikes, and consider the literal null as a compile-time constant;
and thus consider that any string concatenation between null and another
compile-time constant produces a compile-time constant string. This uses less
memory and produces fewer bytecodes than the JDK1.3 approach of creating Strings
and StringBuffers when it is obvious that the (sub)string "null" will be
generated. Here, it seems like an oversight that the literal null was left off
the list in 15.28. You may also want to add that the expression
 null instanceof TypeName
is also a compile-time constant (false). For example, this would allow the
detection of this infinite loop:
 while ( ! (null instanceof Object) );
(Review ID: 108590)
======================================================================