61. Public API's are Public Domain

Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers.

.NET doesn't have an equivalent guarrantee.

62.More Garbage Collections Options

Generational Stop 'n Copy

Single Spaced Concurrent

Generational Concurrent

Parallel

Concurrent Mark and Sweep

Incremental

Generational

63. More Languages for the VM

There are more languages written for the Java VM than the .NET CLR. See Languages of the Java VM (http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html) for a listing. A piece "One Runtime to Bind Them All" (http://www.javalobby.org/clr.html) exposes the myth of .NET's common language support. Meanwhile, the number of new languages for .NET have remained stagnant since its release a year ago, in fact the only new language since then was J#.

64. Better Exception Handling

There is no analog to the throws clause in method signatures. One major side effect of this is that unless the creator of the API explicitly documents the exceptions thrown then it is not possible for the users of the API to know what exceptions to handle. Thus users of C# are reliant on the documentation skill of programmers as their primary error handling mechanism which is a less than optimal situation.

.NET also does not have Checked Exceptions, the use the Compiler to flag any unhandled exception. This is an additional mechanism that developers can use to improve the robustness of their programs.

65 Better SOAP Interoperability

Recent results from http://www.soapbuilders.org/ interoperability lab indicate lingering problems with SOAP interoperability. Several java companies Cape Clear, Systinet and TheMindElectric have made extensive effort to make their products interoperate with a large set of SOAP products. Thus with Java there is a greater likelihood of acheiving SOAP interoperability than Microsoft. In fact, Microsoft has several SOAP toolkits that astonishingly enough aren't 100% interoperable!