harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Tue, 16 Dec 2008 14:59:26 GMT
Alex Blewitt wrote:
> On Tue, Dec 16, 2008 at 10:29 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> 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).
> The JVM will delay ClassNotFoundExceptions until they're actually
> called. However, the initializer for the Bean class has it as its
> method signature, which occurs a lot earlier on than when the code is
> called:

For sure, there are a few other references to consider.  Unfortunately
the API is a bit of a mess, and we have to live with that part, and do
tricks internally to make things more easily separable.

> public static Object instantiate(ClassLoader cls, String beanName,
> 			BeanContext context, ***AppletInitializer initializer***)
> 			throws IOException, ClassNotFoundException {
> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/beans/src/main/java/java/beans/Beans.java?view=markup
> That in turn defines AppletInitializer, which has a reference to
> Applet in the class:
> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/beans/src/main/java/java/beans/AppletInitializer.java?view=markup
>     public void initialize(Applet newAppletBean, BeanContext bCtxt);
>     public void activate(Applet newApplet);
> }
> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/beans/src/main/java/java/beans/AppletInitializer.java?view=markup
> Those are both public APIs so pretty tricky to change, I'd imagine.
> However, the code in place does:
> Beans. instantiate/2 -> Beans. instantiate/4
> Beans. instantiate/3 -> Beans. instantiate/4
> So both instantiate/2 and /3 will fail, even if you pass in a 'null'.
> But the solution would be to do:
> Beans. instantiate/2 -> Beans. instantiate/3
> Beans. instantiate/3 (does the work)
> Beans. instantiate/4 -> Beans. instantiate/3 (and calls the applet initialiser)
> That way, going in through the /2 or /3 arg call path, you don't
> trigger the function signature required to do the work. Seem
> reasonable? I can whack a quick patch together but can't try it out

Yep, since we know that any reference to the method that takes a
parameter of type AppletInitializer must have got the Applet module
loaded (or else they wouldn't have a reference to an AppletInitializer!).

If you want to post a patch I'll try it.

> since it doesn't work on Macs yet :-/

Not got it working yet ?! <g>


View raw message