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 08:23:04 GMT
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.


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

View raw message