commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [digester] collections and default for useThreadClassLoader
Date Sat, 07 Dec 2002 06:50:13 GMT
Craig R. McClanahan wrote:

>> In addition to the threadClassLoader:
> +1 on changing this default, by the way ... forgot to say that yesterday.

Thanks. That was the major issue.

>> Same for beanutils ( which is used quite extensively in digester,
>> and may be needed in modeler as well ).
> In [beanutils] it looks like the only use of [collections] is for
> FastHashMap, which is used to cache things that can still be read with no
> synchronization locks.  I suspect the performance impacts here would be
> more substantial and relevant than the [digester] direct dependencies; it
> probably needs more performance analysis before a decision.

What worries me more is the dependency on the Comparator in a public API.
That would make it impossible to remove beanutils->collection without
one backward incompatibility ( at least at source level - at runtime
it won't have any effect ).

Regarding FastHashMap - most my tests on JDK1.4 show absolutely no
difference. The cost for a lock that is allways unlocked is extremely
small. On the other side - if beanutils is in the top loader and 
gets accessed concurently by many apps - we may find some strange
errors if some of the locks are actually needed. 

I can add some code to check if FastHashMap is available and fallback.
I need to look a bit more at the code in beanutils.

There is also the issue of statics ( which become very visible when 
you move stuff to the top loader), and the issue of security - which is
particularily important for beanutil and probably in collections
( i.e. - if things are cached - can an application access other 
application's data ? Is there any thread that may change the 
security context ? )
And of course - Class.forName and things like that would create
yet another set of problems ( is all the code using the 
thread loader ? ). Pluse the difficulties to override some classes,
possible linkage errors on reverse loaders, etc.

( well, I know you know all this :-)


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message