commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 18:47:40 GMT
Don't you get to this same result by creating your own URLClassLoader
for each "assembly", with its own set of JARs and/or directories
making up its "class path"?


On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata
<> wrote:
> 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:
> For additional commands, e-mail:

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

View raw message