commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <>
Subject Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 19:34:56 GMT
Count me in!  I'm planning on taking some time off for the holidays, so 
that should give me time to play around with this :)


Daniel Florey wrote:
> <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)
> 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
>>>some confusion.
>>>If anyone would be interested I could put a simple proposal to the
>>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
>>- 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
>>>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
>>>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!)
>>>>-----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
>>>>>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
>>>>>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:

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

View raw message