From dev-return-35656-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Dec 16 10:30:21 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 70933 invoked from network); 16 Dec 2008 10:30:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Dec 2008 10:30:21 -0000 Received: (qmail 65923 invoked by uid 500); 16 Dec 2008 10:30:32 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 65890 invoked by uid 500); 16 Dec 2008 10:30:32 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 65878 invoked by uid 99); 16 Dec 2008 10:30:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Dec 2008 02:30:32 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com designates 209.85.219.20 as permitted sender) Received: from [209.85.219.20] (HELO mail-ew0-f20.google.com) (209.85.219.20) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Dec 2008 10:30:11 +0000 Received: by ewy13 with SMTP id 13so3459260ewy.12 for ; Tue, 16 Dec 2008 02:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=0JuMFx+QFnf8cy/0s7oh95nq6Hi0GL5kJAY/wFIS1Dc=; b=QVfdJ4mM7WCaS8wdv0XtfyHjtqXZMxTwQhXXfw6/hEwV8w2sENsvZ8wNme/2QMMJuU alZtRpkbrsJwIPP6vz+BDhAM0Stij21Gwo6MvOCxErH8cWTzQ6+5CGmsATcuD5iACNOY CJ+uIiLGWXj6GW6THbsUtW0UkEU8/2JLKMZhI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wWmZeHVtVRccKNdcc4GLMpnzJ51nJKuEFC4O72LkuWocy7ldBnHRAi9P0v5i1896o1 x3nLSSmoqwUc8tX6n6B9l/F2c29tTiudTtkZgC6RS4aojBpYG7oPrSKd+uD5gcLxHUHk 1ETcMVpfEMiHNa3+J5lEeR6Ml7vc3t7CILS/0= Received: by 10.210.16.10 with SMTP id 10mr2817294ebp.94.1229423389546; Tue, 16 Dec 2008 02:29:49 -0800 (PST) Received: from ?9.20.183.186? (blueice2n1.uk.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id g12sm2835807nfb.6.2008.12.16.02.29.48 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 02:29:48 -0800 (PST) Message-ID: <49478319.5040302@gmail.com> Date: Tue, 16 Dec 2008 10:29:45 +0000 From: Tim Ellison User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: Re: [classlib]Make harmony's modularity better References: <211709bc0812150226u2e49fa42u7acb999391d49fd4@mail.gmail.com> <49464A9D.3070904@gmail.com> <3b3f27c60812150723n25b0af8t3ac9d82f5c623e52@mail.gmail.com> <4946C2B9.1040702@gmail.com> <211709bc0812160035hb336ab0j30ce8d58e8d136ce@mail.gmail.com> In-Reply-To: <211709bc0812160035hb336ab0j30ce8d58e8d136ce@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Tony Wu wrote: > another choice, > set some properties like hy.no.applet, and then we can do anything we > want for modularity in our code without any overhead to performance or > compiler checking. Whenever we want a specific modularity, we can > achieve that simply by resetting these properties. what's your > opinion? How do you see that property being set? The advantage of checking for the existence of the _class_ each time is that you can drop in the applet.jar and it will start to work. If we do the test on properties then we will need a (only slightly) more complex provisioning story that includes "drop in the JAR" and "set/clear a property". I agree that a solution with minimal runtime overhead is desirable, and we may need to bias an implementation choice for one case or the other (i.e. you expect Applet to be there, or you expect Applet not to be there). Regards, Tim > On Tue, Dec 16, 2008 at 4:48 AM, Tim Ellison wrote: >> Nathan Beyer wrote: >>> What are the guarantees of dynamic class loading? I've never been >>> quite sure what you can and can't get away with. >> Depends what you mean by 'guarantee'? >> >> The class is loaded at the first reference to it, or as the VM spec [1] >> says: >> "Creation of a class or interface C [...] is triggered by another class >> or interface D, which references C through its runtime constant pool. >> Class or interface creation may also be triggered by D invoking methods >> in certain Java class libraries (§3.12) such as reflection." >> >> [1] >> http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#72007 >> >>> Wouldn't the bit below need to catch ClassNotFoundError? An >> The 'bit below' is protected by the isApplet test, so if we figured out >> it was not an applet we won't reference the Applet class again. >> >> However, my code below won't compile, since ClassNotFoundException is a >> checked exception, so we'd need to do a Class.forName() in the exception >> handler rather than instanceof. >> >> Regards, >> Tim >> >>> On Mon, Dec 15, 2008 at 6:16 AM, Tim Ellison wrote: >>>> Alexei Fedotov wrote: >>>>> I like when a compiler does a hard job of type and method checking. >>>>> Why should we use reflection and hide applet dependency, hence >>>>> prohibiting the compiler to check things for us? >>>> Right. >>>> >>>> Why not make use of Java's dynamic loading ... something like this >>>> (untested): >>>> >>>> Index: src/main/java/java/beans/Beans.java >>>> =================================================================== >>>> --- src/main/java/java/beans/Beans.java (revision 725055) >>>> +++ src/main/java/java/beans/Beans.java (working copy) >>>> @@ -198,7 +198,13 @@ >>>> >>>> if (result != null) { >>>> // Applet specific initialization >>>> - if (result instanceof Applet) { >>>> + boolean isApplet = false; >>>> + try { >>>> + isApplet = result instanceof Applet; >>>> + } catch (ClassNotFoundException e) { >>>> + // Ignored - leave isApplet as false. >>>> + } >>>> + if (isApplet) { >>>> appletLoaded((Applet) result, loader, beanName, context, >>>> initializer, deserialized); >>>> } >>>> >>>> >>>> Regards, >>>> Tim >>>> >>>>> If this was C, I'd made a common header describing initialization for >>>>> two modules. >>>>> >>>>> Thanks. >>>>> >>>>> On Mon, Dec 15, 2008 at 2:35 PM, Sian January >>>>> wrote: >>>>>> Hi Tony, >>>>>> >>>>>> I think it would be very good if we could minimise unnecessary >>>>>> dependencies between Harmony modules. I would definitely like to get >>>>>> involved with this. >>>>>> >>>>>> For the specific example, don't forget that Applet is not final so >>>>>> could be subclassed, in which case class.getName() would return >>>>>> something else. However you should still be able to do it with >>>>>> refection, (e.g. something like >>>>>> Class.forName("java.applet.Applet").cast(result)) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Sian >>>>>> >>>>>> >>>>>> 2008/12/15 Tony Wu : >>>>>>> Hi, all >>>>>>> >>>>>>> Just came across a problem. when I was running beans without the >>>>>>> applet.jar in classpath, the jre throws "NoClassFoundExcetipn: Applet" >>>>>>> and exit even the bean class I was operating was not an applet. I did >>>>>>> a quick look into the Beans.java, there are some code for applet >>>>>>> specific initialization, >>>>>>> >>>>>>> if (result != null) { >>>>>>> // Applet specific initialization >>>>>>> if (result instanceof Applet) { >>>>>>> appletLoaded((Applet) result, loader, beanName, context, >>>>>>> initializer, deserialized); >>>>>>> } >>>>>>> if (null != context) { >>>>>>> context.add(result); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> I think at least we can make some change to the the line "result >>>>>>> instanceof Applet", such as getClass.getName.equals to avoid this >>>>>>> unexpected exit. >>>>>>> Furthermore, I just simply deleted the dependencies to some non-luni >>>>>>> classes in the manifest files. By tracing these compiler errors in >>>>>>> eclipse, I found there are some similiar cases in beans and other >>>>>>> modules as well, I'm going to tidy up these code and make our >>>>>>> modularity better. >>>>>>> >>>>>>> It is welcome if anyone has interest on this task and would like to help. >>>>>>> -- >>>>>>> Tony Wu >>>>>>> China Software Development Lab, IBM >>>>>>> >>>>>> -- >>>>>> Unless stated otherwise above: >>>>>> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>>>>> >>>>> > > >