From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14283 invoked by alias); 23 Mar 2004 17:25:26 -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 14140 invoked from network); 23 Mar 2004 17:25:18 -0000 Received: from unknown (HELO mxsf02.cluster1.charter.net) (209.225.28.202) by sources.redhat.com with SMTP; 23 Mar 2004 17:25:18 -0000 Received: from InterJet.dellroad.org (E6V6Q8.cpe.mvllo.al.charter.com [24.196.29.251]) by mxsf02.cluster1.charter.net (8.12.10/8.12.8) with ESMTP id i2NH0Epg070852; Tue, 23 Mar 2004 12:00:15 -0500 (EST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.2.2.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA77581; Tue, 23 Mar 2004 10:47:18 -0600 (CST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.9p2/8.12.6) with ESMTP id i2NGlHdK002231; Tue, 23 Mar 2004 10:47:17 -0600 (CST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.9p2/8.12.9/Submit) id i2NGlFrX002230; Tue, 23 Mar 2004 10:47:15 -0600 (CST) (envelope-from archie) From: Archie Cobbs Message-Id: <200403231647.i2NGlFrX002230@arch20m.dellroad.org> Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory) In-Reply-To: To: David Holmes Date: Tue, 23 Mar 2004 17:25:00 -0000 CC: Robert Lougher , brawer@dandelis.ch, chris@kiffer.eunet.be, aph@redhat.com, classpath@gnu.org, mauve-discuss@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2004-q1/txt/msg00025.txt.bz2 David Holmes wrote: > Allow me to take a walk through the spec here :) This is all very interesting and making my brain hurt :-) I'm trying to figure out now if the JC vm does the right thing. Hopefully this email will not add to the confusion. 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? 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? At one time I remember concluding that to satisfy the specs, even though the ClassLoader object may have a Hashtable of loaded classes or whatever, the VM must have its own internal initiated types table associated with each class loader. If this is true, then findLoadedClass() simply needs to look into it - requiring a native method. I believe this is because the VM can't rely on the ClassLoader implementation to do the right thing with respect to not trying to load the same class twice. Classpath has this: protected final synchronized Class findLoadedClass(String name) { // NOTE: If the VM is keeping its own cache, it may make sense to have // this method be native. return (Class) loadedClasses.get(name); } Perhaps then the comment should be removed and this method made native always? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com