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