Well this is getting pretty tedious, however bear with me while I try to sort out the remaining 25 reasons in the list. Its interesting that there's now some defeaning silence from the .NET community. After attacking the list calling it "pathetic", "irrelevant" and "intellectual curiosity but not practical" it now looks like they've stopped commenting after it passed 25 reasons.

If you are finding this list a little too long to handle, I would offer you another list worth looking at. John Munsch blogs a list "Lots of reasons I want .NET to fail and fail badly". I wasn't really aware of a lot of things he wrote about, however #6 hits home for me:

It's a really sad way for a lot of people to waste a whole lot of time rebuilding that which already exists. Wouldn't the whole computing world be a lot better if there wasn't a team of people, maybe a couple of teams of people building complete copies of .NET for other platforms? If those same people were working on giving us new libraries and new tools for an already existing language instead of pouring in the thousands of man hours it's going to take to build a copy of the C# compiler or a .NET version of Ant and JUnit?

The real strength in Java is the richness in its libraries, there's just so much that can be leveraged and reused. One good side effect of this list is that it does point out to people what's out there and available today. When people compare Java with .NET they usually just compare it at the suface level. Done this way it tends to look the same, that's because .NET is pretty shallow and if you go any deeper, well then you see its flaws revealed, revealed in 101 little ways.

As a software architect, I pride myself in finding solutions to problems in the most effective way. So when people try to be agnostic by saying "use the best tool for the job", all I can truly say most often Java is the best tool for the job, simply because the tools and libaries already exist. If reinventing the wheel gives you thrills, well good for you, however don't do it while I'm the architect.

71. Better Best Practices Blueprint Application

Microsoft was recently criticized by members of the .Net community for writing "Anti-Patterns" instead of adopting best practices. Meanwhile, Java vendors spend a lot of time on educating new programmers in best practices (see this site as an example).

72. Business Rule Engine Support

Rule-based systems are designed to encode business rules explicitly and in a declarative manner. The better manageability of business rules leads to a more agile business. Java has comprehensive support for Rule-based systems through vendors like ILOG, Blaze and ATG. Furthermore, there are open source Rule-based systems written in Java, in particular you have JESS, Drools and JEOPS.

73. Run on 64-bit Platforms

Java runs 64-bit platforms today, specifically on AIX, HPUX, Sun and Linux (Itanium). .NET by contrast doesn't even run on the Itanium based Windows Server. Expect to see Java ported first to AMD's 64bit Opteron processors [see].

74. Millions of Java Enabled Cell Phones Today

There are 75 million java enabled phones today by contrast anyone will be hard pressed to find a wireless phone that runs .NET compact framework (There's probably one, but I heard it has virus problems!).

There are no more than "10 mobile carriers around the world deployed Java technology enabled devices with approximately 75 million handsets worldwide running on the Java platform. In addition, there are over 80 different handset models from 19 manufacturers worldwide using the J2ME platform." [ Numbers as of September, see source http://www.sun.com/smi/Press/sunflash/2002-09/sunflash.20020924.2.html ] . Microsoft recently suffered a big setback when one of the few implementers of Microsoft wireless smart phone solution abandoned the the Microsoft solution for Nokia/Symbian/Java. Java has rapidly become a standard part of wireless devices.

75. Garbage Collect Classes

Java classes can are garbage collected, this is controlled by allowing the ClassLoader to be garbage collected. This is a technique used for building dynamic systems.

By contrast, generated MSIL cannot be unloaded. The only way to unload code is to unload an entire application domain (that is, to unload all of your application's code.) [see].

Furthermore, there's no way to add dynamic scripting to an application without the ability to unload a dynamically created assembly. Loading the assembly into another AppDomain causes severe speed issues, great difficulting with respect to marshalling and memory leaks. [see]