On Wed, 2005-03-09 at 07:24, Torsten Curdt wrote: > <snip/> > > > it's a little ironic that both richard and i have held that opinion for > > a long while now. however, ceki's and brian's investigations are now > > starting to persuade me that there is actually some hope for much > > improved discovery from the 1.0.x series of releases. > > > > there are a number of subtle issues (well, they seem subtle to me) about > > salvaging the interfaces. it's more difficult that it should be. not > > being able to fix them easily is what i have always regarded as the JCL > > fatal flaw. > > > > i think that there are ways to maintain backwards compatibility which > > should also allow the interfaces to be salvaged for reuse by different > > implementations. i was working on code along these lines but i only have > > so much energy and most of it (over the last few weeks) has been taken > > up replying to ceki's posts and analysing ceki's examples (or so it > > seems to me). > > No matter what - it more and more seems like > the discovery mechanism builds up a front > of people that more and more dislike JCL.
+1 > TBH I am pretty much sick of those discussion > whether to use JCL or not that come up in other > projects. IMHO it would be great to fix (as > good as possible) what people are complaining > about. JCL lacks energy and community. it's a tough project to work on and it's a pretty thankless task. i think that there's hope but only if the community can rally round. > My perception is that JCL is a great idea and > does the job ...but as soon as you have a > slightly more complicated classloader setup. > Man - you better know what you are doing! that's true :) one of the problems is distinguishing those cases where discovery is prohibited by the java language specification from those where discovery may be theoretically possible but JCL falls short. this is partly an education problem: there really isn't good enough documentation to distinguish those cases. i'll try to find time to create a document (a little like ceki and brian's) that goes through the possible classloader scenarios in a simple fashion and details those which aren't possible. > I personally don't care much of backwards > compatibility of a problematic discovery > mechanism but for sure that's what new major > versions are for. This could be fixed in a > 2.x version. my concern is that discovery is something that sounds easy but is actually tough. when you look at the names on the list of folks who've given it a shot and only managed a partial solution, it's not from want of technical expertise or J2EE experience: it's difficult. (i didn't code the discovery stuff.) my considered opinion is that discovery can be improved in the 1.0.x series of releases but that there will be cases when it falls short (you can decide whether these cases are fatal flaws or corners). in these cases static binding is better. where i disagree with ceki is that i don't think that static binding is the whole solution. language restrictions prevent certain combinations working. i suspect that (compile time) static binding may have as many corner cases as dymanic binding (but i'd need to analyse the case and come up with some examples). education about these cases seems to be very important. i believe that these difficult cases could be addressed by doping the implementation using byte code engineering. (the idea is that you statically bind not JCL but the calls themselves from the code.) the discovery stuff is in LogFactory and is exposed in such a way that it's hard to deal with without losing backwards compatibility. i think that it can be addressed by lifting off a super class (JCL, say) with a reduced interface which is bound (either statically or dynamically) to a (possibly) more complex implementation. this super class would be very simply and configurable dynamically in only a small number of simple ways. it could alternatively be bound statically at compile time. this way of proceeding would preserve compatibility with the existing JCL installation base and the 1.0.x series of discovery could continue as JCL classic which could be bound to the super class when required. i think that such a set up would cover the use cases i'm aware of. however, it's a complex solution. i'm also aware of how much effort is involved. support would be needed from the community if this is going to have a chance of succeeding especially in the thankless tasks of creating documentation and unit tests for all those corner cases ;) anyone think that this approach is worth pursuing? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
