commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lambrou <>
Subject Re: AW: [proposal] avoiding jar version nightmares
Date Fri, 17 Dec 2004 23:16:42 GMT

> Correct me if I'm wrong, but didn't Microsoft come up with some type 
> of solution to DLL hell in Windows 2000 or XP?  I seem to recall 
> reading that a long time ago, but I'm not a Windows programmer, so I 
> have no idea.  Does anyone else know?

The .NET equivalent of a jar file is called an assembly. For libraries, 
this is basically a DLL. Every time the code is compiled, the DLL is 
automatically allocated a unique version number. When you compile your 
code that refers to code in a library assembly, your assembly has an 
explicit dependency on that library assembly. At runtime, when your code 
tries to invoke the library code, an exception will be raised if the 
exact version of the library assembly is not available.

It would appear that if there are bug fixes or other improvements to the 
library, and a recompiled assembly DLL is substituted for the one you 
originally compiled against, then your code will break. At runtime, your 
code will fail to link to the library code, since the version number no 
longer matches. Obviously, a maintenance release of a library component 
shouldn't require a recompilation and redeployment of all software that 
uses the library, so .NET provides a mechanism for you to explicitly 
define a version number. This allows you to provide updated library 
components to users without requiring them to recompile. However, this 
only works if you don't break backwards compatibility.

If you break backwards compatibility in a library, then you have to 
change the version number. However, .NET still allows you to deploy 
different, incompatible versions of the same DLL. When you deploy the 
application, your installer has to register both versions of the DLL 
with the GAC - the Global Assembly Cache. In this way, if you have a 
complex application that contains two components that rely on 
incompatible versions of the same library DLL, the VM instantiates two 
separate versions of the library DLL, and links the two components to 
the appropriate instance.

One possible Java analogy to this would be to bundle all code inside jar 
archives. Each jar contains dependency information, perhaps stored in 
the manifest, or some other meta-file, that describes the jar's own name 
and version number, and a list of the names and version numbers of its 
dependencies. A suitable class loader can then use this meta information 
to stitch the classes together appropriately. Actually, my knowledge of 
java class loaders isn't  sufficient for me to assert that this solution 
would definitely work, but it's a start, and I hope all of this serves 
to illustrate how .NET allows multiple versions of the same library to 


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

View raw message