harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Wed, 17 Dec 2008 09:55:58 GMT
On Wed, Dec 17, 2008 at 5:54 PM, Tony Wu <wuyuehao@gmail.com> wrote:
> done for Encoder[1],
>
>
> I just defered the initializtion for awt and swing classes. I think it
> is not necessary to do a sync here since even more than one threads
> entered this initialization block, they do harm to functionality. Also

they do no harm to functionality I mean... :-(

> the overhead is acceptable, we will pay for no much extra effort than
> reading 2 boolean values and 2 getName.startWith, and when the
> awt/swing initialzion have been done once, it becomes reading 2
> boolean values only in each call. I also marked these booleans to
> volatile in order to minimize the potential overhead caused by cache.
>
> [1]
> http://svn.apache.org/viewvc?view=rev&revision=727324
>
> On Wed, Dec 17, 2008 at 4:23 PM, Tony Wu <wuyuehao@gmail.com> wrote:
>> done for StandardBeanInfo [1]
>>
>> In the cases for those beans which do not contain icons, the method
>> explicitBeanInfo.getIcon will always return null and it wont do any
>> type checking for its return value, therefore it will not try to load
>> java.awt.Image with this patch.
>>
>> [1]
>> http://svn.apache.org/viewvc?view=rev&revision=727043
>>
>> On Tue, Dec 16, 2008 at 11:54 PM, Regis <xu.regis@gmail.com> wrote:
>>> I found there are many places depended on awt/swing module, so I think we
>>> could move these code to one class first. This class only expose
>>> non-denpened API for others to use, so we can do all the trick things at one
>>> place, and it's also easy to re-implement and replace with non-depended
>>> code. Further more, if necessary, the implementation of this class could be
>>> specified at runtime just as IoC guys did, but maybe too complex for current
>>> requirements :)
>>>
>>> However, this way can't help for dependences in public API
>>>
>>> Tony Wu wrote:
>>>>
>>>> Hi, all
>>>>
>>>> Just came across a problem. when I was running beans without the
>>>> applet.jar in classpath, the jre throws "NoClassFoundExcetipn: Applet"
>>>> and exit even the bean class I was operating was not an applet. I did
>>>> a quick look into the Beans.java, there are some code  for applet
>>>> specific initialization,
>>>>
>>>> if (result != null) {
>>>>                        // Applet specific initialization
>>>>                        if (result instanceof Applet) {
>>>>                                appletLoaded((Applet) result, loader,
>>>> beanName, context,
>>>>                                                initializer, deserialized);
>>>>                        }
>>>>                        if (null != context) {
>>>>                                context.add(result);
>>>>                        }
>>>>                }
>>>>
>>>> I think at least we can make some change to the the line "result
>>>> instanceof Applet", such as getClass.getName.equals to avoid this
>>>> unexpected exit.
>>>> Furthermore, I just simply deleted the dependencies to some non-luni
>>>> classes in the manifest files. By tracing these compiler errors in
>>>> eclipse, I found there are some similiar cases in beans and other
>>>> modules as well, I'm going to tidy up these code and make our
>>>> modularity better.
>>>>
>>>> It is welcome if anyone has interest on this task and would like to help.
>>>
>>> --
>>> Best Regards,
>>> Regis.
>>>
>>
>>
>>
>> --
>> Tony Wu
>> China Software Development Lab, IBM
>>
>
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>



-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message