Back after a long break. Hopefully I will be able to finish off this list without any further breaks...:-)
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.
I am not sure that this is something that is gonna change the world. It is generally accepted that to get a new API spec approved takes atleast an year or so, by which time that spec is already out of date.:-)
62.More Garbage Collections Options Generational Stop 'n Copy Single Spaced Concurrent Generational Concurrent Parallel Concurrent Mark and Sweep Incremental Generational
Ok so how many people change thier Garbage collectors daily. Atleast how many people want to change it. A minority few I am sure.
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#.
Well there has been enough debate on real life languages aimed at the JVM. The concenses has been except for 1 or 2 most of the languages listed in the mentioned page are either hobbiest projects are already out of action. JVM was never designed to host multiple languages. This reason seems to be the best joke of all.
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.
I am not sure about what Checked Exceptions are to comment on this, but I know that the tagging to exceptions thrown by a method is a debated topic even within the Java community
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!
Well Sun has only recently entered WS-I. So much for SOAP interoperability with Java....
from Microsoft internal news...
IBM is going to incorporate CLR in thier next version of DB2.
Good news ! Ah.
Posted by: Sudhakar | October 28, 2003 at 04:58 AM
http://conntact.com/bol/buytramadol/#16 buy tramadol c.o.d saturday delivery - order tramadol with saturday delivery
Posted by: rwgRDNowXW | May 16, 2013 at 04:25 PM