From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25108 invoked by alias); 18 Jun 2002 22:26:09 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 25060 invoked by uid 71); 18 Jun 2002 22:26:05 -0000 Date: Tue, 18 Jun 2002 18:17:00 -0000 Message-ID: <20020618222604.25045.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Tom Tromey Subject: Re: libgcj/7073: bytecode interpreter gives wrong answer for interface getSuperclass() Reply-To: Tom Tromey X-SW-Source: 2002-06/txt/msg00431.txt.bz2 List-Id: The following reply was made to PR libgcj/7073; it has been noted by GNATS. From: Tom Tromey To: jsturm@one-point.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: libgcj/7073: bytecode interpreter gives wrong answer for interface getSuperclass() Date: 18 Jun 2002 16:33:32 -0600 Jeff> For an interface class instance, getSuperclass() returns Jeff> java.lang.Object instead of null. This is inconsistent with the Jeff> behavior of compiled classes and the public documentation on Jeff> java.sun.com. Thanks, I added a Mauve tests for this, plus a related bug I found when looking at your test case. (Try void.class.getSuperClass()) I also got a failure when compiling from bytecode. The void thing is definitely a compiler bug. I think it must be a regression, but I haven't looked. `void.class' has to be rewritten to look up the `Void.TYPE' field. Tom