Slashdot Mirror


Advantages Of .NET Over Java

ansonyumo writes "ZDNet is carrying an article written by one John Carroll that outlines specific advantages of .NET over Java. It's written from the point of view of a Java advocate who has 'seen the light.' First of all, comparing .NET and Java isn't very fair; you have to compare .NET and J2EE. When you level the playing field, most of his arguments readily fall apart."

3 of 125 comments (clear)

  1. -1 Sig Comment by pyrrho · · Score: 0, Offtopic

    Stupidity may be self-curing, unfortunately, it reproduces prior to the cure.

    --

    -pyrrho

  2. SUN Internal memo: The Java Problem by schouwl · · Score: 1, Offtopic

    Hi,

    Even Sun admits that Java has a problem using to many resources for small tasks.
    I don't know if that is better than .NET ;)

    The Java Problem
    Author: Julian S. Taylor
    Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter Madany, Michael Boucher

    Executive Summary

    While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.

    Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF.

    Introduction

    This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
    We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
    Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++. Key examples include:

    4246106 Large virtual memory consumption of JVM
    4374713 Anonymous inner classes have incompatible serialization
    4380663 Multiple bottlenecks in the JVM
    4407856 RMI secure transport provider doesn't timeout SSL sessions
    4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
    4460382 For Jdk1.4, the table editors for JTable do not work.
    4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
    4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
    4475676 [under jdk1.3.1, new JFrame launch causes jumping]

    In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.

    Defining the Java Problem

    These are the problems we have observed which we believe indicate the need for an improved implementation and a modified approach.

    1. The support model seems flawed
    Since Java is not a self-contained binary, every Java program depends fundamentally upon the installed Java Runtime Environment (JRE). If that JRE is broken, correction and relief is required. This sort of relief needs to happen in a timely manner and needs to fix only the problem without the likelihood of introducing additional bugs. Java Software does not provide such relief.
    Java packages are released (re-released) every four or five months, introducing bug fixes and new features and new bugs with each release. These releases are upgrading packages which remove all trace

  3. Re:C#/.Net vs. Java/Java by mike_sucks · · Score: 0, Offtopic

    Do you often talk to yourself? It sounds like you're having a really, really good conversation.

    --
    -- "So, what's the deal with Auntie Gerschwitz et all?"