commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <>
Subject Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 14:11:55 GMT
Daniel Florey wrote:
> In order to find an appropriate solution to this issue, I'd like to identify
> the different problems that we need to address.
> Version: What does a version number mean?
> I'll make a proposal for how to use minor/major version number to have a
> basis on which we can identify the issues.
> Major version numbers indicate that some public API methods have been
> changed in semantics or have been removed. So an application using
> component-1.x might not work with component-2.x
> Minor version numbers indicate that the component remains backward
> compatible, but new methods may have been introduced.
> So an application using component-1.x will work with component-1.y if y>0,
> but an application component-1.y might fail when using component 1.x
> A build number might indicate that private methods have changed without
> affecting the public api.
> So an application using component 1.x.a will work with component 1.x.b and
> 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 subsystem does)

> 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 

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


>>-----Urspr√ľngliche Nachricht-----
>>Im Auftrag von Matt Sgarlata
>>Gesendet: Dienstag, 21. Dezember 2004 13:04
>>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.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message