commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <>
Subject Re: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 12:03:50 GMT
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


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

View raw message