<snip/> > > an application using 1.x.b will work with component 1.x.a > > Does this sound reasonable? Missed something? > > Have you seen the guidelines in use by the Apache APR project? It looks > to me like you're basically advocating the same system they have in > place. It might save us hassle to just adopt their version numbering > system whole-sale (as the Spring Acegi Security subs(ystem does) > > http://apr.apache.org/versioning.html
Very funny - looks pretty identical to me ;-) So, yes, let's adopt this. I've not played around with classloading a lot, so I'm very curious if this will work. I'll try to start working on this if I'll find the time for it. If you are interested I could setup an account for you at my personal root server (I've installed Subversion). Or should I create a subproject in the commons-sandbox? As it's in stage of brainstorming I'd prefer to do it in my personal space first. Are you interested? Cheers, Daniel > > > I'd prefer to keep the "jar" naming as introducing "assembly" would > cause > > some confusion. > > If anyone would be interested I could put a simple proposal to the > sandbox. > > Good point, JAR may be a better name. I see two benefits to using > "assembly" or "assembler" as the name: > - Clearly indicates that you aren't dealing with plain-old-JAR files > anymore > - Parallels name used in .NET so that the analogy is directly obvious > > > This approach will not address the trouble that may be caused by > > applications not using this package. So finally I think that it is > required > > that this feature (or something comparable) will make it into Java 1.6. > > Up to then I still think it's a very simple but easy way to add the > version > > number to the package names to avoid at least the very big problems > > concerning incompatible jars in the same classloader. > > I understand your reasoning behind putting this code in Java 1.6, but I > think we can do this without a new release of the Java language (see > below). If our ideas are successful, this new Commons component could > always migrate later to a JSR proposal, as Doug Lea's concurrent package > did. > > With regards to problems caused by components that aren't using this new > package, I'm thinking that as long as the component does not make any > Class.forName calls, we should be OK. If there are Class.forName calls, > the component may still be able to work, but we would strongly encourage > a migration to using Assembly.getType or whatever. This entails the > component introducing a dependency on Assembler, which means the > Assembler API will need to maintain backwards compatability as much as > possible (e.g. - imagine the nightmare that would ensue if > java.util.Vector were to change its semantics!) > > > Regards, > > Daniel > > Matt > > >>-----Ursprüngliche Nachricht----- > >>Von: [EMAIL PROTECTED] > >>[mailto:commons-dev-return-64857- > [EMAIL PROTECTED] > >>Im Auftrag von Matt Sgarlata > >>Gesendet: Dienstag, 21. Dezember 2004 13:04 > >>An: commons-dev@jakarta.apache.org > >>Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares > >> > >>Chris Lambrou wrote: > >> > >>>Matt Sgarlata wrote: > >>> > >>> > >>>>Does this mean .NET doesn't have reflection? That's such a killer > >>>>feature of Java; I can't believe they wouldn't have ported it to .NET. > >>>>Any .NET developers out there that can tell us how .NET deals with > >>>>reflection when you have multiple versions of the same class? > >>> > >>> > >>>Since the class name alone is insufficient to fully identify a specific > >>>version of a class, to my knowledge there is no equivalent to > >>>Class.forName(String classname) in .NET. Instead, .NET has the Assembly > >>>class. An Assembly is roughly akin to a java jar file, and is typically > >>>a single DLL that contains one or more classes. Assembly has a > >>>non-static getType(String typeName) method, that performs the same job > >>>as the static Class.forName(String classname) method in java, but for a > >>>specific Assembly instance. There is never any ambiguity over which > >>>version of the named Type that is returned, since an Assembly can only > >>>contain one version of any given class. Support for multiple versions > of > >>>a class at runtime is achieved by storing those multiple class versions > >>>in separate Assemblies. > >> > >>Thanks for the info, Chris! This definitely sounds like a good > >>approach. Now my question is, can we simulate this in a new commons > >>component? :) > >> > >>Here are the steps I would imagine to be involved: > >>1) Define our own JAR sub-type to mirror the .NET assembly notion. > >>Include some type of a plain-text file that describes the versions of > >>the software required to perform certain tasks. It would be nice to do > >>this in an existing structure like MANIFEST.MF, but I don't know... are > >>you allowed to add arbitrary information to that file? In any case, we > >>wouldn't use the existing dependency descriptors because that would > >>prevent multiple versions of the same class from being loaded. > >>2) Call org.apache.commons.assembler.Assembler.getType(String > >>assembledPackage, String className). The Assembler would then go to the > >>assemblyPackage path on the classpath and search the plain-text file > >>from step #1 which would list the versions of classes that are required > >>by the given assembledPackage. For example, if assembledPackage was the > >>Digester, which required collections 3, the assembledPackage would be > >>org.apache.commons.digester. A dynamic proxy or generated bytecode > >>would be loaded that fulfilled the given contract and that would be > >>returned to the client. Any existing code that is just calling > >>Class.forName would have classes looked up in the normal way, so we > >>would need to make sure that this dynamic proxy doesn't get loaded into > >>the JVM in the same way as Class.forName (this is where the dynamic > >>proxy and/or bytecode generation comes in) > >> > >>What do you guys think? Does this sound feasible? I'd rather spin this > >>as a commons component than a J2SE 1.6 enhancement request, because the > >>later will take years to come to fruition. > >> > >> > >>>Chris > >> > >>Matt > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
