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 gain. 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 not. > 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 users. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
