On Tue, Dec 16, 2008 at 10:29 AM, Tim Ellison <[email protected]> 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
