Alex Blewitt wrote:
> 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:
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>
Regards,
Tim
