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 <[email protected]> > 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 <[email protected]> > 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 > >>> <[email protected]> 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 <[email protected]>: > >>>>> 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 > >>>> > >>> > >>> > > >
