commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] commons logging stubs [was Re: [jci] c#]
Date Wed, 09 Nov 2005 21:14:39 GMT
On Wed, 2005-11-09 at 12:48 +0100, Torsten Curdt wrote:
> > I also talked about removing the commons-logging dependency (which  
> > seemed to be in agreeance at the time),
> > as at least in our environment we don't use it.
> The more I think about this the more I get the opinion we should
> also provide a commons-logging-stub.jar to satisfy commons-logging
> dependencies if you don't like to use it.

IMO the fatal flaw with the original JCL design was that the api jar is
not a minimal functional implementation. we could have developed a
solution if only the original design hadn't suffered from this flaw. the
problem with fixing this is backwards compatibility. 

i agree with ceki that the future is static (rather than dynamic)
binding. i prefer bytecode engineering to different compilation. 

> I know there has been put quite some effort in fixing CL
> but I fear fixing the reputation is a different issue.

a lot of work has certainly been put into analysing JCL. the problems
are know pretty well understood. those willing to spend time reading the
technical documentation and analysis will find there's quite a lot to

it a lot of the criticisms were ill-informed. there are a number of
valid criticisms about JCL which apply equally to a vast number of other
libraries created around the same time. there are a number of valid
criticism which are consequences of adopting a dynamic binding policy
but they are in the minority.

at least, ceki was willing to back up his criticisms with illustrations
and code. though he most of his examples could be fixed (and were), it
spurred analytic work to classify the problematic use cases which could

> Can a new release of CL rule out all the classloading problems
> people had before?

the consensus is that these problems arise from the combination of
broken specifications, popularity and ignorance amongst users about
classloading issues.

the current code is provably superior to the existing codebase. most of
the difficult use cases are known and good configurations are know for
the vast majority of reasonable use cases. the memory leaks are fixed
for most reasonable configurations. we've made a lot of progress but the
work is hard and very unrewarding. there are also fundamental issues
with various broken J2SE and J2EE standards which cannot be fixed.

whether that's of any use to a standard user is a moot point. JCL is
tasked with coping with many very obscure classloading use cases. by
very careful arrangement of jars, JCL will now with most - but not all -
of these. 

IMO is isn't possible to create a library that 'just works right' in
every possible classloading use case without assuming some level of user
knowledge. there's some demonstration code that illustrates this. the
real question is what level of knowledge is reasonable to expect amongst

but the basic problem remains unsolved. i've seen many alternative
proposals which would have fared as bad or worse when faced with the
problems that come with widespread use. 

ceki's approach is (on the other hand) very well informed and analysed.
i suspect that given sufficient popularity, it will encounter some of
the issues as JCL (the ones arising from user ignorance and broken
specifications) but has the advantage of being designed with the
knowledge of those difficulties and has a good team working on it.  

- robert

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

View raw message