harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Tue, 16 Dec 2008 10:16:39 GMT
Jack,

That won't help. AFAIU exception is thrown early on class
verification, rather on class method execution.

WBR,
    Pavel.

On Tue, Dec 16, 2008 at 12:53 PM, Jack Cai <greensight@gmail.com> wrote:
> Well, we can catch a Throwable instead of a checked exception. This will
> also catch Error. We can re-throw non-class-not-found exceptions/errors.
>
> -Jack
>
> 2008/12/16 Tim Ellison <t.p.ellison@gmail.com>
>
>> 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 <t.p.ellison@gmail.com>
>> 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
>> >>> <sianjanuary@googlemail.com> 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 <wuyuehao@gmail.com>:
>> >>>>> 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
>> >>>>
>> >>>
>> >>>
>> >
>>
>

Mime
View raw message