- Comparison of C Sharp and Java
-
The correct title of this article is Comparison of C# and Java. The substitution or omission of the # sign is because of technical restrictions.
This article compares Microsoft's C# programming language with Oracle's (formerly Sun's) Java programming language. While the focus of this article is mainly the programming languages and their features, such a comparison will necessarily also consider some platform features and some library features. For a more detailed comparison of the platforms, please see Comparison of the Java and .NET platforms.
The comparison will naturally focus on areas where the languages differ. In fact the two languages and their platforms are more alike than they are different: Both are (primarily) statically, strongly, and mostly manifestly typed, both are class-based object-oriented, both are designed with semi-interpretation or runtime compilation in mind, both use garbage-collection, and both are "curly brace" languages like C and C++. Common ancestry is also evident in their common terminology and often very similar syntax features.
Language and features
Feature comparison
This section provides a comparison of the languages in terms of features they may or may not offer, or, put differently, properties they may or may not have. The absence of a feature should not automatically be regarded as a disadvantage for the given language; sometimes features may be excluded because the language designers view them as specifically detrimental, and in other cases the designers may have viewed the feature as something that would be nice to have but not worth the added language complexity.
Data types Java C# Single-root (unified) type system No Yes Signed integers Yes; 8, 16, 32, 64 bits Yes; 8, 16, 32, 64 bits Unsigned integers No[1] Yes; 8, 16, 32, 64 bits Character Yes Yes Date/time Yes; reference type Yes; value type IEEE 754 binary32 floating point number Yes Yes IEEE 754 binary64 floating point number Yes Yes High precision floating point number No; but see Arbitrary size decimals 128-bit (28 digits) Decimal type Boolean type Yes Yes Strings Immutable reference type, Unicode Immutable reference type, Unicode Arbitrary size integers Reference type; no operators Yes Arbitrary size decimals Reference type; no operators No Complex numbers No Yes Reference types Yes Yes Arrays Yes Yes Value types No; only primitive types Yes Enumerated types Yes; reference type Yes; scalar Lifted (nullable) types No; but wrapper types Yes Tuples No Yes Pointers No Yes Reference types Java C# Garbage collection Yes Yes Weak references Yes Yes Soft references Yes No Proxy support Yes; proxy generation Yes; object contexts Object orientation Java C# Classes Yes Yes Interfaces Yes Yes Abstract classes Yes Yes Member accessibility levels Public, package, protected, private Public, internal, protected, private, protected internal Class level inner classes Yes Yes Instance level inner classes Yes No Partial classes No Yes Statement level anonymous classes Yes No Implicit (inferred) anonymous classes No Yes Deprecation/obsolescence Yes Yes Overload versioning Some Yes Properties No, but see JavaBeans spec Yes Events No; but the base class library does feature an event mechanism Yes Operator overloading No Yes Indexers No Yes Implicit conversions No Yes Explicit conversions No Yes Fields and initialization Java C# Fields Yes Yes Constants Yes Yes Static (class) constructors Yes Yes Instance constructors Yes Yes Finalizers/destructors Yes Yes Instance initializers Yes No Object initialization Bottom-up (fields and constructors) Top-down (fields); bottom-up (constructors) Object initializers No Yes Collection initializers No; can be modelled Yes Array initializers Yes Yes Methods and properties Java C# Static imports Yes No Virtual Virtual by default Non-virtual by default Abstract Yes Yes Sealing Yes Yes Explicit interface implementation No Yes Value (input) parameters Yes Yes Reference (input/output) parameters No Yes Output (output) parameters No Yes Variadic methods Yes Yes Optional arguments No Yes Named arguments No Yes Generator methods No Yes Extension methods No Yes Conditional methods No Yes Partial methods No Yes Generics Java C# Reified generics No Yes Runtime realization No Yes Covariance Yes Yes Contravariance Yes Yes Reference type constraint Yes; implicit Yes Value/primitive type constraint No Yes Constructor constraint No Yes Relation constraint Yes Yes Primitive/value type support No Yes Migration compatibility Yes No Functional programming Java C# Method references No; but see Delegates / method references Yes Closures/lambdas No; but see Delegates / method references Yes Expression trees No Yes Generic query language No Yes Runtime (dynamic) binding Java C# Late-bound (dynamic) type No Yes Runtime type information and manipulation Java C# Runtime type information Yes; but with type erasure Yes Runtime generics realization No Yes Runtime type construction No; third party tools exist Yes Statements Java C# Loops Yes Yes Conditionals Yes Yes Flow control Yes Yes Assignment Yes Yes Exception control Yes Yes Variable declaration Yes Yes Variable type inference No Yes Deterministic disposal (ARM-blocks) Yes (starting with Java 7) Yes Expressions and operators Java C# Arithmetic operators Yes Yes Logical operators Yes Yes Bitwise logic operators Yes Yes Conditional Yes Yes String concatenation Yes Yes Casts Yes Yes Boxing Yes; implicit Yes; implicit Unboxing Yes; implicit Yes; explicit Lifted operators No Yes Overflow control No Yes Strict floating point evaluation Yes; opt-in/out No Verbatim (here-)strings No Yes Exceptions Java C# Checked exceptions Yes No Try-catch-finally Yes Yes Arrays and Collections Java C# Abstract data types Yes Partial One-dimensional, zero-based index arrays Yes Yes Rectangular (multidimensional) arrays No Yes Jagged (arrays of arrays) arrays Yes Yes Non-zero based arrays No Some Unified arrays and collections No Yes Maps/dictionaries Yes Yes Sorted dictionaries Yes Yes[2] Sets Yes Yes Sorted sets Yes Yes[3] Lists/vectors Yes Yes Queues/stacks Yes Yes Priority queue Yes No Bags/multisets Yes Yes Metadata Java C# Metadata annotations/attributes Interface based Class based Positional arguments No; unless a single argument Yes Named arguments Yes Yes Default values At definition Through initialization Nested types Yes Yes Specialization No Yes Conditional metadata No Yes Preprocessing, Compilation and Packaging Java C# Namespaces Packages Namespaces Packaging Package Assembly Classes/assembly search path Yes; ClassPath No; /lib File contents RestrictedFreeConditional compilation No Yes Custom errors/warnings No Yes Explicit regions No Yes Threading and Synchronization Java C# Threads Yes Yes Thread pool Yes Yes Task based parallelism No[4] Yes[5] Semaphores Yes Yes Monitors Yes Yes Thread local variables Yes Yes; ThreadStaticAttribute Native interoperability Java C# External/native methods Yes Yes Marshalling External glue code required Yes; metadata controlled Pointers and arithmetics No Yes Native types No Yes Fixed size buffers No Yes Explicit stack allocation No Yes Address-of No Yes Object pinning (fix variable to address) No Yes Platform support Java C# Linux Yes Yes[6] Mac OS X Yes Yes[7] Solaris Yes Yes FreeBSD Yes Yes AIX Yes Partial? iOS Yes[8] Yes Windows Yes Yes Windows Mobile Yes Yes Windows Phone No Yes Android Yes Yes[9] Feature phones Yes No Symbian Yes No[10] Blackberry Yes No Syntax
Both languages are considered "curly brace" languages in the C/C++ family. Overall the syntaxes of the languages are very similar. The syntax at the statement and expression level is almost identical with obvious inspiration from the C/C++ tradition. At type definition level (classes and interfaces) some minor differences exists. Java is explicit about extending classes and implementing interfaces, while C# infers this from the kind of types a new class/interface derives from.
C# supports more features than Java which to some extent is also evident in the syntax which specifies more keywords and more grammar rules than Java.
Keywords and backwards compatibility
As the languages evolved, the language designers for both languages have faced situations where they wanted to extend the languages with new keywords and/or syntax. New keywords in particular may break existing code at source level, i.e. older code may no longer compile if presented to a compiler for a later version of the language. Language designers are keen to avoid such regressions. The designers of the two languages have been following different paths when addressing this problem.
Java language designers have avoided new keywords as much as possible, preferring instead to introduce new syntactic constructs which were not legal before or to reuse existing keywords in new contexts. This way they didn't jeopardize backwards compatibility. An example of the former can be found in how the
forloop was extended to accept iterable types. An example of the latter can be found in how theextendsand (especially) thesuperkeywords were reused for specifying type bounds when generics were introduced in Java 1.5. At one time (Java 1.4) a new keywordassertwas introduced which was not reserved as a keyword before. This had the potential to render previously valid code invalid, if for instance the code usedassertas an identifier. The designers chose to address this problem with a 4 step solution: 1) Introducing a compiler switch which indicates if Java 1.4 or later should be used, 2) Only markingassertas a keyword when compiling as Java 1.4 and later, 3) Defaulting to 1.3 to avoid rendering previous (non 1.4 aware code) invalid and 4) Issue warnings if the keyword is used in Java 1.3 mode, in order to allow the developers to change the code. Thus, the present Java syntax is backwards compatible with all previous versions except for the specific case of assert.C# language designers have introduced several new keywords since the first version. However, instead of defining these keywords as global keywords, they define them as context sensitive keywords. This means that even when they introduced (among others) the
partialandyieldkeywords in C# 2.0, the use of those words as identifiers is still valid as there is no clash possible between the use as keyword and the use as identifier, given the context. Thus, the present C# syntax is fully backwards compatible with source code written for any previous version without specifying the language version to be used.Type system
The languages use very similar type systems. Both languages are statically typed with class-based object orientation.
Unified type system
In Java the primitive types are special in that they are not object-oriented and they could not have been defined using the language itself. They also do not share a common ancestor with reference types. The Java reference types all derive from a common root type, however. C# has a unified type system in which all types ultimately derive from a common root type. Consequently, all types implement the methods of this root type, and extension methods defined for the
objecttype apply to all types, even primitiveintliterals and delegates. Note, that unlike Java, this allows C# to support objects with encapsulation which are not reference types.In Java compound types are synonymous with reference types; methods cannot be defined for a type unless it is also a class reference type. In C# the concepts of encapsulation and methods have been decoupled from the reference requirement so that a type can support methods and encapsulation without being a reference type. Only reference types support virtual methods and specialization, however.
Simple/primitive types
Both languages support a number of built-in types which are copied and passed by value rather than by reference. Java calls these types primitive types, while they are called simple types in C#. The simple/primitive types typically have native support from the underlying processor architecture.
C# has a few more primitive types than Java, because it supports unsigned as well as signed integer types, and a
decimaltype for decimal floating-point calculations.Java lacks the unsigned types. In particular, Java lacks a primitive type for an unsigned byte. The Java
bytetype is signed, while the C#byteis unsigned andsbyteis signed.Both languages feature a native
char(character) datatype as a simple type. Although the Javachartype can be used with bitwise operators, this is actually accomplished by promoting thecharto an integer before the operation.C# has a type for high-precision (28 decimal digits) decimal arithmetic for e.g. financial and monetary applications. While Java lacks such a built-in type, the Java library does feature an arbitrary precision decimal type. This is not considered a language type and it does not support the usual arithmetic operators; rather it is a reference type which must be manipulated using the type methods. See more about arbitrary size/precision numbers below.
The C# primitive/simple types implement a number of interfaces and consequently offer a number of methods directly on instances of the types - even on the literals. The C# type names are also merely aliases for Common Language Runtime types. The C#
Int64type is exactly the same type as thelongtype; the only difference is that the former is the canonical .NET name while the latter is a C# alias for it.Java does not offer methods directly on the primitive types. Instead methods which operate on the primitive values are offered through companion wrapper classes. A fixed set of such wrapper classes exist each of which wraps one of the fixed set of primitive types. As an example, the Java
Longtype is a reference type which wraps the primitivelongtype. They are not the same type, however.The following table summarizes the corresponding simple/primitive types of the languages:
C# alias .NET CLR type Width (bits) Range (approximate) Java type Java wrapper sbyte SByte 8 -128 to 127 byte Byte byte Byte 8 0 to 255 Not available Not available short Int16 16 -32768 to 32767 short Short ushort UInt16 16 0 to 65535 Not available Not available int Int32 32 -2,147,483,648 to 2,147,483,647 int Integer uint UInt32 32 0 to 4,294,967,295 Not available Not available long Int64 64 -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 long Long ulong UInt64 64 0 to 18,446,744,073,709,551,615 Not available Not available float Single 32 -3.402823e38 to 3.402823e38 float Float double Double 64 -1.79769313486232e308 to 1.79769313486232e308 double Double decimal Decimal 128 ±1.0 × 10e−28 to ±7.9 × 10e28 Not available Not available char Char 16 \u0000 to \uFFFF char Character bool Boolean 8 false, true boolean Boolean Advanced numeric types
Both languages offer library-defined arbitrary size integer types.
Only Java offers a data type for arbitrary precision decimal point calculations and only C# offers a type for working with complex numbers.
In both languages the number of operations which can be performed are limited compared to the built-in IEEE 754 floating point types. For instance, none of the types support square root or logarithms.
By using the C# support for type integration through custom operator overloading and custom (implicit and explicit) type conversions, C# achieves better parity with the built-in types.
Java C# BigInteger bigNumber = new BigInteger("123456789012345678901234567890"); BigInteger answer = bigNumber.multiply(new BigInteger("42")); BigInteger square = bigNumber.multiply(bigNumber); BigInteger sum = bigNumber.add(bigNumber);
BigInteger bigNumber = BigInteger.Parse("123456789012345678901234567890"); var answer = bigNumber * 42; var square = bigNumber * bigNumber; var sum = bigNumber + bigNumber;
Built-in compound data types
Both languages treat strings as (immutable) objects of reference type. In both languages the type contains a number of methods to manipulate strings, parse, format etc. In both languages regular expressions are considered an external feature and is implemented in separate classes.
Both languages' libraries define classes for working with dates and calendars in different cultures. The Java
java.util.Dateis a mutable reference type where the C#System.DateTimeis a struct value type. C# additionally define aTimeSpantype for working with time periods. Both languages support date/time arithmetic according to different cultures.Reference types
Both languages use classes and interfaces as the primary means for defining new, object-oriented types. See below for further details.
Value types
C# allows the programmer to create user-defined value types, using the
structkeyword. Unlike classes, and like the standard primitives, such value types are passed and assigned by value rather than by reference. 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.Because value types 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. Value types do not have virtual method tables, and because of that (and the fixed memory footprint), they are implicitly sealed. However, value types can (and frequently do) implement interfaces. For example, the built-in integer types implement a number of interfaces.
Apart from the built-in primitive types, Java does not include the concept of value types.
Enumerations
Java C# Definition In Java, both the enumeration type and (optionally) the individual enumeration values are Java classes. The only valid values are the ones listed in the enumeration. The enumeration type may declare or override members (such as a dedicated toString()method) which will be inherited by the individual enumerated values. The individual enumerated values may in turn override members or even define new members only valid for that specific value.Enumerations in C# are implicitly derived from the Enumtype which again is a value type derivative. The value set of a C# enumeration is defined by the underlying type which can be a signed or unsigned integer type of 8, 16, 32 or 64 bits. The enumeration definition defines names for the selected integer values. By default the first name is assigned the value 0 (zero) and the following names are assigned in increments of 1. 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.Combining Java enumeration set and map collections provide functionality to combine multiple enumeration values to a combined value. These special collections allows compiler optimization to minimize the overhead incurred by using collections as the combination mechanism. C# supports bit-mapped enumerations where an actual value may be a combination of enumerated values bitwise or'ed together. The formatting and parsing methods implicitly defined by the type will attempt to use these values. In both C# and Java, programmers can use enumerations in a switch statement without conversion to a string or primitive integer type.
Delegates / method references
C# implements object oriented method pointers in the form of delegates. A delegate is a special type which can capture a type-safe reference to a method. This reference can then be stored in a delegate-type variable or passed to a method through a delegate parameter for later invocation. C# delegates support covariance and contravariance, and can hold a reference to any signature-compatible static method, instance method, anonymous method or lambda expression.
Delegates should not be confused with closures and inline functions. The concepts are related because a reference to a closure/inline function must be captured in a delegate reference to be useful at all. But a delegate does not always reference an inline function, it can also reference existing static or instance methods. Delegates form the basis of C# events but should not be confused with those either.
Delegates were deliberately left out of Java because they were considered unnecessary and detrimental to the language, and because of potential performance issues.[11] Instead, an alternative mechanism must be used. The wrapper pattern, which resembles the delegates of C# in that it barely allows the client to access one or more client-defined subroutines through a known interface, is one way to design such a mechanism.
Java C# // define a common interface for all invokeable objects // (will use the wrapper pattern) interface Invokeable { boolean invoke(String arg); } // a target class class Target { public boolean targetMethod(String arg) { // do something return true; } } // usage void doSomething() { // construct a target with the target method final Target target = new Target(); // wrap the target Invokeable ivk = new Invokeable() { public boolean invoke(String arg) { return target.targetMethod(arg); } }; // use the target through the wrapper boolean result = ivk.invoke("argumentstring"); }// define a delegate private delegate bool SomeDelegate(string resource); // a target class class Target { public bool TargetMethod(string arg) { // do something return true; } } // usage void doSomething() { // construct a target with the target method var target = new Target(); // capture the delegate for later invocation SomeDelegate dlg = target.TargetMethod; // invoke the delegate bool result = dlg("argumentstring"); }Lifted (nullable) types
C# allows value/primitive/simple types to be "lifted" to allow the special
nullvalue in addition to the type's native values. A type is lifted by adding a?suffix to the type name. Conversions are implicitly defined to convert between values of the base and the lifted type. The lifted type can be compared againstnullor it can be tested forHasValue. Also, lifted operators are implicitly and automatically defined based on their non-lifted base, where — with the exception of some boolean operators — a null argument will propagate to the result.Java does not support type lifting as a concept, but all of the built-in primitive types have corresponding wrapper types, which do support the
nullvalue by virtue of being reference types (classes).
According to the Java spec, any attempt to dereference the null reference must result in an exception being thrown at run-time, specifically a NullPointerException. (It would not make sense to dereference it otherwise, because, by definition, it points to no object in memory.) This also applies when attempting to unbox a variable of a wrapper type, which evaluates to null: the program will throw an exception, because actually there is no object to be unboxed - and therefore no boxed value to take part in the subsequent computation.The following example illustrates the different behavior. In C#, the lifted * operator propagates the
nullvalue of the operand; in Java, unboxing the null reference throws an exception.Java C# Integer a = 42; Integer b = null; // This will generate a runtime NullPointerException, // because it attempts to unbox the null value. Integer c = a * b;
int? a = 42; int? b = null; // c will receive the null value // because * is lifted and one of the operands are null int? c = a * b;
Not all C# lifted operators have been defined to propagate
nullunconditionally if one of the operands isnull. Specifically, the boolean operators have been lifted to support ternary logic thus keeping impedance with SQL.The Java boolean operators do not support ternary logic, nor is it implemented in the base class library.
Late-bound (dynamic) type
C# features a late bound dynamic type which supports no-reflection dynamic invocation, interoperability with dynamic languages as well as ad-hoc binding to (for example) document object models. The
dynamictype resolves member access dynamically at runtime as opposed to statically/virtual at compile time. The member lookup mechanism is extensible with traditional reflection as a fall-back mechanism.There are several use cases for the
dynamictype in C#:- Less verbose use of reflection: By casting an instance to the
dynamictype, members such as properties, methods, events etc. can be directly invoked on the instance without using the reflection API directly. - Interoperability with dynamic languages: The dynamic type comes with a hub-and-spoke support for implementing dynamically typed objects and common runtime infrastructure for efficient member lookup.
- Creating dynamic abstractions on the fly: For instance, a dynamic object could provide simpler access to document object models such as XML or XHTML documents.
Java does not support a late-bound type. The use cases for C# dynamic type have different corresponding constructs in Java:
- For dynamic late-bound by-name invocation of preexisting types, reflection should be used.
- For interoperability with dynamic languages, some form of interoperability API specific to that language will have to be used. The Java Virtual Machine platform does have multiple dynamic languages implemented on top of it, but there is no common standard for how to pass objects between languages. Usually this will involve some form of reflection or reflection-like API. As an example of how to use JavaFX objects from Java, see How to Use JavaFX in Your Swing Application.
- For creating and interacting with objects entirely at runtime, e.g. interaction with a document object model abstraction, a specific abstraction API will have to be used.
Dynamic language interoperability
The C#
dynamicenables seamless interoperability with dynamic (late-bound) languages by allowing C# code to manipulate foreign objects using the same syntax as if they were native C# objects. Lacking this capability, Java developers must use a Java based API to access such objects. Consider a Ruby class (defined in a file called Deepthought.rb) which has 2 attributes (a,b) with read/write accessors and aCalculatemethod which returns the product of the attributes. The following examples illustrate how to instantiate and use such a class from within Java and C#, respectively.Java C# initialization ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine = factory.getEngineByName("jruby"); Invocable invocable = (Invocable) engine; FileReader fr = new FileReader("Deepthought.rb"); engine.eval(fr);
var runtime = ScriptRuntime.CreateFromConfiguration(); dynamic globals = runtime.Globals; runtime.ExecuteFile("Deepthought.rb");
usage Object calcClass = engine.eval("Deepthought"); Object calc = invocable.invokeMethod(calcClass, "new"); invocable.invokeMethod(calc, "a=", 6); invocable.invokeMethod(calc, "b=", 7); Object answer = invocable.invokeMethod(calc, "Calculate");
var calc = globals.Deepthought.@new(); calc.a = 6; calc.b = 7; var answer = calc.Calculate();
notes - Ruby accessors names are generated from the attribute name with a
=suffix. When assigning values, Java developers must use the Ruby accessor method name. - Dynamic objects from a foreign language are not first-class objects in that they must be manipulated through an API.
- Objects returned from properties or methods of
dynamicobjects are themselves ofdynamictype. When type inference (thevarkeyword) is used, the variables calc and answer are inferred dynamic/late-bound. - Dynamic, late-bounds objects are first-class citizens which can be manipulated using C# syntax even though they have been created by an external language.
newis a reserved word. The@prefix allows keywords to be used as identifiers.
Pointers
C# allows use of pointers and corresponding pointer arithmetic. Pointers and pointer-arithmetic are potentially unsafe in a managed environment as they can be used to bypass the strict rules for object access. C# addresses that concern by requiring that code blocks or methods that use the feature be marked with the
unsafekeyword, 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, and assemblies containing unsafe code may only execute if explicitly granted security permissions. Generally, unsafe code is either used to allow better interoperability with unmanaged APIs or system calls (which are inherently "unsafe"), or for performance reasons. Java does not permit pointers or pointer-arithmetic within the Java runtime environment and native interop is handled externally through JNI or other mechanisms.Object handling
Both C# and Java are designed from the ground up as object oriented languages using dynamic dispatch, with syntax similar to C++ (C++ in turn derives from C). Neither language is a superset of C or C++, however.
Both languages mainly use garbage collection as a means of reclaiming memory resources, rather than explicit deallocation of memory. In both cases, if an object holds resources of different kinds other than memory, such as file handles, graphical resources, etc., then it will have to be notified explicitly when the application no longer uses it. Both C# and Java offer interfaces for such deterministic disposal and both C# and Java (since Java 7) feature automatic resource management statements which will automatically invoke the disposal/close methods on those interfaces.
Both languages include thread synchronization mechanisms as part of their language syntax.
References
In both languages references are a central concept. All instances of classes are by reference.
While not directly evident in the language syntax per se, both languages support the concept of weak references. An instance which is only referenced by weak references is eligible for garbage collection just as if there were no references at all. In both languages this feature is exposed through the associated libraries, even though it is really a core runtime feature.
In addition to weak references, Java has soft references. Soft references are much like weak references, but the JVM will not deallocate softly-referenced objects until the memory is actually needed.
Object initialization
In both C# and Java, an object's fields can be initialized either by variable initializers (expressions that can be assigned to variables where they are defined) or by constructors (special subroutines that are executed when an object is being created). In addition, Java contains instance initializers, which are anonymous blocks of code with no arguments that are run after the explicit (or implicit) call to a superclass's constructer but before the constructor is executed.
C# initializes object fields in the following order when creating an object:
- Derived static fields
- Derived static constructor
- Derived instance fields
- Base static fields
- Base static constructor
- Base instance fields
- Base instance constructor
- Derived instance constructor
Some of the above fields may not be applicable (e.g. if an object does not have static fields). Derived fields are those that are defined in the object's direct class, while base field is a term for the fields that are defined in one of the object's superclasses. Note that an object representation in memory contains all fields defined in its class or any of its superclasses, even if some fields in superclasses are defined as private.
It is guaranteed that any field initializers take effect before any constructors are called, since both the instance constructor of the object's class and its superclasses are called after field initializers are called. There is, however, a potential trap in object initialization when a virtual method is called from a base constructor. The overridden method in a subclass may reference a field that is defined in the subclass, but this field may not have been initialized because the constructor of the subclass that contains field initialization is called after the constructor of its base class.
In Java, the order of initialization is as follows:
- Invocation of another constructor (either of the object's class or of the object's superclass)
- Instance variable initializers and instance initializers (in the order they appear in the source code)
- The constructor body
Like in C#, a new object is created by calling a specific constructor. Within a constructor, the first statement may be an invocation of another constructor. If this is omitted, the call to the argumentless constructor of the superclass is added implicitly by the compiler. Otherwise, either another overloaded constructor of the object's class can be called explicitly, or a superclass constructor can be called. In the former case, the called constructor will again call another constructor (either of the object's class or its subclass) and the chain sooner or later ends up at the call to one of the constructors of the superclass.
After another constructor is called (which causes direct invocation of the superclass constructor, and so forth, down to the Object class), instance variables defined in the object's class are initialized. Even if there are no variable initializers explicitly defined for some variables, these variables are initialized to default values. Note that instance variables defined in superclasses are already initialized by this point, because they were initialized by a superclass constructor when it was called (either by the constructor's code or by variable initializers performed before the constructor's code or implicitly to default values). In Java, variable initializers are executed according to their textual order in the source file.
Finally, the constructor body is executed. This ensures proper order of initialization, i.e. the fields of a base class finish initialization before initialization of the fields of an object class begins.
There are two main potential traps in Java's object initialization. First, variable initializers are expressions that can contain method calls. Since methods can reference any variable defined in the class, the method called in a variable initializer can reference a variable that is defined below the variable being initialized. Since initialization order corresponds to textual order of variable definitions, such a variable would not be initialized to the value prescribed by its initializer and would contain the default value. Another potential trap is when a method that is overridden in the derived class is called in the base class constructor, which can lead to behavior the programmer would not expect when an object of the derived class is created. According to the initialization order, the body of the base class constructor is executed before variable initializers are evaluated and before the body of the derived class constructor is executed. The overridden method called from the base class constructor can, however, reference variables defined in the derived class, but these are not yet initialized to the values specified by their initializers or set in the derived class constructor. The latter issue applies to C# as well, but in a less critical form since in C# methods are not overridable by default.
Arrays and collections
Arrays and collections are concepts featured by both languages. The syntax used to declare and access arrays is identical, except that C# has added syntax for declaring and manipulating multidimensional arrays.
Java C# Arrays are implicitly direct specializations of Object. They are not unified with collection types.Arrays in C# are implicitly specializations the System.Arrayclass which implements a number of collection interfaces.Arrays and collections are completely separate with no unification. Arrays cannot be passed where sequences or collections are expected Arrays can be passed where sequences ( IEnumerables) or collections/list interfaces are expected. However, the collection operations which alter the number of elements (insert/add/remove) will throw exceptions as these operations are not supported by arrays.The forstatement accepts either arrays orIterables. All collections implementIterable. This means that the same short syntax can be used in for-loops.The foreachstatement iterates through a sequence using theIEnumerableorIEnumerable<T>interface. Because arrays always implicitly implement these interfaces, the loop will iterate through arrays as well.In both languages arrays are covariant. This means that a String[]array is assignable to variables ofObject[]becauseStringis a specialization of (assignable to)Object. In both languages the arrays will perform a type check when inserting new values because type-safety would otherwise be compromised. This is in contrast to how generic collections have been implemented in both languages.Multidimensional arrays only in the form of arrays of arrays (also known as "jagged" arrays); Java does not have true rectangular multidimensional arrays. True multidimensional "rectangular" arrays, as well as arrays of arrays (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). However, since all array element access in a multidimensional array requires multiplication/shift between the two or more dimensions, this is an advantage only in very random access scenarios.
Another potential 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 dimension. Note, though, that Java provides a syntactic construct for allocating a multidimensional jagged array with regular lengths; the loops and multiple allocations are then performed by the virtual machine and need not be explicit at the source level.Both languages feature an extensive set of collection types which includes various ordered and unordered types of lists, maps/dictionaries, sets, etc.
Type members
Operator overloading and implicit and explicit conversions
Operator overloading and user-defined casts are separate features which both aim to allow new types to become first-class citizens in the type system. By using these features in C#, types such as
Complexanddecimalhave been integrated so that the usual operators like addition and multiplication work with the new types.Java does not include operator overloading nor custom conversions in order to prevent abuse of the feature, and to keep the language simple.[12]
Indexers
C# also includes indexers which can be considered a special case of operator overloading (like the C++
operator[]), or parameterizedget/setproperties. An indexer is a property namedthis[]which uses one or more parameters (indexes); the indices can be objects of any type:myList[4] = 5; string name = xmlNode.Attributes["name"]; orders = customerMap[theCustomer];
Java does not include indexers. The common Java pattern involves writing explicit getters and setters where a C# programmer would use an indexer.
Partial classes
C# allows a class definition to be split across several source files using a feature called partial classes. Each part must be marked with the keyword
partial. All the parts must be presented to the compiler as part of a single compilation. Parts can reference members from other parts. Parts can implement interfaces and one part can define a base class. The feature is useful in code generation scenarios (such as UI design) where a code generator can supply one part and the developer another part to be compiled together. The developer can thus edit their part without the risk of a code generator overwriting that code at some later time. Unlike the class extension mechanism, a partial class allows "circular" dependencies among its parts as they are guaranteed to be resolved at compile time. Java has no corresponding concept.Inner and local classes
Both languages allow inner classes, where a class is defined lexically inside another class. However, in each language these inner classes have rather different semantics.
In Java, unless the inner class is declared
static, a reference to an instance of an inner class carries a reference to the outer class with it. As a result, code in the inner class has access to both the static and non-static members of the outer class. To create an instance of a non-static inner class, one has to name the instance of the embracing outer class.[13] This is done via a newnew-operator introduced in JDK 1.3:outerClassInstance.new Outer.InnerClass(). This can be done in any class that has a reference to an instance of the outer class.In C#, an inner class is conceptually the same as a normal class. In a sense, the outer class only acts as a namespace. Thus, code in the inner class cannot access non-static members of the outer class unless it does so through an explicit reference to an instance of the outer class. Programmers can declare the inner class private to allow only the outer class to have any access to it.
Java provides another feature called local classes or anonymous classes, which can be defined within a method body. These are generally used to implement an interface with only one or two methods, which are typically event handlers. However, they can also be used to override virtual methods of a superclass. The methods in those local classes have access to the outer method's local variables declared
final. C# satisfies the use-cases for these by providing anonymous delegates; see event handling for more about this.C# also provides a feature called anonymous types/classes, but it is rather different from Java's concept with the same name. It allows the programmer to instantiate a class by providing only a set of names for the properties the class should have, and an expression to initialize each. The types of the properties are inferred from the types of those expressions. These implicitly-declared classes are derived directly from object.
Explicit member implementation
C# 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.
Events
C# multicast-delegates are called events. Events provide support for event-driven programming and is an implementation of the observer pattern. To support this there is a specific syntax to define events in classes, and operators to register, unregister or combine event handlers.
See here for information about how events are implemented in Java.
Statements and expressions
Boxing and unboxing
Both languages allow automatic boxing and unboxing, i.e. they allow for implicit casting between any primitive types and the corresponding reference types.
In C#, the primitive types are subtypes of the Object type. In Java this is not true; any given primitive type and the corresponding wrapper type have no specific relationship with each other, except for autoboxing and unboxing, which act as syntactic sugar for interchanging between them. This was done intentionally, to maintain backwards compatibility with prior versions of Java, in which no automatic casting was allowed, and the programmer worked with two separate sets of types: the primitive types, and the wrapper (reference) type hierarchy.[14]This difference has the following consequences. First of all, in C#, primitive types can define methods, such as an override of Object's
ToString()method. In Java, this is task is accomplished by the primitive wrapper classes.
Secondly, in Java an extra cast is needed whenever one tries to directly dereference a primitive value, as it will not be boxed automatically. The expression((Integer)42).toString()will convert an integer literal to string in Java while42.ToString()performs the same operation in C#. This is because the latter one is actually an instance call on the primitive value42, while the former one is an instance call on an object of type java.lang.Integer.Finally, another difference is that Java makes heavy use of boxed types in generics (see below).
Generics
Further information: Generic programmingIn the field of generics the two languages show a superficial syntactical similarity, but they have deep underlying differences.
Type erasure versus reified generics
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; generics are not part of the JVM. Instead, generics classes and methods are transformed during compilation through a process known as type erasure. During this process the compiler replaces all generic types with their raw version and inserts casts/checks appropriately in client code where the type and its methods are used. The resulting byte code will contain no references to any generic types or parameters (See also Generics in Java).
The language specification intentionally prohibits certain uses of generics; this is necessary to allow for implementing generics through type erasure, and to allow for migration compatibility.[15]C# builds on support for generics from the virtual execution system itself, i.e. it is not just a language feature. The language is merely a front-end for cross-language generics support in the CLR. During compilation generics are verified for correctness, but code generation for actually implementing the generics are deferred to class-load time. Client code (code invoking generic methods/properties) are fully compiled and can safely assume generics to be type-safe. This is called reification. At runtime, when a unique set of type parameters for a generic class/method/delegate is encountered for the first time, the class loader/verifier will synthesize a concrete class descriptor and generate method implementations. During the generation of method implementations all reference types will be considered a single type, as reference types can safely share the same implementations. Note, this is merely for the purpose of the implementing code. Different sets of reference types will still have unique type descriptors; their method tables will merely point to the same code.
The following list illustrates some differences between Java and C# when managing generics. It is not exhaustive[16]:
Java C# Type checks and downcasts are injected into client code (the code referencing the generics). Compared to non-generic code with manual casts, these casts will be the same.[17] But compared to compile-time verified code which would not need runtime casts and checks, these operations represent a performance overhead. C#/.NET generics guarantees type-safety and is verified at compile time and no extra checks/casts are necessary at runtime. Hence, generic code will run faster than non-generic code (and type-erased code) which require casts when handling non-generic or type-erased objects. Cannot use primitive types as type parameters; instead the developer must use the wrapper type corresponding to the primitive type. This incurs extra performance overhead by requiring boxing and unboxing conversions as well a memory and garbage collection pressure because the wrappers will be heap allocated as opposed to stack allocated. Primitive and value types are allowed as type parameters in generic realizations. At runtime code will be synthesized and compiled for each unique combination of type parameters upon first use. Generics which are realized with primitive/value type do not require boxing/unboxing conversions. Generic exceptions are not allowed[18] and a type parameter cannot be used in a catch clause[19] Can both define generic exceptions and use those in catch clauses Static members are shared across all generic realizations[20] (during type erasure all realizations are folded into a single class) Static members are separate for each generic realization. A generic realization is a unique class. Type parameters cannot be used in declarations of static fields/methods or in definitions of static inner classes No restrictions on use of type parameters Cannot create an array where the component type is a generic realization (concrete parameterized type) Object tenPairs = new Pair<Integer, String>[10]; // error
A generic realization is a 1st class citizen and can be used as any other class; also an array component object tenPairs = new Pair<int, string>[10]; // ok
Cannot create an array where the component type is a type parameter public class Lookup<TKey,TValue> { public TValue[] getEmptyValues(TKey key) { return new TValue[0]; // error } }
Type parameters represent actual, discrete classes and can be used like any other type within the generic definition. public class Lookup<TKey, TValue> { public TValue[] GetEmptyValues(TKey key) { return new TValue[0]; // ok } }
There is no class literal for a concrete realization of a generic type A generic realization is an actual class. instanceofis not allowed with type parameters or concrete generic realizationsThe isandasoperators work the same for type parameters as for any other type.Cannot create new instances using a type parameter as the type With a constructor constraint, generic methods or methods of generic classes can create instances of classes which have default constructors. Type information is erased during compilation. Special extensions to reflection must be used to discover the original type. Type information about C# generic types is fully preserved at runtime, and allows complete reflection support as well as instantiation of generic types. Reflection cannot be used to construct new generic realizations. During compilation extra code (typecasts) are injected into the client code of generics. This precludes creating new realizations later. Reflection can be used to create new realizations for new combinations of type parameters. C# allows generics directly for primitive types. Java, instead, allows the use of boxed types as type parameters (e.g.,
List<Integer>instead ofList<int>). This comes at a cost since all such values need to be boxed/unboxed when used, and they all need to be heap-allocated. However, a generic type can be specialized with an array type of a primitive type in Java, for exampleList<int[]>is allowed.[21]Migration compatibility
Java's type erasure design was motivated by a design requirement to achieve migration compatibility - not to be confused with backward compatibility. In particular, the original requirement was "... there should be a clean, demonstrable migration path for the Collections APIs that were introduced in the Java 2 platform".[22] This was designed so that any new generic collections should be passable to methods which expected one of the pre-existing collection classes.[23]
C# generics were introduced into the language while preserving full backwards compatibility, but did not preserve full migration compatibility: Old code (pre C# 2.0) runs unchanged on the new generics-aware runtime without recompilation. As for migration compatibility, new generic collection classes and interfaces were developed which supplemented the non-generic .NET 1.x collections rather than replacing them. In addition to generic collection interfaces, the new generic collection classes implement the non-generic collection interfaces where possible. This prevents the use of new generic collections with pre-existing (non-generic aware) methods, if those methods are coded to use the collection classes.
Covariance and contravariance
Further information: Covariance and contravariance (computer science)Covariance and contravariance is supported by both languages. Java has use-site variance which allows a single generic class to declare members using both co- and contravariance. C# has define-site variance for generic interfaces and delegates. Variance is not supported directly on classes but is supported through their implementation of variant interfaces. C# also has use-site covariance support for methods and delegates.
Notation and special features
Special feature keywords
keyword feature, example usage checked,uncheckedIn C#, checkedstatement blocks or expressions can enable run-time checking for arithmetic overflow.get,setC# implements properties as part of the language syntax with their optional corresponding getandsetaccessors, as an alternative for the accessor methods used in Java, which is not a language feature but a coding-pattern based on method name conventions.gotoC# supports the gotokeyword. This can occasionally be useful, for example for implementing finite state machines or for generated code, but the use of a more structured method of control flow is usually recommended (see criticism of the goto statement). Java does not support thegotostatement (butgotois a reserved word). However, Java does support labeledbreakandcontinuestatements, which in certain situations can be used when agotostatement might otherwise be used.switch(color) { case Color.Blue: Console.WriteLine("Color is blue"); break; case Color.DarkBlue: Console.WriteLine("Color is dark"); goto case Color.Blue; // ... }
lockIn C#, the lockkeyword is a shorthand for synchronizing access to a block of code across threads (using aMonitor), wrapped in atry...finallyblock.out,refC# has support for output and reference parameters. These allow returning multiple output values from a method, or passing values by reference. strictfpJava uses strictfpto guarantee the results of floating point operations remain the same across platforms.switchIn C#, the switch statement also operates on strings and longs but only allows fallthrough for empty statements. Java's switch statement does not operate on strings (before Java 7) nor longprimitive type but falls through for all statements (excluding those with 'break').throwsJava requires every method to declare the checked exceptions or superclasses of the checked exceptions that it can throw. Any method can also optionally declare the unchecked exception that it throws. C# has no such syntax. public int readItem() throws java.io.IOException { // ... }
usingIn C#, usingcauses theDisposemethod (implemented via theIDisposableinterface) of the object declared to be executed after the code block has run or when an exception is thrown within the code block.// 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"); }
Numeric applications
To adequately support applications in the field of mathematical and financial computation, several language features exist.[24] In this category, Java provides the strictfp keyword, which enables strict floating-point calculations for a region of code. This will ensure that calculations return exactly the same result on all platforms. C# provides no equivalent, but does provide the built-in
decimaltype, 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.The
BigDecimalclass also provides such characteristics for Java.BigDecimalandBigIntegerare types provided with Java that allow arbitrary-precision representation of numbers. As of 2010[update] the current stable release of the .NET framework (4.0) includes classes for manipulating arbitrary-precision integers and complex numbers (with operators overloaded for easy use so that BigInteger objects can be used just like any other primitive data type), but still the .NET Framework lacks classes to deal with arbitrary-precision floating point numbers (see software for arbitrary-precision arithmetic).In Java there is no way to provide the same level of integration for library-defined types such as
BigDecimalor 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
inttype that can implicitly convert tolong. - 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 mathematical applications with the
checkedanduncheckedoperators that allow the enabling or disabling of run-time checking for arithmetic overflow for a region of code.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. Virtuality 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.
Java methods are virtual by default (although they can be "sealed" by using the
finalmodifier to disallow overriding). There is no way to let derived classes define a new, unrelated method with the same name.This means that by default in Java, and only when explicitly enabled in C#, new methods may be defined in a derived class with the same name and signature as those in its base class. When the method is called on a superclass reference of such an object, the "deepest" overridden implementation of the base class' method will be called according to the specific subclass of the object being referenced.
In some cases, when a subclass introduces a method with the same name and signature as a method already present in the base class, problems can occur. In Java, this will mean that the method in the derived class will implicitly override the method in the base class, even though that may not be the intent of the designers of either class.
To mitigate this, C# requires that if a method should be overridden, the
overridekeyword must be specified. Otherwise, the method will "hide" the inherited method. A compiler warning to this effect is issued, which can be silenced by specifying thenewkeyword. This avoids 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.Generator methods
Further information: GeneratorsAny C# method declared as returning
IEnumerable,IEnumeratorand/or the generic versions of these interfaces can be implemented usingyieldsyntax. This is a form of limited, compiler-generated continuations and can drastically reduce the code required to traverse or generate sequences, although that code is just generated by the compiler instead. The feature can also be used to implement infinite sequences, e.g. the sequence of Fibonacci numbers.Java does not have an equivalent feature. Instead generators are typically defined by providing a specialized implementation of a well-known collection or iterable interface, which will compute each element on demand. For such a generator to be used in a for each statement, it must implement interface
java.lang.Iterable.Below these two approaches are shown for the two languages. Both use the designated iterator/enumerator interface of the language. Note how the C# version use multiple
yield returnstatements to alternate between accumulating in one or the other local variable. The Java version would have to use an extra boolean flag to achieve the same, or use a temporary variable as in this case.Java C# public class Fibonacci implements Iterable<Integer> { public Iterator<Integer> iterator() { return new Iterator<Integer>() { private int a = 0; private int b = 1; public boolean hasNext() { return true; // infinite sequence } public Integer next() { int tmp = a; a = b; b = a + tmp; return tmp; } public void remove() { throw new UnsupportedOperationException ("Not supported on the Fibonacci sequence."); } }; } }
public static IEnumerable<int> Fibonacci() { int a = 0; int b = 1; while (true) // infinite sequence { yield return a; a += b; yield return b; b += a; } }
Explicit interface implementation
In either language if a method (or property in C#) is specified with the same name and signature in multiple interfaces, the members will clash when a class is designed which implements those interfaces. An implementation will by default implement a common method for all of the interfaces. If separate implementations are required (because the methods really do serve separate purposes, or because return values differ between the interfaces) C#'s explicit interface implementation will solve the problem, though allowing different results for the same method, depending on the current cast of the object. In Java there is no way to solve this problem other than cleaning the code and refactoring one or more of the interfaces to avoid name clashes.
Closures
A closure is an inline function which captures variables from its lexical scope.
C# supports closures as anonymous methods or lambda expressions with full-featured closure semantics.[25][26]
In Java, anonymous inner classes remains the preferred way to emulate closures. Aside from being a more verbose construction, this approach also has some drawbacks compared to real closures, such as limited access to variables from the enclosing scopes (only final members can be referenced).
When a reference to a method can be passed around for later execution, a problem arises about what to do when the method has references to variables/parameters in its lexical scope. C# closures can fully capture any variable/parameter from its lexical scope. In Java's anonymous inner classes only references to final members of the lexical scope are allowed, thus requiring the developer to artificially introduce extra levels of indirections and boxing primitive types if he wants to reference and update those from the inner class.
While Java does not currently feature closures, it has been announced that some form of closures or lambdas will be included in JDK 8 which at latest update (10 October 2010) is scheduled for release "late 2012".[27]
Language integrated query (LINQ)
Further information: LINQC#s Language INtegrated Query (LINQ) is not really a single feature; rather it is a number of features designed to work together to allow for in-language querying capabilities. LINQ has emerged as one of the most distinguishing features between Java and C#.
LINQ consists of the following features:
- Extension methods allow existing interfaces or classes to be extended with new methods. Implementations can be shared or an interface can have a dedicated implementation.
- Lambdas allow for expression of criteria in a functional fashion.
- Expression trees allow a specific implementation to capture a lambda as a concrete syntax tree rather than an executable block. This can be utilized by implementations to represent criteria in a different language, e.g. in the form of an SQL where clause as is the case with e.g. Linq, LINQ to SQL.
- Anonymous types and type inference supports capturing and working with the result type of a query. A query may both join and project over query sources which may lead to a result type which cannot be named.
- Query expressions to support a syntax familiar to SQL users.
- Nullable (lifted) types to allow for a better match with query providers which support nullable types, like e.g. SQL.
Lambdas and expression trees
C# features a special type of in-line closures called lambdas. These are anonymous methods: they have a signature and a body, but no name. They are mainly used to specify local function-valued arguments in calls to other methods, a technique mainly associated with functional programming. On top of that, lambda functions can double as a way to define special data structures called expression trees. Whether they are seen as an executable function or as a data structure depends on compiler type inference and what type of variable or parameter they are assigned or cast to. Lambdas and expression trees play key roles in LINQ. Java does not feature lambdas or expression trees; its primary mechanism for inline scope capture and method definition is the anonymous inner class syntax.
Partial methods
Related to partial classes C# allows partial methods to be specified within partial classes. A partial method is an intentional declaration of a method with a number of restrictions on the signature. These restrictions ensure that if a definition is not actually provided by any class part, then the method and every call to it can be safely erased. This feature allows code to provide a large number of interception points (like the template method GoF design pattern) without paying any runtime overhead if these extension points are not being used by another class part at compile time. Java has no corresponding concept.
Extension methods
Using a special this designator on the first parameter of a method, C# allows the method to act as if it were a member method of the type of the first parameter. This extension of the foreign class is purely syntactical. The extension method needs to be static and defined within a purely static class. It must obey any restriction on such external static methods and thus cannot break object encapsulation. The "extension" is only active within scopes where the namespace of the static host class has been imported. Java does not have an equivalent feature (although one is being discussed for Java 8).
Conditional compilation
Unlike Java, C# implements conditional compilation using preprocessor directives. It also provides a
Conditionalattribute 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 methodDebug.Assert(), which is only evaluated when theDEBUGconstant 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-enableassertionsor-easwitch when invoking the JVM.Namespaces and source files
In C#, namespaces are similar to those in C++. Unlike package names in Java, a namespace is not in any way tied to the location of the source file. While it is not strictly necessary for a Java source file location to mirror its package directory structure, it is the conventional organization.
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 ofusing 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)wherefoo()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., allowingfoo.bar()wherebar()can be an imported extension method working on the type offoo).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. C# 2.0 and later allows splitting a class definition into several files by using the
partialkeyword in the source code. In Java, a public class will always be in its own source file. In C#, source code files and logical units separation are not tightly related.Exception handling
Java supports checked exceptions (in addition to unchecked exceptions). C# only supports unchecked exceptions. Checked exceptions force the programmer to either declare the exception thrown in a method, or to catch the thrown exception using a
try-catchclause.Checked exceptions can encourage good programming practice, ensuring that all errors are dealt with. However Anders Hejlsberg, chief C# language architect, argues that they were to some extent an experiment in Java and that they have not been shown to be worthwhile except in small example programs.[28][29]
One criticism is that checked exceptions encourage programmers to use an empty catch block (
catch (Exception e) {}), which silently eats exceptions, rather than letting the exceptions propagate to a higher-level exception-handling routine. In some cases, however, exception chaining can be applied instead, by re-throwing the exception in a wrapper exception. For example, if an object is changed to access a database instead of a file, anSQLExceptioncould be caught and re-thrown as anIOException, 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-finallystatement. Thefinallyblock is always executed, even if thetryblock contains control-passing statements likethroworreturn. In Java, this may result in unexpected behavior if thetryblock is left by areturnstatement with some value, and then thefinallyblock that is executed afterwards is also left by areturnstatement with a different value. C# resolves this problem by prohibiting any control-passing statements likereturnorbreakin thefinallyblock.A common reason for using
try-finallyblocks is to guard resource managing code, thus guaranteeing the release of precious resources in the finally block. C# features theusingstatement as a syntactic shorthand for this common scenario, in which theDispose()method of the object of theusingis always called.A rather subtle difference is the moment a stack trace is created when an exception is being thrown. In Java, the stack trace is created in the moment the exception is created.
class Foo { Exception e = new Exception(); int foo() { throw e; } }
The exception in the statement above will always contain the constructor's stack-trace - no matter how often foo is called. In C# on the other hand, the stack-trace is created the moment "throw" is executed.
class Foo { Exception e = new Exception(); int foo() { try { throw e; } catch (Exception e) { throw; } } }
In the code above, the exception will contain the stack-trace of the first throw-line. When catching an exception, there are two options in case the exception should be rethrown:
throwwill just rethrow the original exception with the original stack, whilethrow ewould have created a new stack trace.Finally blocks
Java allows flow of control to leave the
finallyblock of atrystatement, regardless of the way it was entered. This can cause another control flow statement (such asreturn) to be terminated mid-execution. For example:int foo() { try { return 0; } finally { return 1; } }
In the above code, the
returnstatement withintryblock causes control to leave it, and thereforefinallyblock is executed before the actual return happens. However,finallyblock itself performs a return as well; thus, the original return that caused it to be entered is not actually executed, and the above method returns 1 rather than 0.C# does not allow any statements which allow control flow to leave the
finallyblock prematurely, except forthrow. In particular,returnis not allowed at all,gotois not allowed if the target label is outside thefinallyblock, andcontinueandbreakare not allowed if the nearest enclosing loop is outside thefinallyblock.Lower level code
The Java Native Interface (JNI) feature allows Java programs to call non-Java code. However, JNI does require the code being called to follow several conventions and imposes 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++. Java Native Access (JNA) allows easier calling of native code that only requires writing Java code, but comes at a performance cost.
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 limited 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 using this feature, the programmer must mark the code using the
unsafekeyword. 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. An assembly (program or library) 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.Runtime environments
Java (the programming language) is designed to execute on the Java platform via the Java Runtime Environment (JRE). The Java platform includes the Java Virtual Machine (JVM) as well as a common set of libraries. The JRE was originally designed to support interpreted execution with final compilation as an option. Most JRE environments execute fully or at least partially compiled programs, possibly with adaptive optimization. The Java compiler produces Java bytecode. Upon execution the bytecode is loaded by the Java runtime and either interpreted directly or compiled to machine instructions and then executed.
Further information: Java Runtime EnvironmentC# is designed to execute on the Common Language Runtime (CLR). The CLR is designed to execute fully compiled code. The C# compiler produces Common Intermediate Language instructions. Upon execution the runtime loads this code and compiles to machine instructions on the target architecture.
Further information: Common Language RuntimeLanguage history and evolution
Java
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 books than C# books.[30] Java's maturity and popularity have ensured more third party Java APIs and libraries (many of them open source)[citation needed] than C#[citation needed].
An occasionally voiced criticism [31] of the Java language is that it evolves slowly, lacking some features which make fashionable programming patterns and methodologies easier.[citation needed] Some critics[who?] suggest that the designers of C# may pander too quickly to current trends in programming, thus 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.[32] Proposals and specifications for the new features had been worked on in the Java community for a 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[33]), such was the Java community's conservatism at that time[opinion].
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 2008 debate continued over the inclusion of closures[34] and properties[35] into the language syntax for Java 7.
C#
By contrast, C# is a relatively[weasel words] new language. Microsoft has studied existing languages such as Java and Object Pascal[citation needed], and has changed some aspects of the language and runtime environment in response[citation needed] to perceived failures and difficulties with its predecessors[original research?]. C# accommodates constructs more commonly found in languages such as C++, Delphi (the design of 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 and Python[citation needed].
C# 3.0 adds SQL-like language integrated queries suited for querying data from collections, databases or XML documents, building upon general-purpose language features, including lambda expressions and extension methods, to allow 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[citation needed] to the standards and conventions that ensure the platform neutrality which lies at the heart of Java. This violated[citation needed] 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 in settling the suit, Microsoft agreed to discontinue J++. (The settlement allowed other existing Java-using Microsoft products to continue such use for seven years.[36]) With the release of the .NET framework (and C#), the project was revived in the form of J#.
See also
- Comparison of C# and VB.NET
- Comparison of Java and C++
- Java programming language
- Comparison of the Java and .Net platforms
References
- ^ Unsigned integers were deliberately left out of Java because James Gosling believed that programmers would not understand how unsigned arithmetic works.
retrieved from http://www.artima.com/intv/gosling3P.htmlIn programming language design, one of the standard problems is that the language grows so complex that nobody can understand it. One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C. It turns out nobody understands how unsigned arithmetic in C works. There are a few obvious things that people understand, but many people don't understand it.
- ^ http://msdn.microsoft.com/en-us/library/f7fta44c.aspx
- ^ http://msdn.microsoft.com/en-us/library/dd412070.aspx
- ^ Fork-join framework planned for inclusion with JDK7 including some language support (resembling closures)
- ^ Microsoft Task Parallel Library
- ^ http://www.mono-project.com/Compatibility
- ^ http://www.mono-project.com/Compatibility
- ^ http://www.flexycore.com/ispectrum-overview.html
- ^ http://mono-android.net/
- ^ http://en.wikipedia.org/wiki/Symbian#Other_languages
- ^ The Java Language Team, About Microsoft's "Delegates"
- ^ August 1998 Java News
- ^ Java Language Specification Third Edition: section 15.9 Class Instance Creation Expressions
- ^ The separation of primitive and reference types is a fundamental property of the Java programming language.: [1]
- ^ The Java Language Specification.
- ^ see also Java Generics FAQs - Frequently Asked Questions by Angelika Langer
- ^ http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ110
- ^ http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ302
- ^ http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ304
- ^ there one instances of a static field per instantiation of a parameterized type?
- ^ Generics in C#, Java, and C++
- ^ JSR 14: http://www.jcp.org/en/jsr/detail?id=14
- ^ http://gafter.blogspot.com/2004/09/puzzling-through-erasure-answer.html
- ^ Java for Scientific Computation: Prospects and Problems
- ^ Richter, Jeffrey (April 2001). "An Introduction to Delegates". MSDN Magazine. http://msdn.microsoft.com/en-ca/magazine/cc301810.aspx. Retrieved 2008-12-23.
- ^ Campbell, Dustin (9 February 2007). "What's In A Closure?". Did it with .NET. http://diditwith.net/PermaLink,guid,235646ae-3476-4893-899d-105e4d48c25b.aspx. Retrieved 2008-12-23.
- ^ Mark Reinhold’s Blog: Plan B: The details [2] retrieved 21 November 2011
- ^ The Trouble with Checked Exceptions
- ^ Why doesn't C# have exception specifications?
- ^ O'Reilly, Tim (2006-08-02). "Programming Language Trends". Radar. O'Reilly. http://radar.oreilly.com/archives/2006/08/programming_language_trends_1.html.
- ^ i-Technology Viewpoint: Java's Not Evolving Fast Enough
- ^ Java 5 catches up with C#
- ^ JSR 14: Add Generic Types To The JavaTM Programming Language
- ^ Debate over closures for Java
- ^ Property Support in Java, the Java Way
- ^ CNET. "Sun, Microsoft settle Java suit". http://news.cnet.com/2100-1001-251401.html.
External links
- Moving to C# and the .NET Framework at MSDN
- C# and Java: Comparing Programming Languages at MSDN
- A Comparison of C# and Java
- 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)
.NET Framework Architecture CLI Languages Common1Other2Components Other implementations Comparisons - Java and C#
- C# and Visual Basic .NET
- Java and .NET platforms
Upcoming - "Jasper"
- "Roslyn"
Past - "Acropolis"
Tools 1 Languages that had been supported, is supported, or will be supported, in Visual Studio or .Net Framework.
2 Non-academic or research languages with relatively large user-bases.Java Java platform 
Sun technologies Platform technologies Major third-party technologies JRockit · GNU Classpath · Kaffe · TopLink · Apache Harmony · Apache Struts · Spring framework · Hibernate · JBoss application server · Tapestry · JazelleHistory Major programming languages Java conferences Categories:- Microsoft development tools
- Programming language comparisons
- Java programming language
- C programming language family
- Less verbose use of reflection: By casting an instance to the
Wikimedia Foundation. 2010.
