harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Tue, 16 Dec 2008 14:26:27 GMT
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:

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
since it doesn't work on Macs yet :-/

Alex

Mime
View raw message