harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Cai" <greensi...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Tue, 16 Dec 2008 09:53:20 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message