Comparison of C Sharp and Java

Expressions and operators

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 System.Object type. In Java this is not analogously true for java.lang.Object; 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 backward 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.

This difference has the following consequences. First of all, in C#, primitive types can define methods, such as an override of System.Object's ToString() method. In Java, this 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 while 42.ToString() performs the same operation in C#. This is because the latter one is an instance call on the primitive value 42, 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).

Statements

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 exist. 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 that specifies more keywords and more grammar rules than Java.

Keywords and backward compatibility

As the languages evolved, the language designers for both languages have faced situations where they wanted to extend the languages with new keywords 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 that were not legal before or to reuse existing keywords in new contexts. This way they didn't jeopardize backward compatibility. An example of the former can be found in how the for loop was extended to accept iterable types. An example of the latter can be found in how the extends and (especially) the super keywords were reused for specifying type bounds when generics were introduced in Java 1.5. At one time (Java 1.4) a new keyword assert was introduced that was not reserved as a keyword before. This had the potential to render formerly valid code invalid, if for instance the code used assert as an identifier. The designers chose to address this problem with a four-step solution: 1) Introducing a compiler switch that indicates if Java 1.4 or later should be used, 2) Only marking assert as a keyword when compiling as Java 1.4 and later, 3) Defaulting to 1.3 to avoid rendering prior (non 1.4 aware code) invalid and 4) Issue warnings, if the keyword is used in Java 1.3 mode, to allow changes in the code.

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 partial and yield keywords 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 backward compatible with source code written for any prior version without specifying the language version to be used.

Object-oriented programming

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.

Partial class

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 user interface (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, the instance of the embracing outer class must be named. This is done via a new new-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.

Event

C# multicast-delegates are used with events. Events provide support for event-driven programming and are 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.

Operator overloading and conversions

Operator overloading and user-defined casts are separate features that both aim to allow new types to become first-class citizens in the type system. By using these features in C#, types such as System.Numerics.Complex and decimal have been integrated so that the usual operators like addition and multiplication work with the new types. Unlike C++, C# does restrict the use of operator overloading, prohibiting it for the operators new, ( ), ||, &&, =, and any variations of compound statements like +=. But compound operators will call overloaded simple operators, like -= calling - and =.

Java does not include operator overloading, nor custom conversions to prevent abuse of the feature and to keep the language simple.

Indexer

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

<span id="mwBWE"></span><span class="n" id="mwBWI">myList</span><span class="p" id="mwBWM">[</span><span class="mi" id="mwBWQ">4</span><span class="p" id="mwBWU">]</span><span class="w" id="mwBWY"> </span><span class="o" id="mwBWc">=</span><span class="w" id="mwBWg"> </span><span class="mi" id="mwBWk">5</span><span class="p" id="mwBWo">;</span> <span class="kt" id="mwBWs">string</span><span class="w" id="mwBWw"> </span><span class="n" id="mwBW0">name</span><span class="w" id="mwBW4"> </span><span class="o" id="mwBW8">=</span><span class="w" id="mwBXA"> </span><span class="n" id="mwBXE">xmlNode</span><span class="p" id="mwBXI">.</span><span class="n" id="mwBXM">Attributes</span><span class="p" id="mwBXQ">[</span><span class="s" id="mwBXU">"name"</span><span class="p" id="mwBXY">];</span> <span class="n" id="mwBXc">orders</span><span class="w" id="mwBXg"> </span><span class="o" id="mwBXk">=</span><span class="w" id="mwBXo"> </span><span class="n" id="mwBXs">customerMap</span><span class="p" id="mwBXw">[</span><span class="n" id="mwBX0">customer</span><span class="p" id="mwBX4">];</span>

Java does not include indexers. The common Java pattern involves writing explicit getters and setters where a C# programmer would use an indexer.

Fields and initialization

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 constructor but before the constructor is executed.

C# initializes object fields in the following order when creating an object:

1. Derived static fields
2. Derived static constructor
3. Derived instance fields
4. Base static fields
5. Base static constructor
6. Base instance fields
7. Base instance constructor
8. 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:

1. Invocation of another constructor (either of the object's class or of the object's superclass)
2. Instance variable initializers and instance initializers (in the order they appear in the source code)
3. 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 (that 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.

Resource disposal

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 must 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 that will automatically invoke the disposal/close methods on those interfaces.

Methods

Extension methods and default 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 must be declared static and defined within a purely static class. The method must obey any member access restriction like any other method external to the class; thus static methods cannot break object encapsulation. The "extension" is only active within scopes where the namespace of the static host class has been imported.

Since Java 8, Java has a similar feature called default methods, which are methods with a body declared on interfaces. As opposed to C# extension methods, Java default methods are instance methods on the interface that declare them. Definition of default methods in classes that implement the interface is optional: If the class does not define the method, the default definition is used instead.

Both the C# extension methods and the Java default methods allow a class to override the default implementation of the extension/default method, respectively. In both languages this override is achieved by defining a method on the class that should use an alternate implementation of the method.

C# scope rules defines that if a matching method is found on a class, it takes precedence over a matching extension method. In Java any class declared to implement an interface with default method is assumed to have the default methods implementations, unless the class implements the method itself.

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 several restrictions on the signature. The restrictions ensure that if a definition is not 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.

Virtual methods

Methods in C# are non-virtual by default, and must 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 Oracle 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 final modifier 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 is intended to override an inherited method, the override keyword must be specified. Otherwise, the method will "hide" the inherited method. If the keyword is absent, compiler warning to this effect is issued, which can be silenced by specifying the new keyword. This avoids the problem that can arise from a base class being extended with a non-private method (i.e. an inherited part of the namespace) whose signature is already in use by a derived class. Java has a similar compiler check in the form of the @Override method annotation, but it is not compulsory, and in its absence, most compilers will not provide comment (but the method will be overridden).

Constant/immutable parameters

In Java, it is possible to prevent reassignment of a local variable or method parameter by using the final keyword. Applying this keyword to a primitive type variable causes the variable to become immutable. However, applying final to a reference type variable only prevents that another object is assigned to it. It will not prevent the data contained by the object from being mutated. As of C#7, it is possible to prevent reassignment of a method parameter by using the in keyword, however this keyword cannot be used on local variables. As with Java, applying in to a parameter only prevents the parameter from being reassigned to a different value. It is still possible to mutate the data contained by the object.

Both languages do not support essential feature of const-correctness that exists in C/C++, which makes a method constant.

Java defines the word "constant" arbitrarily as a static final field; such constants are compile-time, and can be inlined by the compiler. As a convention, these variable names are capital-only with words separated with an underscore but the Java language doesn't insist on this. A parameter that is only final is not considered as a constant, although it may be so in the case of a primitive data type or an immutable class, like a java.lang.String.

C# supports the const keyword; this declares a compile-time static constant, similar to constexpr in C and C++. Java reserves the const keyword, but it remains unused.

Generator methods

Any C# method declared as returning System.Collections.IEnumerable, System.Collections.IEnumerator or the generic versions of these interfaces can be implemented using yield syntax. This is a form of limited, compiler-generated continuations and can drastically reduce the code needed 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.

See also example Fibonacci sequence below.

Explicit interface implementation

C# also has explicit interface implementation that 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.

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 that implements those interfaces. An implementation will by default implement a common method for all of the interfaces. If separate implementations are needed (because the methods 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 refactoring one or more of the interfaces to avoid name clashes.

Reference (in/out) parameters

The arguments of primitive types (e.g. int, double) to a method are passed by value in Java whereas objects are passed by reference. This means that a method operates on copies of the primitives passed to it instead of on the actual variables. On the contrary, the actual objects in some cases can be changed.

In C#, it is possible to enforce a reference with the ref keyword, similar to C++ and in a sense to C. This feature of C# is particularly useful when one wants to create a method that returns more than one object. In Java trying to return multiple values from a method is unsupported unless a wrapper is used, in this case named "Ref".

Exceptions

Checked exceptions

Java supports checked exceptions (along with 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/catch block.

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.

One criticism is that checked exceptions encourage programmers to use an empty catch block (catch (Exception e) {} ), which silently swallows 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, an java.sql.SQLException could be caught and re-thrown as an java.io.IOException, since the caller may not need to know the inner workings of the object.

However, not all programmers agree with this stance. James Gosling and others maintain that checked exceptions are useful, and misusing them has caused the problems. Silently catching exceptions is possible, yes, but it must be stated explicitly what to do with the exception, versus unchecked exceptions that allow doing nothing by default. It can be ignored, but code must be written explicitly to ignore it.

Try-catch-finally

There are also differences between the two languages in treating the try/finally statement. The finally block 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 afterward 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, thus guaranteeing the release of precious resources in the finally block. C# features the using statement as a syntactic shorthand for this common scenario, in which the IDisposable.Dispose() method of the object of the using is 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.

<span id="mwCT4"></span><span class="kd" id="mwCT8">class</span> <span class="nc" id="mwCUA">Foo</span><span class="w" id="mwCUE"> </span><span class="p" id="mwCUI">{</span> <span class="w" id="mwCUM"> </span><span class="n" id="mwCUQ">Exception</span><span class="w" id="mwCUU"> </span><span class="n" id="mwCUY">e</span><span class="w" id="mwCUc"> </span><span class="o" id="mwCUg">=</span><span class="w" id="mwCUk"> </span><span class="k" id="mwCUo">new</span><span class="w" id="mwCUs"> </span><span class="n" id="mwCUw">Exception</span><span class="p" id="mwCU0">();</span> <span class="w" id="mwCU4"> </span><span class="kt" id="mwCU8">int</span><span class="w" id="mwCVA"> </span><span class="nf" id="mwCVE">foo</span><span class="p" id="mwCVI">()</span><span class="w" id="mwCVM"> </span><span class="kd" id="mwCVQ">throws</span><span class="w" id="mwCVU"> </span><span class="n" id="mwCVY">Exception</span><span class="w" id="mwCVc"> </span><span class="p" id="mwCVg">{</span> <span class="w" id="mwCVk"> </span><span class="k" id="mwCVo">throw</span><span class="w" id="mwCVs"> </span><span class="n" id="mwCVw">e</span><span class="p" id="mwCV0">;</span> <span class="w" id="mwCV4"> </span><span class="p" id="mwCV8">}</span> <span class="p" id="mwCWA">}</span>

The exception in the statement above will always contain the constructor's stacktrace, no matter how often foo() is called. On the other hand, in C#, the stacktrace is created the moment throw is reached.

<span id="mwCWY"></span><span class="k" id="mwCWc">using</span><span class="w" id="mwCWg"> </span><span class="nn" id="mwCWk">System</span><span class="p" id="mwCWo">;</span> <span class="k" id="mwCWs">class</span><span class="w" id="mwCWw"> </span><span class="nc" id="mwCW0">Foo</span> <span class="p" id="mwCW4">{</span> <span class="w" id="mwCW8"> </span><span class="n" id="mwCXA">Exception</span><span class="w" id="mwCXE"> </span><span class="n" id="mwCXI">e</span><span class="w" id="mwCXM"> </span><span class="o" id="mwCXQ">=</span><span class="w" id="mwCXU"> </span><span class="k" id="mwCXY">new</span><span class="p" id="mwCXc">();</span> <span class="w" id="mwCXg"> </span><span class="kt" id="mwCXk">int</span><span class="w" id="mwCXo"> </span><span class="nf" id="mwCXs">Foo</span><span class="p" id="mwCXw">()</span> <span class="w" id="mwCX0"> </span><span class="p" id="mwCX4">{</span> <span class="w" id="mwCX8"> </span><span class="k" id="mwCYA">try</span> <span class="w" id="mwCYE"> </span><span class="p" id="mwCYI">{</span> <span class="w" id="mwCYM"> </span><span class="k" id="mwCYQ">throw</span><span class="w" id="mwCYU"> </span><span class="n" id="mwCYY">e</span><span class="p" id="mwCYc">;</span> <span class="w" id="mwCYg"> </span><span class="p" id="mwCYk">}</span> <span class="w" id="mwCYo"> </span><span class="k" id="mwCYs">catch</span><span class="w" id="mwCYw"> </span><span class="p" id="mwCY0">(</span><span class="n" id="mwCY4">Exception</span><span class="w" id="mwCY8"> </span><span class="n" id="mwCZA">e</span><span class="p" id="mwCZE">)</span> <span class="w" id="mwCZI"> </span><span class="p" id="mwCZM">{</span> <span class="w" id="mwCZQ"> </span><span class="k" id="mwCZU">throw</span><span class="p" id="mwCZY">;</span> <span class="w" id="mwCZc"> </span><span class="p" id="mwCZg">}</span> <span class="w" id="mwCZk"> </span><span class="p" id="mwCZo">}</span> <span class="p" id="mwCZs">}</span>

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: throw will just rethrow the original exception with the original stack, while throw e; would have created a new stack trace.

Finally blocks

Java allows flow of control to leave the finally block of a try statement, regardless of the way it was entered. This can cause another control flow statement (such as return) to be terminated mid-execution. For example:

<span id="mwCaY"></span><span class="kt" id="mwCac">int</span><span class="w" id="mwCag"> </span><span class="nf" id="mwCak">foo</span><span class="p" id="mwCao">()</span><span class="w" id="mwCas"> </span><span class="p" id="mwCaw">{</span> <span class="w" id="mwCa0"> </span><span class="k" id="mwCa4">try</span><span class="w" id="mwCa8"> </span><span class="p" id="mwCbA">{</span> <span class="w" id="mwCbE"> </span><span class="k" id="mwCbI">return</span><span class="w" id="mwCbM"> </span><span class="mi" id="mwCbQ">0</span><span class="p" id="mwCbU">;</span> <span class="w" id="mwCbY"> </span><span class="p" id="mwCbc">}</span><span class="w" id="mwCbg"> </span><span class="k" id="mwCbk">finally</span><span class="w" id="mwCbo"> </span><span class="p" id="mwCbs">{</span> <span class="w" id="mwCbw"> </span><span class="k" id="mwCb0">return</span><span class="w" id="mwCb4"> </span><span class="mi" id="mwCb8">1</span><span class="p" id="mwCcA">;</span> <span class="w" id="mwCcE"> </span><span class="p" id="mwCcI">}</span> <span class="p" id="mwCcM">}</span>

In the above code, the return statement within the try block causes control to leave it, and thus finally block is executed before the actual return happens. However, the finally block itself also performs a return. Thus, the original return that caused it to be entered is not executed, and the above method returns 1 rather than 0. Informally speaking, it tries to return 0 but finally returns 1.

C# does not allow any statements that allow control flow to leave the finally block prematurely, except for throw. In particular, return is not allowed at all, goto is not allowed if the target label is outside the finally block, and continue and break are not allowed if the nearest enclosing loop is outside the finally block.

Generics

In 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 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 Java virtual machine (JVM). Instead, generics classes and methods are transformed during compiling via a process termed type erasure. During this, 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 Java 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. Research into adding reified generics to the Java platform is ongoing, as part of Project Valhalla.

C# builds on support for generics from the virtual execution system, 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 compiling generics are verified for correctness, but code generation to implement 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 one type, as reference types can safely share the same implementations. This is merely for the purpose of 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:

C# allows generics directly for primitive types. Java, instead, allows the use of boxed types as type parameters (e.g., List<Integer> instead of List<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 example List<int[]> is allowed. Several third-party libraries implemented the basic collections in Java with backing primitive arrays to preserve the runtime and memory optimization that primitive types provide.

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". This was designed so that any new generic collections should be passable to methods that expected one of the pre-existing collection classes.

C# generics were introduced into the language while preserving full backward 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 that 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

Covariance and contravariance is supported by both languages. Java has use-site variance that 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 unsupported directly on classes but is supported through their implementation of variant interfaces. C# also has use-site covariance support for methods and delegates.

Functional programming

Closures

A closure is an inline function that captures variables from its lexical scope.

C# supports closures as anonymous methods or lambda expressions with full-featured closure semantics.

In Java, anonymous inner classes will remain the preferred way to emulate closures until Java 8 has become the new standard. This is a more verbose construction. This approach also has some differences compared to real closures, notably more controlled access to variables from the enclosing scopes: only final members can be referenced. Java 8, however introduces lambdas that fully inherit the current scope and, in fact, do not introduce a new scope.

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 access 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 mark which variables to make available, and in what state (possibly requiring boxing).

Lambdas and expression trees

C# and Java feature 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.

C#, unlike Java, allows the use of lambda functions 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 Language Integrated Query (LINQ).

Metadata

Preprocessing, compilation and packaging

Namespaces and file contents

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 have a feature to "import" a type into scope (e.g., import java.util.* in Java, using System; in C#), allowing a class to be referenced using only its name. (Note that import in Java and using in C# merely adds the type into scope; it does not "import" a class/assembly.) 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# does not, only allowing entire namespaces to be imported. C# allows aliasing classes under a new local name using the following syntax: using SysConsole = System.Console. It also allows aliasing types in the form of using IntList = System.Collections.Generic.List<int> (similar to C++'s using IntList = std::vector<int>).

Both languages have 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. C# 2.0 and later allows splitting a class definition into several files by using the partial keyword 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.

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.

Threading and asynchronous features

Both languages include thread synchronization mechanisms as part of their language syntax.

Task-based parallelism for C#

With .NET Framework 4.0, a new task-based programming model was introduced to replace the existing event-based asynchronous model. The API is based around the System.Threading.Tasks.Task and System.Threading.Tasks.Task<T> classes. Tasks can be composed and chained.

By convention, every method that returns a System.Threading.Tasks.Task should have its name postfixed with Async.

<span id="mwDIA"></span><span class="k" id="mwDIE">using</span><span class="w" id="mwDII"> </span><span class="nn" id="mwDIM">System.Threading.Tasks</span><span class="p" id="mwDIQ">;</span> <span class="k" id="mwDIU">public</span><span class="w" id="mwDIY"> </span><span class="k" id="mwDIc">static</span><span class="w" id="mwDIg"> </span><span class="k" id="mwDIk">class</span><span class="w" id="mwDIo"> </span><span class="nc" id="mwDIs">SomeAsyncCode</span> <span class="p" id="mwDIw">{</span> <span class="w" id="mwDI0"> </span><span class="k" id="mwDI4">public</span><span class="w" id="mwDI8"> </span><span class="k" id="mwDJA">static</span><span class="w" id="mwDJE"> </span><span class="n" id="mwDJI">Task</span><span class="o" id="mwDJM"><</span><span class="n" id="mwDJQ">XDocument</span><span class="o" id="mwDJU">></span><span class="w" id="mwDJY"> </span><span class="n" id="mwDJc">GetContentAsync</span><span class="p" id="mwDJg">()</span> <span class="w" id="mwDJk"> </span><span class="p" id="mwDJo">{</span> <span class="w" id="mwDJs"> </span><span class="n" id="mwDJw">HttpClient</span><span class="w" id="mwDJ0"> </span><span class="n" id="mwDJ4">httpClient</span><span class="w" id="mwDJ8"> </span><span class="o" id="mwDKA">=</span><span class="w" id="mwDKE"> </span><span class="k" id="mwDKI">new</span><span class="p" id="mwDKM">();</span> <span class="w" id="mwDKQ"> </span><span class="k" id="mwDKU">return</span><span class="w" id="mwDKY"> </span><span class="n" id="mwDKc">httpClient</span><span class="p" id="mwDKg">.</span><span class="n" id="mwDKk">GetStringAsync</span><span class="p" id="mwDKo">(</span><span class="s" id="mwDKs">"www.contoso.com"</span><span class="p" id="mwDKw">).</span><span class="n" id="mwDK0">ContinueWith</span><span class="p" id="mwDK4">((</span><span class="n" id="mwDK8">task</span><span class="p" id="mwDLA">)</span><span class="w" id="mwDLE"> </span><span class="o" id="mwDLI">=></span><span class="w" id="mwDLM"> </span><span class="p" id="mwDLQ">{</span> <span class="w" id="mwDLU"> </span><span class="kt" id="mwDLY">string</span><span class="w" id="mwDLc"> </span><span class="n" id="mwDLg">responseBodyAsText</span><span class="w" id="mwDLk"> </span><span class="o" id="mwDLo">=</span><span class="w" id="mwDLs"> </span><span class="n" id="mwDLw">task</span><span class="p" id="mwDL0">.</span><span class="n" id="mwDL4">Result</span><span class="p" id="mwDL8">;</span> <span class="w" id="mwDMA"> </span><span class="k" id="mwDME">return</span><span class="w" id="mwDMI"> </span><span class="n" id="mwDMM">XDocument</span><span class="p" id="mwDMQ">.</span><span class="n" id="mwDMU">Parse</span><span class="p" id="mwDMY">(</span><span class="n" id="mwDMc">responseBodyAsText</span><span class="p" id="mwDMg">);</span> <span class="w" id="mwDMk"> </span><span class="p" id="mwDMo">});</span> <span class="w" id="mwDMs"> </span><span class="p" id="mwDMw">}</span> <span class="p" id="mwDM0">}</span> <span class="n" id="mwDM4">Task</span><span class="w" id="mwDM8"> </span><span class="n" id="mwDNA">t</span><span class="w" id="mwDNE"> </span><span class="o" id="mwDNI">=</span><span class="w" id="mwDNM"> </span><span class="n" id="mwDNQ">SomeAsyncCode</span><span class="p" id="mwDNU">.</span><span class="n" id="mwDNY">GetContentAsync</span><span class="p" id="mwDNc">().</span><span class="n" id="mwDNg">ContinueWith</span><span class="p" id="mwDNk">((</span><span class="n" id="mwDNo">task</span><span class="p" id="mwDNs">)</span><span class="w" id="mwDNw"> </span><span class="o" id="mwDN0">=></span><span class="w" id="mwDN4"> </span><span class="p" id="mwDN8">{</span> <span class="w" id="mwDOA"> </span><span class="n" id="mwDOE">XDocument</span><span class="w" id="mwDOI"> </span><span class="n" id="mwDOM">xmlDocument</span><span class="w" id="mwDOQ"> </span><span class="o" id="mwDOU">=</span><span class="w" id="mwDOY"> </span><span class="n" id="mwDOc">task</span><span class="p" id="mwDOg">.</span><span class="n" id="mwDOk">Result</span><span class="p" id="mwDOo">;</span> <span class="p" id="mwDOs">});</span> <span class="n" id="mwDOw">t</span><span class="p" id="mwDO0">.</span><span class="n" id="mwDO4">Start</span><span class="p" id="mwDO8">();</span>

In C# 5 a set of language and compiler extensions was introduced to make it easier to work with the task model. These language extensions included the notion of async methods and the await statement that make the program flow appear synchronous.

<span id="mwDPU"></span><span class="k" id="mwDPY">using</span><span class="w" id="mwDPc"> </span><span class="nn" id="mwDPg">System.Threading.Tasks</span><span class="p" id="mwDPk">;</span> <span class="k" id="mwDPo">public</span><span class="w" id="mwDPs"> </span><span class="k" id="mwDPw">static</span><span class="w" id="mwDP0"> </span><span class="k" id="mwDP4">class</span><span class="w" id="mwDP8"> </span><span class="nc" id="mwDQA">SomeAsyncCode</span> <span class="p" id="mwDQE">{</span> <span class="w" id="mwDQI"> </span><span class="k" id="mwDQM">public</span><span class="w" id="mwDQQ"> </span><span class="k" id="mwDQU">static</span><span class="w" id="mwDQY"> </span><span class="k" id="mwDQc">async</span><span class="w" id="mwDQg"> </span><span class="n" id="mwDQk">Task</span><span class="o" id="mwDQo"><</span><span class="n" id="mwDQs">XDocument</span><span class="o" id="mwDQw">></span><span class="w" id="mwDQ0"> </span><span class="n" id="mwDQ4">GetContentAsync</span><span class="p" id="mwDQ8">()</span> <span class="w" id="mwDRA"> </span><span class="p" id="mwDRE">{</span> <span class="w" id="mwDRI"> </span><span class="n" id="mwDRM">HttpClient</span><span class="w" id="mwDRQ"> </span><span class="n" id="mwDRU">httpClient</span><span class="w" id="mwDRY"> </span><span class="o" id="mwDRc">=</span><span class="w" id="mwDRg"> </span><span class="k" id="mwDRk">new</span><span class="p" id="mwDRo">();</span> <span class="w" id="mwDRs"> </span><span class="kt" id="mwDRw">string</span><span class="w" id="mwDR0"> </span><span class="n" id="mwDR4">responseBodyAsText</span><span class="w" id="mwDR8"> </span><span class="o" id="mwDSA">=</span><span class="w" id="mwDSE"> </span><span class="k" id="mwDSI">await</span><span class="w" id="mwDSM"> </span><span class="n" id="mwDSQ">httpClient</span><span class="p" id="mwDSU">.</span><span class="n" id="mwDSY">GetStringAsync</span><span class="p" id="mwDSc">(</span><span class="s" id="mwDSg">"www.contoso.com"</span><span class="p" id="mwDSk">);</span> <span class="w" id="mwDSo"> </span><span class="k" id="mwDSs">return</span><span class="w" id="mwDSw"> </span><span class="n" id="mwDS0">XDocument</span><span class="p" id="mwDS4">.</span><span class="n" id="mwDS8">Parse</span><span class="p" id="mwDTA">(</span><span class="n" id="mwDTE">responseBodyAsText</span><span class="p" id="mwDTI">);</span> <span class="w" id="mwDTM"> </span><span class="p" id="mwDTQ">}</span> <span class="p" id="mwDTU">}</span> <span class="n" id="mwDTY">XDocument</span><span class="w" id="mwDTc"> </span><span class="n" id="mwDTg">xmlDocument</span><span class="w" id="mwDTk"> </span><span class="o" id="mwDTo">=</span><span class="w" id="mwDTs"> </span><span class="k" id="mwDTw">await</span><span class="w" id="mwDT0"> </span><span class="n" id="mwDT4">SomeAsyncCode</span><span class="p" id="mwDT8">.</span><span class="n" id="mwDUA">GetContentAsync</span><span class="p" id="mwDUE">();</span> <span class="c1" id="mwDUI">// The Task will be started on call with await.</span>

From this syntactic sugar the C# compiler generates a state-machine that handles the necessary continuations without developers having to think about it.

Task-based parallelism for Java

Java supports threads since JDK 1.0. Java offers a high versatility for running threads, often called tasks. This is done by implementing a functional interface (a java.lang.Runnable interface) defining a single void no-args method as demonstrated in the following example:

<span id="mwDUo"></span><span class="n" id="mwDUs">Thread</span><span class="w" id="mwDUw"> </span><span class="n" id="mwDU0">t</span><span class="w" id="mwDU4"> </span><span class="o" id="mwDU8">=</span><span class="w" id="mwDVA"> </span><span class="k" id="mwDVE">new</span><span class="w" id="mwDVI"> </span><span class="n" id="mwDVM">Thread</span><span class="p" id="mwDVQ">(()</span><span class="w" id="mwDVU"> </span><span class="o" id="mwDVY">-></span><span class="w" id="mwDVc"> </span><span class="p" id="mwDVg">{</span> <span class="w" id="mwDVk"> </span><span class="n" id="mwDVo">String</span><span class="w" id="mwDVs"> </span><span class="n" id="mwDVw">threadName</span><span class="w" id="mwDV0"> </span><span class="o" id="mwDV4">=</span><span class="w" id="mwDV8"> </span><span class="n" id="mwDWA">Thread</span><span class="p" id="mwDWE">.</span><span class="na" id="mwDWI">currentThread</span><span class="p" id="mwDWM">().</span><span class="na" id="mwDWQ">getName</span><span class="p" id="mwDWU">();</span> <span class="w" id="mwDWY"> </span><span class="n" id="mwDWc">System</span><span class="p" id="mwDWg">.</span><span class="na" id="mwDWk">out</span><span class="p" id="mwDWo">.</span><span class="na" id="mwDWs">println</span><span class="p" id="mwDWw">(</span><span class="s" id="mwDW0">"Hello "</span><span class="w" id="mwDW4"> </span><span class="o" id="mwDW8">+</span><span class="w" id="mwDXA"> </span><span class="n" id="mwDXE">threadName</span><span class="p" id="mwDXI">);</span> <span class="p" id="mwDXM">});</span> <span class="n" id="mwDXQ">myThread</span><span class="p" id="mwDXU">.</span><span class="na" id="mwDXY">start</span><span class="p" id="mwDXc">();</span>

Similar to C#, Java has a higher-level mechanism for working with threads. java.util.concurrent.Executors can execute asynchronous tasks and also manage a group of subprocesses. All the threads of a java.util.concurrent.ExecutorService instance are handled in a pool. This java.util.concurrent.ExecutorService instance will be reused under the hood for recurring tasks, so it is possible to run as many concurrent tasks as the programmer wants throughout the life-cycle of the application using a single java.util.concurrent.ExecutorService instance. Further, Java supports virtual threads, which are very lightweight threads that allow massive concurrency with no overhead of traditional platform threads, though they are used alongside the standard java.util.concurrent.ExecutorService model.

This is how the first thread-example looks using executors:

<span id="mwDYM"></span><span class="kn" id="mwDYQ">import</span><span class="w" id="mwDYU"> </span><span class="nn" id="mwDYY">java.util.concurrent.*</span><span class="p" id="mwDYc">;</span> <span class="n" id="mwDYg">ExecutorService</span><span class="w" id="mwDYk"> </span><span class="n" id="mwDYo">executor</span><span class="w" id="mwDYs"> </span><span class="o" id="mwDYw">=</span><span class="w" id="mwDY0"> </span><span class="n" id="mwDY4">Executors</span><span class="p" id="mwDY8">.</span><span class="na" id="mwDZA">newSingleThreadExecutor</span><span class="p" id="mwDZE">();</span> <span class="n" id="mwDZI">executor</span><span class="p" id="mwDZM">.</span><span class="na" id="mwDZQ">submit</span><span class="p" id="mwDZU">(()</span><span class="w" id="mwDZY"> </span><span class="o" id="mwDZc">-></span><span class="w" id="mwDZg"> </span><span class="p" id="mwDZk">{</span> <span class="w" id="mwDZo"> </span><span class="n" id="mwDZs">String</span><span class="w" id="mwDZw"> </span><span class="n" id="mwDZ0">threadName</span><span class="w" id="mwDZ4"> </span><span class="o" id="mwDZ8">=</span><span class="w" id="mwDaA"> </span><span class="n" id="mwDaE">Thread</span><span class="p" id="mwDaI">.</span><span class="na" id="mwDaM">currentThread</span><span class="p" id="mwDaQ">().</span><span class="na" id="mwDaU">getName</span><span class="p" id="mwDaY">();</span> <span class="w" id="mwDac"> </span><span class="n" id="mwDag">IO</span><span class="p" id="mwDak">.</span><span class="na" id="mwDao">println</span><span class="p" id="mwDas">(</span><span class="s" id="mwDaw">"Hello "</span><span class="w" id="mwDa0"> </span><span class="o" id="mwDa4">+</span><span class="w" id="mwDa8"> </span><span class="n" id="mwDbA">threadName</span><span class="p" id="mwDbE">);</span> <span class="p" id="mwDbI">});</span>

The java.util.concurrent.ExecutorService instance also supports a java.util.concurrent.Callable interface, another single method interface like java.lang.Runnable but the signature of the contained method of java.util.concurrent.Callable returns a value. In this way, the lambda expression must also return a value, like the below example of calling a website asynchronously as the C# example.

<span id="mwDbo"></span><span class="kn" id="mwDbs">import</span><span class="w" id="mwDbw"> </span><span class="nn" id="mwDb0">java.net.URI</span><span class="p" id="mwDb4">;</span> <span class="kn" id="mwDb8">import</span><span class="w" id="mwDcA"> </span><span class="nn" id="mwDcE">java.net.http.*</span><span class="p" id="mwDcI">;</span> <span class="kn" id="mwDcM">import</span><span class="w" id="mwDcQ"> </span><span class="nn" id="mwDcU">java.util.concurrent.*</span><span class="p" id="mwDcY">;</span> <span class="kd" id="mwDcc">class</span> <span class="nc" id="mwDcg">AsyncExample</span><span class="w" id="mwDck"> </span><span class="p" id="mwDco">{</span> <span class="w" id="mwDcs"> </span><span class="kd" id="mwDcw">public</span><span class="w" id="mwDc0"> </span><span class="kd" id="mwDc4">static</span><span class="w" id="mwDc8"> </span><span class="n" id="mwDdA">Future</span><span class="o" id="mwDdE"><</span><span class="n" id="mwDdI">String</span><span class="o" id="mwDdM">></span><span class="w" id="mwDdQ"> </span><span class="nf" id="mwDdU">getContentAsync</span><span class="p" id="mwDdY">()</span><span class="w" id="mwDdc"> </span><span class="p" id="mwDdg">{</span> <span class="w" id="mwDdk"> </span><span class="n" id="mwDdo">ExecutorService</span><span class="w" id="mwDds"> </span><span class="n" id="mwDdw">executor</span><span class="w" id="mwDd0"> </span><span class="o" id="mwDd4">=</span><span class="w" id="mwDd8"> </span><span class="n" id="mwDeA">Executors</span><span class="p" id="mwDeE">.</span><span class="na" id="mwDeI">newSingleThreadExecutor</span><span class="p" id="mwDeM">();</span> <span class="w" id="mwDeQ"> </span><span class="k" id="mwDeU">return</span><span class="w" id="mwDeY"> </span><span class="n" id="mwDec">executor</span><span class="p" id="mwDeg">.</span><span class="na" id="mwDek">submit</span><span class="p" id="mwDeo">(()</span><span class="w" id="mwDes"> </span><span class="o" id="mwDew">-></span><span class="w" id="mwDe0"> </span><span class="p" id="mwDe4">{</span><span class="w" id="mwDe8"> </span> <span class="w" id="mwDfA"> </span><span class="n" id="mwDfE">HttpRequest</span><span class="w" id="mwDfI"> </span><span class="n" id="mwDfM">httpReq</span><span class="w" id="mwDfQ"> </span><span class="o" id="mwDfU">=</span><span class="w" id="mwDfY"> </span><span class="n" id="mwDfc">HttpRequest</span><span class="p" id="mwDfg">.</span><span class="na" id="mwDfk">newBuilder</span><span class="p" id="mwDfo">()</span> <span class="w" id="mwDfs"> </span><span class="p" id="mwDfw">.</span><span class="na" id="mwDf0">uri</span><span class="p" id="mwDf4">(</span><span class="k" id="mwDf8">new</span><span class="w" id="mwDgA"> </span><span class="n" id="mwDgE">URI</span><span class="p" id="mwDgI">(</span><span class="s" id="mwDgM">"https://www.graalvm.org"</span><span class="p" id="mwDgQ">))</span> <span class="w" id="mwDgU"> </span><span class="p" id="mwDgY">.</span><span class="na" id="mwDgc">build</span><span class="p" id="mwDgg">();</span> <span class="w" id="mwDgk"> </span><span class="k" id="mwDgo">return</span><span class="w" id="mwDgs"> </span><span class="n" id="mwDgw">HttpClient</span><span class="p" id="mwDg0">.</span><span class="na" id="mwDg4">newHttpClient</span><span class="p" id="mwDg8">()</span> <span class="w" id="mwDhA"> </span><span class="p" id="mwDhE">.</span><span class="na" id="mwDhI">send</span><span class="p" id="mwDhM">(</span><span class="n" id="mwDhQ">httpReq</span><span class="p" id="mwDhU">,</span><span class="w" id="mwDhY"> </span><span class="n" id="mwDhc">HttpResponse</span><span class="p" id="mwDhg">.</span><span class="na" id="mwDhk">BodyHandlers</span><span class="p" id="mwDho">.</span><span class="na" id="mwDhs">ofString</span><span class="p" id="mwDhw">())</span> <span class="w" id="mwDh0"> </span><span class="p" id="mwDh4">.</span><span class="na" id="mwDh8">body</span><span class="p" id="mwDiA">();</span> <span class="w" id="mwDiE"> </span><span class="p" id="mwDiI">});</span> <span class="w" id="mwDiM"> </span><span class="p" id="mwDiQ">}</span> <span class="p" id="mwDiU">}</span> <span class="kt" id="mwDiY">void</span><span class="w" id="mwDic"> </span><span class="nf" id="mwDig">main</span><span class="p" id="mwDik">()</span><span class="w" id="mwDio"> </span><span class="p" id="mwDis">{</span> <span class="w" id="mwDiw"> </span><span class="n" id="mwDi0">String</span><span class="w" id="mwDi4"> </span><span class="n" id="mwDi8">webPageResult</span><span class="w" id="mwDjA"> </span><span class="o" id="mwDjE">=</span><span class="w" id="mwDjI"> </span><span class="n" id="mwDjM">AsyncExample</span><span class="p" id="mwDjQ">.</span><span class="na" id="mwDjU">getContentAsync</span><span class="p" id="mwDjY">().</span><span class="na" id="mwDjc">get</span><span class="p" id="mwDjg">();</span> <span class="w" id="mwDjk"> </span><span class="n" id="mwDjo">IO</span><span class="p" id="mwDjs">.</span><span class="na" id="mwDjw">println</span><span class="p" id="mwDj0">(</span><span class="n" id="mwDj4">webPageResult</span><span class="p" id="mwDj8">);</span> <span class="p" id="mwDkA">}</span>

Calling the method get() blocks the current thread and waits until the callable completes before returning the value (in the example, a web page content):

Further features

Numeric applications

To adequately support applications in the field of mathematical and financial computation, several language features exist.

Java once used the strictfp keyword to enable strict floating-point calculations for a region of code. Since Java 17, all floating point arithmetic is strict. C# allows an implementation for a given hardware architecture to always use a higher precision for intermediate results if available, i.e. C# does not allow the programmer to optionally force intermediate results to use the potential lower precision of single/double.

Although Java's floating-point arithmetic is largely based on IEEE 754 (Standard for Binary Floating-Point Arithmetic), certain features are unsupported even when using the strictfp modifier, such as Exception Flags and Directed Roundings, abilities mandated by IEEE Standard 754 (see Criticism of Java, Floating point arithmetic).

C# provides a built-in decimal type, which has higher precision (but less range) than the Java/C# double. The decimal type is a 128-bit data type suitable for financial and monetary calculations. The decimal type can represent values ranging from 1.0 × 10⁻²⁸ to approximately 7.9 × 10²⁸ with 28–29 significant digits. The structure uses C# operator overloading so that decimals can be manipulated using operators such as +, -, * and /, like other primitive data types.

Java's java.math.BigDecimal and java.math.BigInteger allow arbitrary-precision representation of decimal numbers and integer numbers, respectively. Java standard library does not have classes to deal with complex numbers.

C#'s System.Numerics.BigInteger, and System.Numerics.Complex allow representation and manipulation of arbitrary-precision integers and complex numbers, respectively. The structures use C# operator overloading so that instances can be manipulated using operators such as +, -, *, and /, like other primitive data types. C# standard library does not have classes to deal with arbitrary-precision floating point numbers (see software for arbitrary-precision arithmetic).

C# can help mathematical applications with the checked and unchecked operators that allow the enabling or disabling of run-time checking for arithmetic overflow for a region of code.

Language integrated query (LINQ)

C#s Language Integrated Query (LINQ) is a set of features designed to work together to allow in-language querying abilities and is a distinguishing feature between C# and Java.

LINQ consists of these 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 an abstract 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 that may lead to a result type that 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 that support nullable types, like e.g. SQL.

Native interoperability

The Java platform provides several mechanisms for interoperating with native code. The most recent addition is the Foreign Function and Memory API (FFM API), developed under Project Panama, which offers a standardized, safer, and more efficient approach for calling native functions and accessing native memory without relying on the Java Native Interface (JNI). The FFM API reduces overhead and eliminates much of the boilerplate traditionally associated with JNI while enabling closer-to-native performance and preserving safety and lifetime guarantees.

Historically, JNI has been the primary mechanism for native interoperability in Java and remains widely used in existing codebases.

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 Component Object Model (COM) bridging, e.g., JACOB (Free software) and J-Integra for COM (Proprietary software).

Native code typically resides in a library, which Java can interoperate with via these mechanisms.

.NET Platform Invoke (P/Invoke) offers the same ability by allowing calls from C# to what Microsoft terms unmanaged code. Through metadata attributes the programmer can control exactly how the parameters and results are marshalled, thus avoiding the external glue code needed by the equivalent JNI in Java. 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 first-class .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 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. 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) and a common set of libraries. The JRE was originally designed to support interpreted execution with final compiling 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.

C# 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.

Examples

Input/output

Example illustrating how to copy text one line at a time from one file to another, using both languages.

Integration of library-defined types

C# allows library-defined types to be integrated with existing types and operators by using custom implicit/explicit conversions and operator overloading as illustrated by the following example:

C# delegates and equivalent Java constructs

Type lifting

Java lacks nullable types (T?), like C# has, but can emulate them with java.util.Optional<T>.

Interoperability with dynamic languages

This example illustrates how Java and C# can be used to create and invoke an instance of class that is implemented in another programming language. The "Deepthought" class is implemented using the Ruby programming language and represents a simple calculator that will multiply two input values (a and b) when the Calculate method is invoked. In addition to the conventional way, Java has GraalVM, a virtual machine capable to run any implemented programming language.

Fibonacci sequence

This example illustrates how the Fibonacci sequence can be implemented using the two languages. The C# version takes advantage of C# generator methods. The Java version takes the advantage of Stream interface and method references. Both the Java and the C# examples use K&R style for code formatting of classes, methods and statements.