Comparison of Java and C Sharp

From Wikipedia, the free encyclopedia

This is a comparison of the C# programming language with the Java programming language. As the two are both garbage-collected runtime-compiled languages with syntax derived from C and C++, there are many similarities between Java and C#. However, there are many differences also, with C# being described as a hybrid of C++ and Java, with additional new features and changes. This page documents the strong general similarities of the languages and then points out those instances where the languages differ.

[edit] Language

[edit] Object handling

Both C# and Java are designed from the ground up as VMT-based object oriented languages, with a syntax similar to C++. (C++ in turn is derived from C.) Neither language is a superset of C or C++, however. Both use garbage collection as a means of reclaiming memory resources, rather than explicit deallocation of memory. Both include thread synchronization mechanisms as part of their language syntax.

Both Java and C# have strong and weak object references. Java allows registering a listener that will be notified when a reference is garbage collected, which allows for the good performance of the WeakHashMap that C# lacks. C# only supports this by using a finalizer (which is also available in Java). C# on the other hand allows the programmer to suppress the finalizer of a specific object (e.g., an SQL connection or a file stream that always needs to be properly closed). This can be very useful since finalizers are expensive in generational garbage collection (applied by both Java and .NET), and are often used only as a fail-safe for when the programmer does not close the object. An object with a finalizer will normally be promoted to an extra generation and kept alive longer before it is collected.

Java allows soft references, as well as weak references. A softly referenced object is only garbage collected when all strong references are gone and the virtual machine's memory is low. This gives Java applications a simple way to cache objects in memory that would otherwise be expensive to reconstruct later. Weak references are not suitable for caching such objects in memory, since the virtual machine is liable to garbage collect them soon after the strong references are gone.

C# allows restricted use of pointers, which are considered unsafe by some language designers^[who?]. C# addresses that concern by requiring that code blocks or methods that use the feature be marked with the unsafe keyword, so that all clients of such code can be aware that the code may be less secure than otherwise. The compiler requires the /unsafe switch to allow compilation of a program that uses such code. Generally, unsafe code is either used to allow better interoperability with unmanaged APIs or system calls (which are inherently "unsafe"), or for performance reasons.

[edit] Data types

Both languages support the idea of primitive types (all of which, except for string, are value types in C#/.NET). C# has more primitive types than Java, with unsigned as well as signed integer types being supported, and a special decimal type for decimal fixed-point calculations. Java lacks unsigned types. In particular, Java lacks a primitive type for an unsigned byte. Strings are treated as (immutable) objects in both languages, but support for string literals provides a specialized means of constructing them. C# also allows verbatim strings for quotation without escape sequences, which also allow newlines.

Both allow automatic boxing and unboxing to translate primitive data to and from their object form. Effectively, this makes the primitive types a subtype of the Object type. In C# this also means that primitive types can define methods, such as an override of Object's ToString() method. In Java, separate primitive wrapper classes provide such functionality, which means it requires a static call Integer.toString(42) instead of an instance call 42.ToString(). Another difference is that Java makes heavy use of boxed types in generics (see below), and as such allows an implicit unboxing conversion (in C# this requires a cast). This conversion can potentially throw a null pointer exception, which may not be obvious by code review in Java.

C# allows the programmer to create user-defined value types, using the struct keyword. From the programmer's perspective, they can be seen as lightweight classes. Unlike regular classes, and like the standard primitives, such value types are allocated on the stack rather than on the heap. They can also be part of an object (either as a field or boxed), or stored in an array, without the memory indirection that normally exists for class types. Structs also come with a number of limitations. Because structs have no notion of a null value and can be used in arrays without initialization, they always come with an implicit default constructor that essentially fills the struct memory space with zeroes. The programmer can only define additional constructors with one or more arguments. This also means that structs lack a virtual method table, and because of that (and the fixed memory footprint), they cannot allow inheritance (but can implement interfaces).

[edit] Enumerations

Enumerations in C# are derived from a primitive 8, 16, 32, or 64 bit integer type. Any value of the underlying primitive type is a valid value of the enumeration type, though an explicit cast may be needed to assign it. Enumeration values in Java, on the other hand, are objects. The only valid values in a Java enumeration are the ones listed in the enumeration. As objects, each enumeration can contain its own fields which can be modified. Special enumeration set and map collections provide fully type-safe functionality with minimal overhead. Java enumerations allow differing method implementations for each value in the enumeration. Both C# and Java enumerations can be converted to strings and can be used in a switch statement.

[edit] Arrays

Array and collection types are also given significance in the syntax of both languages, thanks to an iterator-based foreach statement loop. In both languages an array corresponds to an object of the Array class, although in Java this class does not implement any of the collection interfaces. C# has true multidimensional arrays, as well as the arrays-of-arrays that are available in Java (and which in C# are commonly called jagged arrays). Multidimensional arrays can in some cases increase performance because of increased locality (as there is a single pointer dereference, instead of one for every dimension of the array as is the case for jagged arrays). Another advantage is that the entire multidimensional array can be allocated with a single application of operator new, while jagged arrays require loops and allocations for every dimensions. Note, though, that Java provides a syntactic construct for allocating a multidimensional jagged array with regular lengths (a rectangular array in the C# terminology); the loops and multiple allocations are then performed by the virtual machine and need not be explicit at the source level.

[edit] Inner classes

Both languages allow inner classes, where a class is defined entirely within another class. In Java, these classes have access to both the static and non-static members of the outer class (unless the inner class is declared static, then it only has access to the static members). Local classes can be defined within a method and have access to the method's local variables declared final, and anonymous local classes allow the creation of class instances that override some of their class methods.

C# also provides inner classes, and requires an explicit reference to the outer class to its non-static members. Also, C# provides anonymous delegates as a construct that can provide access to local variables and members (see Event handling).

[edit] Generics

Further information: Generic programming

Both languages now support generics programming, but they have taken different paths to its implementation.

Generics in Java are a language-only construction; they are implemented only in the compiler. The generated classfiles include generic signatures only in the form of metadata (allowing the compiler to compile new classes against them). The runtime has no knowledge of the generic type system, which meant that JVM implementations only needed minimal updates to handle the new class format.

To achieve this goal the compiler replaces all generic types by their upper bounds and inserts casts appropriately in the various places where the type is used. The resulting byte code will contain no references to any generic types or parameters. This technique of implementing generics is known as type erasure. This means that runtime information about the actual types is not available at runtime, and imposes some restrictions such as the inability to create new instances or arrays of generic type arguments. (See also Generics in Java.)

C# took a different route. Support for genericity was integrated into the virtual execution system itself and first appeared in .NET 2.0. The language then becomes merely a front-end for the underlying generics support in the execution system. As in Java, the compiler provides static type safety checking, but additionally the JIT performs load time verification of the correctness. Information on generic types is fully preserved at runtime, and allows complete reflection support as well as instantiation of generic types.

Java's approach requires additional run time type checks, it does not guarantee that generic contract will be followed, and lacks reflection on the generic types. Java does not allow to specialize generic classes with primitive types, while C# allows generics for both reference types and value types, including primitive types. Java instead allows the use of boxed types as type parameters (e.g., List<Integer> instead of List<int>), but this comes at a cost since all such values need to be heap-allocated. In both Java and C#, generic specializations that use different reference types share equivalent underlying code,^[1] but for C# the Common Language Runtime (CLR) dynamically generates optimized code for specializations on value types.

[edit] Notation and special features

[edit] Special feature keywords

// Create a small file "test.txt", write a string, and close it (even if an exception occurs)
using (StreamWriter file = new StreamWriter("test.txt"))
{
    file.Write("test");
}

switch(color)
{
    case Color.Blue: Console.WriteLine("Color is blue"); break;
    case Color.DarkBlue: Console.WriteLine("Color is dark"); goto case Color.Blue;
    // ...
}

public static IEnumerable<int> GetEven(IEnumerable<int> numbers)
{
    foreach (int i in numbers)
    {
        if (i % 2 == 0)
            yield return i;
    }
}

[edit] Event handling

Java requires the programmer to implement the observer pattern manually, though it provides some syntactic sugar in form of anonymous inner classes, which allow one to define the body of the class and create an instance of it in a single point in the code. This is typically used to create observers.

C# provides support for event-driven programming at the language level, including delegate types. These are type-safe references to methods and can be combined to allow multicasting. To support them there is a special syntax to define events in classes and operators to register, unregister or combine event handlers. Delegates support covariance and contravariance, and can be created as anonymous methods with full-featured closure semantics.

Closures have also been proposed as a new feature for Java SE 7.^[2] Like delegates in C#, such closures would have full access to all local variables in scope, not just read-only access to those marked final (as with anonymous inner classes).

[edit] Numeric applications

To adequately support applications in the field of mathematic and financial computation, several language features exist.^[3] In this category, Java provides the strictfp keyword, that enables strict floating-point calculations for a region of code. This will ensure that calculations return the exact same result on all platforms. C# provides no equivalent, but does provide the built-in decimal type, for accurate decimal floating-point calculations. This forgoes the problems that exist with binary floating-point representations (float, double). Such binary representations are not suited to accurately represent decimal numbers and hence introduce rounding errors. For financial applications, an accurate decimal type is essential. Since Java 5.0, the BigDecimal class also provides such characteristics for Java.^[4] BigDecimal and BigInteger are types provided with Java that allow arbitrary-precision representation of numbers. The current release of the .NET framework (3.5) does not currently include such classes, although third party implementations exist.

In Java there is no way to provide the same level of integration for library-defined types such as BigDecimal or complex numbers as there is for the primitive types. For this purpose, C# provides the following:

• Operator overloading and indexers providing convenient syntax (see below).
• Implicit and explicit conversions; allow conversions such as exist for the built-in int type that can implicitly convert to long.
• Valuetypes and generics based on valuetypes; in Java every custom type must be allocated on the heap, which is detrimental for performance of both custom types and collections.

In addition to this, C# can help mathematic applications with the checked and unchecked operators that allow to enable or disable run-time checking for arithmetic overflow for a region of code. It also offers rectangular arrays, that have advantages over regular nested arrays for certain applications.^[3]

[edit] Operator overloading

C# includes a large number of notational conveniences over Java, many of which, such as operator overloading and user-defined casts, are already familiar to the large community of C++ programmers. It also has "Explicit Member Implementation" which allows a class to specifically implement methods of an interface, separate to its own class methods, or to provide different implementations for two methods with the same name and signature inherited from two base interfaces.

C# includes indexers which can be considered a special case of operator overloading (like C++ operator[]), or parametrized get/set properties. An indexer is a property named this[] which uses one or more parameters (indexes); the indexes can be objects of any type:

myList[4] = 5;
string name = xmlNode.Attributes["name"];
orders = customerMap[theCustomer];

Java does not include operator overloading in order to prevent abuse of the feature, and to keep the language simpler.^[5] C# allows operator overloading (subject to certain restrictions to ensure logical coherence), which, when used carefully, can make code succinct and more readable.

[edit] Methods

Methods in C# are non-virtual by default, and have to be declared virtual explicitly if desired. In Java, all non-static non-private methods are virtual. Virtualness guarantees that the most recent override for the method will always be called, but incurs a certain runtime cost on invocation as these invocations cannot be normally inlined, and require an indirect call via the virtual method table. However, some JVM implementations, including the Sun reference implementation, implement inlining of the most commonly called virtual methods.

In Java there is no way to make methods non-virtual (although they can be "sealed" by using the final modifier to disallow overriding). This means that there is no way to let derived classes define a new, unrelated method with the same name. This can be a problem when a base class is designed by a different person, and a new version introduces a method with the same name and signature as some method already present in the derived class. In Java, this will mean that the method in the derived class will implicitly override the method in the base class, even though that was not the intent of the designers of either class. To prevent this versioning problem, C# requires explicit declaration of intent when overriding virtual methods in a derived class. If a method should be overridden, the override modifier must be specified. If overriding is not desired, and the class designer merely wishes to introduce a new method shadowing the old one, the new keyword must be specified. The new and override keywords also avoid the problem which can arise from a base class being extended with a protected/public method whose signature is already in use by a derived class. In Java a recompilation will lead the compiler to regard the method of the derived class as an override of the method of the base class, which was probably not the intent of the base class developer. The C# compiler will regard the method as if new had been specified, but will issue a warning to that effect.

To partially accommodate for these versioning problems, Java 5.0 introduced the @Override annotation, but to preserve backwards compatibility it could not be made compulsory, so it cannot prevent the above accidental overriding situation. Like the override keyword in C#, it can however help ensure that a method in the base class with the same signature exists and is correctly overridden.

[edit] Conditional compilation

Unlike Java, C# implements conditional compilation using preprocessor directives. It also provides a Conditional attribute to define methods that are only called when a given compilation constant is defined. This way, assertions can be provided as a framework feature with the method Debug.Assert(), which is only evaluated when the DEBUG constant is defined. Since version 1.4, Java provides a language feature for assertions, which are turned off at runtime by default but can be enabled using the "-enableassertions" or "-ea" switch when invoking the JVM.

[edit] Namespaces and source files

C#'s namespaces are similar to those in C++. Unlike package names in Java, a namespace is not in any way tied to location of the source file. While it's not strictly necessary for a Java source file location to mirror its package directory structure, it is the conventional organisation.

Both languages allow importing of classes (e.g., import java.util.* in Java), allowing a class to be referenced using only its name. Sometimes classes with the same name exist in multiple namespaces or packages. Such classes can be referenced by using fully qualified names, or by importing only selected classes with different names. To do this, Java allows importing a single class (e.g., import java.util.List). C# allows importing classes under a new local name using the following syntax: using Console = System.Console. It also allows importing specializations of classes in the form of using IntList = System.Collections.Generic.List<int>.

Java has a static import syntax that allows using the short name of some or all of the static methods/fields in a class (e.g., allowing foo(bar) where foo() can be statically imported from another class). C# has a static class syntax (not to be confused with static inner classes in Java), which restricts a class to only contain static methods. C# 3.0 introduces extension methods to allow users to statically add a method to a type (e.g., allowing foo.bar() where bar() can be an imported extension method working on the type of foo).

The Sun Microsystems Java compiler requires that a source file name must match the only public class inside it, while C# allows multiple public classes in the same file, and puts no restrictions on the file name. As of Version 2, C# allows a class definition to be split into several files, by using the partial keyword in the source code.

[edit] Exception handling

The neutrality of this section is disputed. Please see the discussion on the talk page.(February 2008) Please do not remove this message until the dispute is resolved.

Java supports checked exceptions (in addition to unchecked exceptions). C# only supports unchecked exceptions. Checked exceptions enforce the programmer to declare all exceptions thrown in a method, and to catch all exceptions thrown by a method invocation.

Some would argue^[who?] that checked exceptions are very helpful for good programming practice, ensuring that all errors are dealt with. Others, including Anders Hejlsberg, chief C# language architect, argue that they were to some extent an experiment in Java and that they haven't been shown to be worthwhile except for in small example programs.^[6][7]

One criticism is that checked exceptions encourage programmers to use an empty catch block, which silently eats exceptions rather than letting the exceptions propagate to a higher-level exception-handling routine: catch (Exception e) {}. Another criticism of checked exceptions is that a new implementation of a method may cause unanticipated checked exceptions to be thrown, which is a contract-breaking change. This can happen in methods implementing an interface that only declares limited exceptions, or when the underlying implementation of a method changes. To allow for such unanticipated exceptions to be thrown, some programmers simply declare the method can throw any type of exception ("throws Exception"), which defeats the purpose of checked exceptions. In some cases however, exception chaining can be applied instead; re-throwing the exception in a wrapper exception. For example, if an object is changed to access a database instead of a file, an SQLException could be caught and re-thrown as an IOException, since the caller may not need to know the inner workings of the object.

There are also differences between the two languages in treating the try-finally statement. The finally is always executed, even if the try block contains control-passing statements like throw or return. In Java, this may result in unexpected behavior if the try block is left by a return statement with some value, and then the finally block that is executed afterwards is also left by a return statement with a different value. C# resolves this problem by prohibiting any control-passing statements like return or break in the finally block.

A common reason for using try-finally blocks is to guard resource managing code, so that precious resources are guaranteed to be released in the finally block. C# features the using statement as a syntactic shorthand for this common scenario, in which the Dispose() method of the object of the using is always called.

[edit] Lower level code

The Java Native Interface (JNI) feature allows Java programs to call non-Java code. However, JNI does require the code to be called to follow several conventions and impose restrictions on types and names used. This means that an extra adaption layer between legacy code and Java is often needed. This adaption code must be coded in a non-Java language, often C or C++.

In addition, third party libraries provide for Java-COM bridging, e.g. JACOB (free), and J-Integra for COM (proprietary).

.NET Platform Invoke (P/Invoke) offers the same capability by allowing calls from C# to what Microsoft refers to as unmanaged code. Through metadata attributes the programmer can control exactly how the parameters and results are marshalled, thus avoiding the need for extra adaption code. P/Invoke allows almost complete access to procedural APIs (such as Win32 or POSIX), but no direct access to C++ class libraries.

In addition, .NET Framework also provides a .NET-COM bridge, allowing access to COM components as if they were native .NET objects.

C# also allows the programmer to disable the normal type-checking and other safety features of the CLR, which then enables the use of pointer variables. When this feature is used, the programmer must mark the code using the unsafe keyword. JNI, P/Invoke, and "unsafe" code are equally risky features, exposing possible security holes and application instability. An advantage of unsafe, managed code over P/Invoke or JNI is that it allows the programmer to continue to work in the familiar C# environment to accomplish some tasks that otherwise would require calling out to unmanaged code. A program or assembly using unsafe code must be compiled with a special switch and will be marked as such. This enables runtime environments to take special precautions before executing potentially harmful code.

[edit] Language history and evolution

[edit] Java

This article or section may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (December 2007)

Java is older than C# and has built up a large and highly active user base, becoming the lingua franca in many modern branches of computer science, particularly areas which involve networking.^{[citation needed]} Java dominates programming courses at high school and college level in the United States, and there are currently more Java than C# books.^[8] Java's maturity and popularity have ensured more third party Java API and libraries (many of them open source) than C#.

An occasionally voiced criticism^[who?] of the Java language is that it evolves slowly, lacking some features which make fashionable programming patterns and methodologies easier.^{[citation needed]} Others^[who?] point to C# and say that its designers are perhaps too quick to pander to current trends in programming - lacking focus and simplicity.^{[citation needed]} Java's designers seem^{[original research?]} to have taken a more conservative stand on adding major new features to their language syntax than other current languages, perhaps^[who?] not wanting to tie the language too tightly with trends which may prove to be dead ends.

These trends^{[original research?]} have been broken with the Java 5.0 release, which introduced several new major language features: a foreach construct, autoboxing, methods with variable number of parameters (varargs), enumerated types, generic types, and annotations. With the exception of Generics, C# included all these features from its beginning, some under different names.^[9] Proposals and specifications for the new features had been worked on in the Java community for considerable time before they were introduced. Indeed, some had been in gestation since before C#'s initial release (e.g., work on Generics formally began in May 1999^[10]) such was the Java community's conservatism at that time.

Problem-specific language additions to Java have been considered and, for now at least, rejected. This approach, along with a number of other new languages and technologies that address themselves specifically towards current programming trends, has sparked a renewed debate within the Java camp about the future direction of the Java language and whether its 'conservative evolution' is right.^{[citation needed]}

As of 2006, there is an on going debate with the inclusion of closures^[11] and properties^[12] into the language syntax for Java 7.

[edit] C#

By contrast, C# is a relatively new language. Microsoft has studied existing languages such as Java and Object Pascal, and has changed some aspects of the language and runtime environment in response to perceived failures and difficulties with its predecessors. C# accommodates constructs more commonly found in languages such as C++, Delphi (designing which was Anders Hejlsberg's principal job when he was at Borland), and, in recent C# versions, borrows from dynamic scripting languages such as Ruby.

C# has evolved rapidly to attempt to streamline development for problem-specific features. C# 3.0 adds SQL-like language integrated queries suited for querying data from collections, databases or XML documents. It however builds upon general-purpose language features; lambda expressions and extension methods features, that also allow such queries to be expressed and optimized for user types.

Before creating C#, Microsoft implemented a modified Java environment, called J++, adding new features in a manner which was in direct contravention to the standards and conventions ensuring the platform neutrality which lies at the heart of Java. This violated the license agreement Microsoft had signed, requiring that standards and specifications be strictly adhered to in return for using the Java name and brand logos. Sun Microsystems sued, and won, thus preventing Microsoft from further production of J++. With the release of the .NET framework (and C#), the project was revived in the form of J#.

[edit] See also

• Comparison of C# and VB.NET
• Comparison of Java and C++
• Java programming language
• C#
• Comparison of the Java and .Net platforms

[edit] References

[edit] External links

• Contrasting C# and Java Syntax
• Java vs. C# - Code for Code Comparison
• Nine Language Performance Round-up
• Java and C-Sharp Compared
• MSDN: The C# Programming Language for Java Developers
• Standard ECMA-334 C# Language specification
• Java Language Specification (Sun)