From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6597 invoked by alias); 8 Apr 2003 14:29:43 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 6579 invoked from network); 8 Apr 2003 14:29:42 -0000 Received: from unknown (HELO email1.byu.edu) (128.187.22.133) by sources.redhat.com with SMTP; 8 Apr 2003 14:29:42 -0000 Received: from email.byu.edu ([10.7.224.202]) by EMAIL1.BYU.EDU (PMDF V6.2 #30538) with ESMTPA id <01KUH8CBNSI68XQ8UA@EMAIL1.BYU.EDU> for mauve-discuss@sources.redhat.com; Tue, 08 Apr 2003 08:29:09 -0600 (MDT) Date: Tue, 08 Apr 2003 14:29:00 -0000 From: Eric Blake Subject: Re: FW: Question about Java Lang testcase JAVA.LANG.REFLECT.ARRAY.NEGATIVEARRAYSIZEEXCEPTION To: Patrick Ellis Cc: mauve-discuss Message-id: <3E92DCE9.8040200@email.byu.edu> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: X-SW-Source: 2003-q2/txt/msg00011.txt.bz2 More quotes from Sun (by the way, I was the submitter of the bug you quote from, 4433326): http://developer.java.sun.com/developer/bugParade/bugs/4433326.html FWIW, this contradicts the JVMS and the JLS. So it is a bug. I doubt if it makes a big difference to anyone either way, but the KVM behaves differently (and for once, they're right). xxxxx@xxxxx 2002-07-31 http://developer.java.sun.com/developer/bugParade/bugs/4723534.html 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 Patrick Ellis wrote: > Eric, > > I forgot to include a comment made by Sun. > > > This is a comment from one of our designers ...... > I think this is a gray area that would be classified as "interpretation of the spec.". All the vendors get the same spec to implement, but the interpretation of things not explicitly stated varies. This would probably fall into that category, but in the bug that was submitted to Sun (about two years ago) that is pretty much the exact same example you have in your code, Sun stated that they do not consider this to be a bug. There are lots of cases where IBM and other vendors have tightened up the functionality over and above what the spec states as being required. > >>From Sun: > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > "The first array element is zero size therefore we silently discontinue evaluating next array element size. This will not be fixed. This is not a bug. If user puts [1][-1] an exception will be thrown as desired and spec'd. Closing as a will not fix. xxxxx@xxxxx 2002-04-08" > -- This signature intentionally left boring. Eric Blake ebb9@email.byu.edu BYU student, free software programmer