On Wed, Dec 17, 2008 at 5:54 PM, Tony Wu <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
