commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject {logging] demonstration/proof of concept code and analysis
Date Sat, 26 Mar 2005 17:10:10 GMT
i've committed the analysis of parent and child cases with demonstration
code. it's under trunk/demonstration (for now). i'm not sure whether
this is the right place or not but it should be easy to move later if
necessary. i'd like to invite people to point out any mistakes and would
welcome opinions (whether good or bad).

i haven't analysed how JCL measured up against the theory yet. i thought
i'd give everyone the chance to run the demonstrations themselves and
come up with their thoughts independently. anyone want to volunteer to
pull together some sort of summary about where JCL is now as measure by
theoretical and practical performance.

after these recent exercises, i now feel a lot more confident about the
theory. i hope other people will take this opertunity to travel down the
same road. it may be a little long but the reward is a solid
understanding of class loading.

a couple of interesting points have emerged from this investigation into
the theory side.

1. it looks like those who first analysed the static verses dynamic
binding issue were correct in theory: it should be possible to address
many more use cases through use of dynamic binding than can be address
by static. the price is that the dynamic binding is much harder to
implement and fails in more mysterious ways. i now have confidence that
it should be possible to address the first matter and create improved
troubleshooting documentation which helps with the second.

2. there are a number of child-first cases where an implementation jar
would solve theoretical problems which prevent dynamic discovery
functioning. these are the only cases where (in theory) static binding
offers an improvement over dynamic binding. brian's implementation jar
approach is therefore correct in principle. 

of course, the real benefit of static binding is it's performance under
unconventional context classloaders. the analysis of these cases is
pending. anyone want to volunteer to take this on?

i'm now actually more hopeful than i've been in a long time that
provided the community works together, it should be possible to see an
improvement in the number of cases that JCL can theoretically function
in (thanks to adding an implementation jar) and also a major improvement
in the number of cases where JCL performs to specification. but there's
plenty to do and the more people volunteer to help, the quicker it will
get fixed :)

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message