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 Wed, 17 Dec 2008 21:43:59 GMT
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 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)

Regards,
Tim

> [1]
> https://issues.apache.org/jira/secure/attachment/12396303/HARMONY-6050_Jack.diff
> 
> 2008/12/17 Tim Ellison <t.p.ellison@gmail.com>
> 
>> 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
>>
> 

Mime
View raw message