|
|
| Article: |
Best Practices for Building Production Quality EAR Files
|
| Subject: |
Very true and thats whats so wrong |
| Date: |
2008-04-23 11:51:46 |
| From: |
ryanyoder |
|
Response to: Very true and thats whats so wrong
|
|
You haven't heard of them because they don't exist :) I'm no expert in classloading but afaik the java classloader and run-time type identification is built on weak references such as package name, class name plus (as of Java 1.2 I believe) classloader.
With DotNet and COM you have the ability to sign your assemblies (dlls) and strong name them. When you reference a dll that is strong named you can only run against that dll. You can also chooose to load certain assemblies with version numbers that are not signed if you don't want to go that far.
When deploying a dotnet application onto someone elses IIS instance you rarely run into a classcast exception because something you hadn't expected is being loaded instead of your class. It just doesn't happen.
Java needs to have a way to sign a jar and to reference a signed version of a jar explicitly or automatically when compiled against a signed jar. That would really make things easier. If I compile against saaj.jar 1.xyz then I shouldn't be handed classes from saaj.jar 1.25 or just because the Weblogic instance has that jar file or even worse because it packages saaj.jar classes inside the 32mb weblogic.jar file. |
|
