hi all, first of all: I am a big fan of the avalon project. I hope I can someday contribute something to the project other than using and propagating it... ;-)
The following are ideas and questions I carry with me for a long time. One of the problem is that the java versioning mechanism is I think too weak. Loading is not effected by versioning since Class.forName or ClassLoader.loadClass only take a FQCN. And, the Package class (in the reflectioning api) is only available, when a class of that package already got loaded so you could only do versioning by using a separate "throw away" class loader, in order to get rid of a class that does not have the right version. In avalon-framework there is that Version class. But I can't find it elsewhere. I am using the excalibur component container and do some cocoon programming, but maybe I have overlooked the use of this Class inside the avalon component architecture. Please correct me here. I have also looked at the osgi spec (btw: there is an open source osgi implementation I found reasently: oscar-osgi.sf.net ). The osgi packaging mechanism is a bundle. I didn't get all the details of the osgi paper, so at this time I can't say anything specific about versioning other, than it is embedded in the manifest like the weak versioning spec of j2se 1.3+ (i think). The manifset is used to specify the version as well as the import and export dependencies. Also .Net (which I don't like much (I prefer java)) has something like that (nothing fancy): /* it is enought to just specify an assembly name here, but I would like to point out that the version exists */ Assembly a = Assembly.Load( "assemblyName, Version=a.b.c.d, ...." ); Object myObject = a.CreateInstance( "MyClass" ); instead of the java variant: Class c = ClassLoader.loadClass( "MyClass" ); Object myObject = c.newInstance( ); this (.NET) I think ressembles more the shared object (or dll) view, where you first load the shared object and then look into the shared object to find the function pointer (or in our case the type). Way all this? I would like to see a mechanism, by which java distinguishes the classes of specific versions, or better by which java uses modules ( or assemblies, plugins, bundles (however you call them) ) in its core. You see things like these coming out of every larger java community: netbeans has that module thing eclipse uses plugins osgi ueses bundles ... [ don't know about this one: jjar - the "jakarta jar" I've come accross the other day - it also uses versioning to automatically download the current jakarta dists of subprojects - still in design phase I think ... ] ... and the problem is you have to wrap everything to be used in netbeans, to be used in osgi and to be used in eclipse in a different way. Perhaps I am totally wrong here, and too many mandatory specifications are wrong, as they kill the openness java has proven, but I think it is a pitty that the jcp (or sun) has not better specified a mandatory way to do versioning and module loading. what are your thoughts about the versioning dilemma? thank you -- Jakob -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
