From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1541 invoked by alias); 23 Mar 2004 23:59:48 -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 1516 invoked from network); 23 Mar 2004 23:59:39 -0000 Received: from unknown (HELO power.connexus.net.au) (203.12.22.20) by sources.redhat.com with SMTP; 23 Mar 2004 23:59:39 -0000 Received: from dholmeslaptop (dholmes.dltech.com.au [203.222.72.2]) by power.connexus.net.au (8.12.4/8.11.6) with SMTP id i2NNu9hZ036427; Wed, 24 Mar 2004 10:56:11 +1100 (EST) (envelope-from dholmes@dltech.com.au) XAntiVirus: This e-mail has been scanned for viruses via the Connexus Internet Service From: "David Holmes" To: "Archie Cobbs" Cc: "Robert Lougher" , , , , , Subject: RE: ClassLoader.findLoadedClass (was: ServiceFactory) Date: Tue, 23 Mar 2004 23:59:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <200403231647.i2NGlFrX002230@arch20m.dellroad.org> X-SW-Source: 2004-q1/txt/msg00026.txt.bz2 Archie Cobbs wrote: > JC will record C in the (internal to the VM) initiated types table > associated with a class loader L if and only if: > > (a) L is the defining loader for C (i.e., L.defineClass(C) was called); or > > (b) L.loadClass(C) successfully returns after being called **from > within the VM itself** (e.g., as a result of the VM's trying > to resolve a symbolic reference). > > So if another loader L2 delegates the loading of C to L, then L is not > marked as an initiating loader for C, as neither (a) nor (b) happens. > > Is this consistent and/or correct with the current understanding? Sounds consistent and correct to me. > Also: this discussion seems to imply that we require a native method > that findLoadedClass() can use to ask the VM to look for C in its internal > initiated types table associated with L.. is that correct? As findLoadedClass is a final method in ClassLoader I consider its implementation part of the VM - as long as it and other parts of the VM use the same lookup table you can do whatever you like here. That said it seems to me that the lookup table defined in ClassLoader should be moved to VMClassLoader. That way we would have: ClassLoader.findLoadedClass(n) calls VMClassLoader.findLoadedClass(this, n) and ClassLoader.defineClass calls VMClassLoader.defineClass(this, ...) and VMClassLoader.defineClass can then update the lookup table however it is implemented in that VM. VMClassLoader can define a default mechanism using hashtables or just leave things native. Or in simple words: move the lookup table out of ClassLoader into VMClassLoader. David Holmes