Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4723534
Votes 0
Synopsis multianewarray throws unexpected NegativeArraySizeException
Category kvm:vm
Reported Against 1.1b8
Release Fixed
State 11-Closed, Not a Defect, bug
Priority: 3-Medium
Related Bugs 4433326
Submit Date 31-JUL-2002
Description





The J2SE Virtual Machine specification 6.4 The Java Virtual Machine 
Instruction Set, says about multianewarray instruction :
"

...
  If any count value is zero, no subsequent dimensions are allocated.
  The components of the array in the first dimension are initialized 
  to subarrays of the type of the second dimension, and so on...
  
Runtime Exception
  Otherwise, if any of the dimensions values on the operand stack are 
  less than zero, the multianewarray instruction throws 
  a NegativeArraySizeException.  "

The specification is ambiguous.
    
kvm always throws NegativeArraySizeException when one of the dimension 
is negative even if previous one was zero.

But java1.3 and java1.4 do not throw exception in this case, because
they do not check for a negative dimension if one of the previous dimension 
was zero.
According to clarification in the bug 4433326:
"The first array element is zero size therefor we silently discontinue 
evaluating next array element size...
If user puts [1][-1] an exception will be thrown as desired and spec'd."

To reproduce this bug run the following test:
----------------------B.java--------------------------
public class  B {
    public static void main (String argv[]) {
        int arr [][];
        try {
             arr = new int[1][-1];
        } catch (Exception e) {
            System.out.println("Expected exception: "+e);
        }
        try {
             arr = new int[0][-1];
        } catch (Exception e) {
            System.out.println("FAILD: Unexpected exception: "+e);
            return;
        }
        System.out.println("Ok");
    }
}
----------------------------
%% javac -d tmp B.java
%% preverify -d . -classpath tmp:$KVM_PROMOTED/api/classes B
%% kvm -classpath . B
Expected exception: java.lang.NegativeArraySizeException
FAILD: Unexpected exception: java.lang.NegativeArraySizeException
%% java -classpath . B
Expected exception: java.lang.NegativeArraySizeException
Ok
---------------------------
======================================================================
Work Around
N/A
Evaluation
Evaluation excerpt from mail by Tim Lindholm (see comments for complete mail):

I think the JLS clarifies the intention of the JVMS and breaks the
potential ambiguity.  JLS 15.10.1, describing the semantics of array
creation expressions, says:

  [...]
  First, the dimension expressions are evaluated, left-to-right.  If
  any of the expression evaluations completes abruptly, the expressions
  to the right of it are not evaluated.
  
  Next, the values of the dimension expressions are checked.  If the
  value of any [dimension expression] is less than zero, then an [sic --
  "an" can't be right, can it?!] NegativeArraySize Exception is thrown.
  
  Next, space is allocated for the new array. [...allocation of a multi-
  dimensional array is given as equivalent to nested for loops each
  allocating one dimension...]

I read that to say that all the dimension expressions are evaluated
first, and the only problems noted at this point are expressions that
cannot be evaluated.  I do not think that an expression evaluating to
zero can be considered to have completed abruptly.  Then *all* the
evaluated dimension values are checked to be nonnegative, and only
after that is space allocated for the new array.  I don't see any way
to argue that encountering a zero dimension should terminate the
checking for nonnegative values.  But is the case that, as described,
encountering a zero dimension when allocating terminates allocation of the
subarrays.  So I conclude that KVM is right, and the test and HotSpot
are wrong!

Unfortunately, this gets us back to a variant of the philosophical
problem: the JLS appears to conflict with a longstanding behavior.
This might turn into something that Gilad and I have to worry about
resolving somehow, and it's possible that resolution would mean
deciding that the spec is in fact in error.  But in the meanwhile I
don't think you have a bug.

-- Tim

=========

Closing bug as 'not a bug' as per above evaluation.

  xxxxx@xxxxx   2002-08-22
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang