Jeff Dillon

     
 
« Jonathan Schwartz at... | Main | I had to Dump Eclips... »

24 Jun · Thu 2004

Where .NET Shines
Aside from the fact that large parts of .NET are a straight rip-off of Java and that Enterprise Java is years ahead of .NET, there is one thing that .NET addresses that Java never touched. I really like the .NET Globally Assembly Cache (GAC). Java always left JAR management and dealing with shared JARS almost completely up to the developer. It is up to the developer to generate a globally unique name, it is up to the developer to deal with versioning issues, and it is up to the developer to set the classpath. There is very little support for dealing with the problems that arise from shared JARs. Often times I wonder how many copies of XML libraries or Reg Exp libraries are on a system that has many (pre-1.4) Java products installed. Many people are using private copies of everything including the JVM itself. This works fine until people realize that they have to start sharing with other products in the same company or across companies. Everyone ends up implementing the same types of custom solutions. Why do Sys Admins not deal with JARs like they would shared libraries? In the Java world, we often wrap JARs into RPMs and PKGs and then pretend that its not Java. Microsoft's .NET is able to treat assemblies as first class objects to the operating system using the GAC.

Java somewhat addressed this problem with the extensions directory where users can place JRE extension JARS, but this is rather primitive. Perhaps this is more difficult for Java because it can not integrate with the OS as closely as .NET can, but I am not sure that is the only reason. Since Java really took off in the enterprise App Server space, many people were ok with dealing with these issues in their application. (Namely, the app server). But, the fact that small ISVs have to implement a custom solution or just not share at all stinks. I really don't see any reason why something like the GAC could not be implemented for Java.

.NET's Globally Assembly Cache has some pretty nice features for addressing sharing problems in a common way.
@ 10:20 AM PDT
 
 
 
 
Comments:

I agree with you on this issue. Currently I've about 2 JUnit, 4 Ant, and tons of different versions of XML and DOM libraries in my system. Let alone 3 JVMs (one is 1.4.1 for compile OO.o .. even 'Sun' product cannot keep backward compatibiliy with each other -_-"). I know that for some of them I can manually configure the config file to point dir to a shared one. That's quite practical for a small number of packages, but may be not for a larger number. I like to see some service for Java .. a registry? .. that each library can sign up and say "Hey! I'm XML parser, from X vendor, version Y, and I can do this this this and this, and this is my interfaces.". Later on if there's any application like to use an XML functionality, it just look around the registry. Admin may able to set a 'default' lib, so those application that just ask for service and not specify the 'vendor' name of service will got a default one. The package installer/deployer will working together with this registry to see if any of packages to be installed is already there in the registry -- if it is there, not install duplicate, just use the existing (of course, in case that version/vendor constraint met). This not only save space, but also reduce admin headache. Shared lib/piece of code in new architecture of JVM (as i've heard of) also reduce memory footprint. Please correct me if there's already a Java solution for this :)

Posted by bact' on June 24, 2004 at 10:56 AM PDT #

I only found this yesterday by accident, so I haven't read it yet. Have a look at this paper: http://www.google.com/search?q=mj%20rational%20module

Posted by fghdghsfgh on June 26, 2004 at 06:36 PM PDT #

Hi, I fully agree with you. A GAC for java would be great. Actually once upon a time I was starting to implement something like a GAC for java. The project got stalled, partly because of lack of time and partly because there are already solutions to this problem that are good enough for my purposes. If you base your application for example on the eclipse plugin framework, you get most of the problems with jar files solved. I'm not sure whether Eclipse already allows sharing of plugins between different applications, but this features is IMHO not always important. Regards, Markus

Posted by nil on July 01, 2004 at 01:38 AM PDT #

Post a Comment:

Comments are closed for this entry.
 
« December 2009
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today

[RSS Newsfeed]

 
© Jeff Dillon