On Thu, Dec 18, 2008 at 5:43 AM, Tim Ellison <[email protected]> wrote: > Jack Cai wrote: >> I have another try following Alex's idea. See the patch here [1]. > > Yep, I think that does it! Thanks Jack. > > Tony / Alex, does that look good to you too? >
I'm happy with this patch. Thanks Jack. > I'm still unsure whether to have that catch Throwable as opposed to a > creating a helper that tests the instanceof without referencing the > Applet class directly, since the reference to Applet.class in the test > will cause the applet.jar to be loaded if it is available. > > What we need is a performant version of something like ... > boolean instanceOf(Object obj, String typeName) No more ideas, seem we have to chose between these, 1. try/catch 2. reflection The former has more overhead whereas the later has less compiler checking. > > Regards, > Tim > >> [1] >> https://issues.apache.org/jira/secure/attachment/12396303/HARMONY-6050_Jack.diff >> >> 2008/12/17 Tim Ellison <[email protected]> >> >>> Alex Blewitt wrote: >>>>> 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) >>>> I've attached such a proposed change to >>>> https://issues.apache.org/jira/browse/HARMONY-6050. Sorry I can't >>>> compile/test in-situ, but if someone can give that a go and run >>>> associated tests, that would be great. >>> I took another look, and it isn't so simple. While we know the caller >>> to the instantiate/4 method has got applet loaded, we also have to deal >>> with the case where instantiate/3 loads a bean of type Applet. >>> >>> We should not inadvertently load applet.jar by deferring /3 to /4, but >>> we still need to cope with potentially loading it for the /3 case. If >>> you are still following me... >>> >>> Regards, >>> Tim >>> >> > -- Tony Wu China Software Development Lab, IBM
