Why I prefer .NET instead of Java
4/10/2007
This is a question I have been asked many times. I decided to finally write my thoughts down.
I am sure that no matter how I phrase this, since I am a Microsoft Regional Director as well as a Microsoft MVP it will be construed by some as Java bashing. And while in many of my sessions Java is the butt of many good humored jokes, it is all in jest. My primary audience are .NET developers, and it is the natural rival. When I spoke primarily to Delphi users, Visual Basic was the target of my jokes.
Believe it or not I respect Java as a platform. Before .NET was released, several times I ventured into the Java space. I do not believe Java to be trash, or that those who choose to use Java are poor developers. However I have several technical reasons why I prefer .NET and I will list them here. It is not a document describing which is better, that is a decision best decided based on needs and the uniqueness of each situation.
Comparing Frameworks
I will not discuss the frameworks included with each platform or available separately. That is JDK, J2EE, BCL, FCL, etc. Each has its own strengths over the other. While frameworks are very important, the frameworks are based on the core platform.
No Language Choice
In .NET there is a Common Language Specification (CLS). This allows many languages to exist and for .NET to be language neutral. While C# and VB.NET account for the majority of developers there are significant amounts of developers using Delphi, PHP, and other .NET based languages. When choosing Java as a platform, Java is the only language available. I am aware that some other languages have been made to emit Java byte code, however because Java was never designed for this significant restrictions apply. Because of this, none of these languages has garnered any significant following and nearly all Java development is done using Java as the language.
Java lacks a CLS, or one might say the CLS is the Java language. Because of this, any language that runs on the JDK must either be very Java like, or a second class citizen. And any language that is Java like, offers little reason for the developer not to use the Java language.
Backwards Compatibility
.NET and Java have different approaches when adding new functionality that requires changes to existing API's. .NET maintains runtime compatibility through versioning (and so does Java). However Java also keeps source compatibility between versions. This allows code designed for JDK 1.0 to compile against JDK 5.0, however as each new version of Java is released more and more baggage accumulates. There are some API's that have grown to dozens of methods with identical functionality, most of which are deprecated but must continue to be supported. .NET on the other hand documents required changes and if the source code is to be moved must be updated to be compiled against newer versions. While this has impact on source code, such changes are kept to a minimum as it does have impact on developers, but it also keeps each release cleaner and free of accumulated baggage. Older code even if not updated (when necessary) can be run under the older version of .NET, while still accessed from code running in the newer version through interoperation in most cases.User Interface
This is probably the one I will catch the most flak for, and I am sure Java advocates left and right will send me isolated unique examples. There certainly are some good user interfaces written in Java. However it continues to be the rule that most Java applications have user interfaces that "stick out" from other applications and are not well implemented. 9 times out of 10 I can identify a Java application by its lackluster user interface within seconds of using it. This is also one reason Java has been successful in server environments, yet not as widely used in desktop applications.
Slowness
I am not here to say Java is slow. I have studied how the just in time compiler in .NET works, as well has how the JVM and hot spot technologies work. And certainly cases of .NET slowness as well as Java slowness are not difficult to find examples for. However taken as a whole while looking at desktop applications, in general Java desktop applications are noticeably slow. Maybe it is the UI layer, or a requirement of many JNI calls. I do not know, I do not believe it to be a core JVM issue. But the simple fact remains again as with the UI, 9 out of 10 Java desktop applications even on my dual core 3.6 GHz machine execute much slower than comparable native or even .NET desktop applications. I have not noticed this slowness in server applications, where Java is predominantly used anyways. However this brings me to the point that Java in my experience is inferior for desktop applications, which are important to me and many developers.Original Design
I think this is one of the biggest crutches of Java, but it is made worse by the method of maintaining near absolute backwards compatibility. Java was originally designed for embedded type devices. It failed to succeed for what it was designed for. However it saw a short lived success for browser applets, because while not designed for it, Java was the closest and best solution in an emerging market. Later the same phenomenon occurred when Java succeeded and continues to thrive in the server space. However these two hops have left it fairly disconnected from its original design goals. Java has certainly evolved to better address what it is being used for, however many of its original design goals restrict it from evolving in ways that would improve it further without breaking code and becoming something other than Java..NET Designed Later
.NET also had an advantage of time. .NET is not a clone of Java, and those who think it is either do not know one of the two very well. Those who say it is, should also be aware that Java is not the first managed code platform. .NET was designed on its own, however it is obvious that the designers studied Java's weak spots and designed .NET differently so as not to have the same issues. Many of these issues only became apparent after many years of use, as well as seeing how computing evolved in those years and seeing the more recent computing trends and needs. This was only possible becuase .NET was designed several years after Java. Thus Java served as a case study of sorts.Notable .NET Shortcomings
To be fair, .NET has shortcomings as well. The most predominant is the lack of cross platform support. For many however, this is not an issue. And for those that cross platform is important there are projects like Mono and DotGNU. Both are making excellent progress and very usable in many scenarios. I believe in the coming years we will see more cross platform offerings for .NET that will minimize and possibly eliminate this issue. The vital parts of .NET have all been submitted and accepted by ECMA as a standard. Anyone is free to implement .NET on other platforms as Mono has. Today IBM is mostly about services and hardware. While they are big into Java, .NET is getting to big too ignore and I predict that eventually we will see IBM in conjunction with Microsoft port .NET to the mainframe and other high end systems. In fact it is already possible using on of Mono's variants to run .NET on the mainframe using their JVM based .NET implementation.
Microsoft has even released ROTOR for educational purposes, a fully functional .NET implementation that was used for prototyping as well as ECMA standardization. ROTOR is freely available and runs on Windows, Mac OSX, and BSD.
<< Previous Entry Next Entry >>
Use my contact form to contact me directly.
