Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 11718 invoked from network); 10 Jun 2005 07:33:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Jun 2005 07:33:22 -0000 Received: (qmail 53091 invoked by uid 500); 10 Jun 2005 07:32:45 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 53045 invoked by uid 500); 10 Jun 2005 07:32:44 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 53030 invoked by uid 99); 10 Jun 2005 07:32:44 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from imag.imag.fr (HELO imag.imag.fr) (129.88.30.1) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 10 Jun 2005 00:32:43 -0700 Received: from [129.88.103.2] (invite2.imag.fr [129.88.103.2]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j5A7WBBv014729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jun 2005 09:32:13 +0200 (CEST) Message-ID: <42A94210.9060102@ungoverned.org> Date: Fri, 10 Jun 2005 03:32:32 -0400 From: "Richard S. Hall" User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [modules] Packaging Class Libraries References: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org> <42988D8A.6000907@ungoverned.org> <2132.10.0.20.199.1117406128.squirrel@10.0.20.2> <429ABF70.8090300@ungoverned.org> <42A73E87.8060208@kaffe.org> <42A74070.1010300@ungoverned.org> <7D6F9432-26D8-4C7D-B3E0-DC1D81BA40C2@apache.org> <42A7FC13.7000201@ungoverned.org> <8cca42d805060910342a806a7e@mail.gmail.com> <42A88FC8.2070700@ungoverned.org> <8cca42d80506091242771402e3@mail.gmail.com> In-Reply-To: <8cca42d80506091242771402e3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Fri, 10 Jun 2005 09:32:13 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Rodrigo Kumpera wrote: >AFAIK the term extension classloader is used for application created >classloaders. The application classloader handles classpath and >installed extends (the dreaded /lib/ext directory). > > Well, just writing a simple program that prints the class loaders, I get: loader = sun.misc.Launcher$AppClassLoader@7b7072 loader = sun.misc.Launcher$ExtClassLoader@136228 loader = null Where the "null" represents the bootstrap class loader, so I still count three, but I don't think this adds much to the discussion. :-) >In terms of extensibility, the classlib is mostly a dead-end, an >end-user should be better using some SPI. But good modularity keeps >the software entropy low. > > I am not sure what you are referring to with "classlib" here. >I think a build time "good citizenship" test can do just fine, so no >module mess with other's internals unless it's specified. Having >export/import controls for the public API (the j2se api) seens allmost >unreasonable. > > Build-time test? What about code compiled by another compiler? This doesn't make much sense to me. >But if the JVM is build all in java, or big chunks at least, using an >OSGi like thing is a very good idea for managing the implementation. > From my experience, it makes sense, period. -> richard