From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26370 invoked by alias); 13 Mar 2006 19:07:08 -0000 Received: (qmail 26261 invoked by uid 48); 13 Mar 2006 19:07:07 -0000 Date: Mon, 13 Mar 2006 19:07:00 -0000 Message-ID: <20060313190707.26259.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug java/26390] Problem dispatching method call when method does not exist in superclass In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "tromey at gcc dot gnu dot org" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2006-q1/txt/msg00378.txt.bz2 List-Id: ------- Comment #7 from tromey at gcc dot gnu dot org 2006-03-13 19:07 ------- The bug here is that gcj implements method inheritance incorrectly. In particular it does not consider SwingWindowPeer.setBounds as a candidate method for the super.setBounds() call, because it has no notion that there is a method named "SwingWindowPeer.setBounds". Instead it only considers SwingComponentPeer.setBounds -- which is not maximal and thus not selected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390