harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Thu, 18 Dec 2008 06:32:33 GMT


Tony Wu wrote:
> On Thu, Dec 18, 2008 at 5:43 AM, Tim Ellison <t.p.ellison@gmail.com> 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

Is this dependency problem a common case or just for beans module? If it 
a common case, I think we may should find a better way to resolve it. If 
not, I suggest to create a helper class to do these trick things.

> 
> 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 <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
>>>>
> 
> 
> 

-- 
Best Regards,
Regis.

Mime
View raw message