Unified type system

Both languages are statically typed with class-based object orientation. 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. C# has a unified type system in which all types (besides unsafe pointers^[17]) ultimately derive from a common root type. Consequently, all types implement the methods of this root type, and extension methods defined for the object type apply to all types, even primitive int literals and delegates. This allows C#, unlike Java, to support objects with encapsulation that 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.

Both languages support many built-in types that 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 primitive/simple types typically have native support from the underlying processor architecture.

The C# simple types implement several interfaces and consequently offer many methods directly on instances of the types, even on the literals. The C# type names are also merely aliases for Common Language Runtime (CLR) types. The C# System.Int64 type is exactly the same type as the long type; 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 primitive types. Instead, methods that operate on primitive values are offered through companion primitive 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 Long type is a reference type that wraps the primitive long type. They are not the same type, however.

Data types

User-defined value type (struct)

C# allows the programmer to create user-defined value types, using the struct keyword. 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 several interfaces.

Apart from the built-in primitive types, Java does not include the concept of value types.

Enumerations

Both languages define enumerations, but they are implemented in fundamentally different ways. As such, enumerations are one area where tools designed to automatically translate code between the two languages (such as Java to C# converters) fail.

C# has implemented enumerations in a manner similar to C, that is as wrappers around the bit-flags implemented in primitive integral types (int, byte, short, etc.). This has performance benefits and improves interaction with C/C++ compiled code, but provides fewer features and can lead to bugs if low-level value types are directly cast to an enumeration type, as is allowed in the C# language. Therefore, it is seen as syntactic sugar.^[26] In contrast, Java implements enumerations as full featured collection of instances, requiring more memory and not aiding interaction with C/C++ code, but providing additional features in reflection and intrinsic behavior. The implementation in each language is described in the table below.

In both C# and Java, programmers can use enumerations in a switch statement without conversion to a string or primitive integer type. However, C# disallows implicit fall-through unless the case statement does not contain any code, as it is a common cause of hard-to-find bugs.^[29] Fall-through must be explicitly declared using a goto statement.^[30]

Delegates, method references

C# implements object-oriented method pointers in the form of delegates. A delegate is a special type that can capture a 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.^[31] Instead, alternative mechanisms are used. The wrapper pattern, which resembles the delegates of C# in that it allows the client to access one or more client-defined methods through a known interface, is one such mechanism. Another is the use of adapter objects using inner classes, which the designers of Java argued are a better solution than bound method references.^[31]

See also example C# delegates and equivalent Java constructs.

Lifted (nullable) types

C# allows value/primitive/simple types to be "lifted" to allow the special null value in addition to the type's native values. A type is lifted by adding a ? suffix to the type name; this is equivalent to using the Nullable<T> generic type, where T is the type to be lifted. Conversions are implicitly defined to convert between values of the base and the lifted type. The lifted type can be compared against null or it can be tested for HasValue. 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 null value 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 there is no object to be unboxed – and thus no boxed value to take part in the subsequent computation.

The following example illustrates the different behavior. In C#, the lifted*operator propagates the null value of the operand; in Java, unboxing the null reference throws an exception.

Not all C# lifted operators have been defined to propagate null unconditionally, if one of the operands is null. 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 that supports no-reflection dynamic invocation, interoperability with dynamic languages, and ad-hoc binding to (for example) document object models. The dynamic type 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 dynamic type in C#:

• Less verbose use of reflection: By casting an instance to the dynamic type, 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 must be used. The Java virtual machine platform does have multiple dynamic languages implemented on it, but there is no common standard for how to pass objects between languages. Usually this involves some form of reflection or reflection-like API. As an example of how to use JavaFX objects from Java.^[32]
• For creating and interacting with objects entirely at runtime, e.g., interaction with a document object model abstraction, a specific abstraction API must be used.

See also example #Interoperability with dynamic languages.

Pointers

Java precludes pointers and pointer-arithmetic within the Java runtime environment. The Java language designers reasoned that pointers are one of the main features that enable programmers to put bugs in their code and chose not to support them.^[9] Java does not allow for directly passing and receiving objects/structures to/from the underlying operating system and thus does not need to model objects/structures to such a specific memory layout, layouts that frequently would involve pointers. Java's communication with the underlying operating system is instead based upon Java Native Interface (JNI) where communication with/adaptation to an underlying operating system is handled through an external glue layer.

While C# does allow use of pointers and corresponding pointer arithmetic, the C# language designers had the same concerns that pointers could potentially be used to bypass the strict rules for object access. Thus, C# by default also precludes pointers.^[33] However, because pointers are needed when calling many native functions, pointers are allowed in an explicit unsafe mode. Code blocks or methods that use the pointers must be marked with the unsafe keyword to be able to use pointers, and the compiler requires the /unsafe switch to allow compiling such code. Assemblies that are compiled using the /unsafe switch are marked as such and may only execute if explicitly trusted. This allows using pointers and pointer arithmetic to directly pass and receive objects to/from the operating system or other native APIs using the native memory layout for those objects while also isolating such potentially unsafe code in specifically trusted assemblies.

Reference types

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 that 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.

Along with weak references, Java has soft references. They are much like weak references, but the JVM will not deallocate softly-referenced objects until the memory is needed.

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.

Multidimensional arrays can in some cases increase performance because of increased locality (as there is one pointer dereference instead of one for every dimension of the array, as it 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 difference 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. However, Java provides a syntactic construct for allocating a 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 that includes various ordered and unordered types of lists, maps/dictionaries, sets, etc.

Tuples

C# provides two different methods for creating tuple types (also known as product types). The first is via the System.Tuple classes, which are immutable reference types provided by the framework API (starting with .NET Framework 4.0) for creating generic tuple types.^[14] This first method has since been effectively superseded by the second, the System.ValueTuple structs, which are mutable value types provided by the framework API (starting with .NET Framework 4.7).^[15]

While the two methods seem superficially similar, they have multiple notable differences. The ValueTuple types are value types, so they have a more compact memory footprint; also, the ValueTuple types expose their contents as mutable fields, compared to the immutable properties of the Tuple classes. Finally, since C# version 7.0, the language has native syntactical support for the construction, deconstruction, and manipulation of tuples as ValueTuple instances; this also provides for the arbitrary renaming of the tuples' constituent fields (as opposed to Tuple, where the fields are always named Item1, Item2, etc.).

Java does not provide tuple types as part of its language or standard API; numerous third-party libraries exist which can provide tuple types,^[41] but they all are necessarily similar to the C# System.Tuple classes. In comparison to C# ValueTuple types and their associated syntax, they are more unwieldy to use (requiring the explicit use of constructors or static factory methods for creating them, requiring individual member access to deconstruct them, and having fixed names for their elements).

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 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.^[46]

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 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).

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 previously 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 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.

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 previous version without specifying the language version to 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;
    // ...
}

public int readItem() throws java.io.IOException {
    // ...
}

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

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
}

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.^[53] 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 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 =.^[54]

Java does not include operator overloading, nor custom conversions in order to prevent abuse of the feature and to keep the language simple.^[55]

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:

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.

Fields and initialization

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

public int addOne(final int x) {
    x++; // ERROR: a final variable cannot be reassigned
    return x;
}

public List addOne(final List<Integer> list) {
    list.add(1); // OK: it is still possible to modify a
                 // final (reference type) variable
    return list;
}

public int AddOne(in int x) 
{
    x++; // ERROR: a readonly parameter cannot be reassigned
    return x;
}

public List<int> AddOne(in List<int> list) 
{
    list.Add(1); // OK: it is still possible to modify a
                 // readonly (reference type) parameter
    return list;
}

class PassByRefTest {

    static class Ref<T> {
        T val;
        Ref(T val) { this.val = val; }
    }
    
    static void changeMe(Ref<String> s) {
        s.val = "Changed";
    }

    static void swap(Ref<Integer> x, Ref<Integer> y) {
        int temp = x.val;

        x.val = y.val;
        y.val = temp;
    }

    public static void main(String[] args) {
        var a = new Ref(5);
        var b = new Ref(10);
        var s = new Ref("still unchanged");
        
        swap(a, b);
        changeMe(s);

        System.out.println( "a = " + a.val + ", " +
                            "b = " + b.val + ", " +
                            "s = " + s.val );
    }
}

class PassByRefTest 
{
    public static void ChangeMe(out string s) 
    {
        s = "Changed";
    }

    public static void Swap(ref int x, ref int y) 
    {
        int temp = x;

        x = y;
        y = temp;
    }

    public static void Main(string[] args) 
    {
        int a = 5;
        int b = 10;
        string s = "still unchanged";

        Swap(ref a, ref b);
        ChangeMe(out s);

        System.Console.WriteLine("a = " + a + ", " +
                                 "b = " + b + ", " +
                                 "s = " + s);
    }
}

Exceptions

class Foo {
    Exception up = new Exception();
    int foo() throws Exception {
        throw up;
    }
}

class Foo
{
    Exception e = new Exception();

    int foo()
    {
        try
        {
            throw e;
        }
        catch (Exception e)
        {
            throw;
        }
    }
}

int foo() {
    try {
        return 0;
    } finally {
        return 1;
    }
}

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 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.^[72] 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:^[73]

Pair<String, String>[] tenPairs = new Pair[10]; //OK

object tenPairs = new Pair<int, string>[10]; // OK

public class Lookup<K, V> {
    public V[] getEmptyValues(K key) {
        return (V[]) new Object[0]; // OK
    }
}

public class Lookup<K, V extends Comparable<V>> {
    public V[] getEmptyValues(K key) {
        return (V[]) new Comparable[0];
    }
}

public class Lookup<K, V>
{
    public V[] GetEmptyValues(K key)
    {
        return new V[0]; // OK
    }
}

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.^[78] 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.^[79]

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

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.

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.^[84][85]

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).

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

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.

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 Task and Task<T> classes. Tasks can be composed and chained.

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

public static class SomeAsyncCode
{
    public static Task<XDocument> GetContentAsync()
    {
        HttpClient httpClient = new HttpClient();
        return httpClient.GetStringAsync("www.contoso.com").ContinueWith((task) => {
            string responseBodyAsText = task.Result;
            return XDocument.Parse(responseBodyAsText);
        });
    }
}

var t = SomeAsyncCode.GetContentAsync().ContinueWith((task) => {
    var xmlDocument = task.Result;
});

t.Start();

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.

public static class SomeAsyncCode
{
    public static async Task<XDocument> GetContentAsync()
    {
        HttpClient httpClient = new HttpClient();
        string responseBodyAsText = await httpClient.GetStringAsync("www.contoso.com");
        return XDocument.Parse(responseBodyAsText);
    }
}

var xmlDocument = await SomeAsyncCode.GetContentAsync();

// The Task will be started on call with await.

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:

var myThread = new Thread(() -> {
    var threadName = Thread.currentThread().getName();
    System.out.println("Hello " + threadName);
});

myThread.start();

Similar to C#, Java has a higher level mechanism for working with threads. Executors can execute asynchronous tasks and also manage a group of subprocesses. All the threads of an ExecutorServices instance are handled in a pool. This ExecutorService instance will be reused under the hood for revenant tasks, so it's possible runs as many concurrent tasks as the programmer wants throughout the life-cycle of the application using a single executor service instance.

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

ExecutorService executor = Executors.newSingleThreadExecutor();

executor.submit(() -> {
    var threadName = Thread.currentThread().getName();
    System.out.println("Hello " + threadName);
});

The ExecutorService instance also supports a Callable interface, another single method interface like Runnable but the signature of the contained method of 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.

ExecutorService executor = Executors.newSingleThreadExecutor();

Future<String> contentAsync = executor.submit(() -> {           
    HttpRequest httpReq = HttpRequest.newBuilder()
        .uri(new URI("www.graalvm.org"))
        .build();
            
    return HttpClient.newHttpClient()
        .send(httpReq, BodyHandlers.ofString())
        .body();
});
   
var webPageResult = contentAsync.get();

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):

The following example, a method and a class are used. This wrap it's just to be similar to the C# example since Java does not have keywords like async for the method signature.

public static class SomeAsyncCode {

    static ExecutorService executor = Executors.newSingleThreadExecutor();

    public static Future<String> getContentAsync(){
        return executor.submit(() -> {           
            HttpRequest httpReq = HttpRequest.newBuilder()
                .uri(new URI("www.graalvm.org"))
                .build();
            return HttpClient.newHttpClient()
                .send(httpReq, BodyHandlers.ofString())
                .body();
        });
    }
}

var webPageResult = SomeAsyncCode.getContentAsync().get();

Numeric applications

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

Java's strictfp keyword enables strict floating-point calculations for a region of code. Strict floating-point calculations require that even if a platform offers higher precision during calculations, intermediate results must be converted to single/double. This ensures that strict floating-point calculations return exactly the same result on all platforms. Without strict floating-point, a platform implementation is free to use higher precision for intermediate results during calculation. 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.^[93]

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,^[94] 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.^[95] The structure uses C# operator overloading so that decimals can be manipulated using operators such as +, -,*and /, like other primitive data types.

The BigDecimal and BigInteger types provided with Java allow arbitrary-precision representation of decimal numbers and integer numbers, respectively. Java standard library does not have classes to deal with complex numbers.

The BigInteger,^[3] and Complex^[96] types provided with C# 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 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 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 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 Java-Component Object Model (COM) bridging, e.g., JACOB (free), and J-Integra for COM (proprietary).

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

Input/output

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

import java.nio.file.*;

class FileIOTest {

    public static void main(String[] args) throws Exception {
        var lines = Files.readAllLines(Paths.get("input.txt"));
        Files.write(Paths.get("output.txt"), lines);
    }
}

using System.IO;

class FileIOTest
{
    public static void Main(string[] args)
    {
        var lines = File.ReadLines("input.txt");
        File.WriteAllLines("output.txt", lines);
    }
}

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:

var bigNumber =
    new BigInteger("123456789012345678901234567890");

var answer = bigNumber.multiply(BigInteger.valueOf(42));
var square = bigNumber.sqrt();
var sum = bigNumber.add(bigNumber);

var bigNumber =
    BigInteger.Parse("123456789012345678901234567890");

var answer = bigNumber * 42;
var square = bigNumber * bigNumber;
var sum = bigNumber + bigNumber;

C# delegates and equivalent Java constructs

// a target class
class Target {
    public boolean targetMethod(String arg) {
        // do something
        return true;
    }
}

// usage
void doSomething() {
    // construct a target with the target method
    var target = new Target();

    // capture the method reference
    Function<String, Boolean> ivk = target::targetMethod;

    // invokes the referenced method
    var result = ivk.apply("argumentstring");
}

    // 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
        Func<string, bool> dlg = target.TargetMethod;

        // invoke the delegate
        bool result = dlg("argumentstring");
    }

Type lifting

var a = Optional.of(42);
var b = Optional.<Integer>empty();

var c = a.flatMap(aa -> b.map(bb -> aa * bb));

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;

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.

Context polyglot = Context.newBuilder().allowAllAccess(true).build();

//Ruby
Value rubyArray = polyglot.eval("ruby", "[1,2,42,4]");
int rubyResult = rubyArray.getArrayElement(2).asInt();

//Python
Value pythonArray = context.eval("python", "[1,2,42,4]");
int pythonResult = pythonArray.getArrayElement(2).asInt();

//JavaScript
Value jsArray = polyglot.eval("js", "[1,2,42,4]");
int jsResult = jsArray.getArrayElement(2).asInt();

//R
Value rArray = polyglot.eval("R", "c(1,2,42,4)");
int rResult = rArray.getArrayElement(2).asInt();

//LLVM (in this case C, but could be C++, Go, Basic, etc...)
Source source = Source.newBuilder("llvm", new File("C_Program.bc")).build();
Value cpart = polyglot.eval(source);
cpart.getMember("main").execute();

// Initialize the engine
var invocable = new ScriptEngineManager().getEngineByName("jruby");
var rubyFile = new FileReader("Deepthought.rb");
engine.eval(fr);

// Initialize the engine

var runtime = ScriptRuntime.CreateFromConfiguration();
dynamic globals = runtime.Globals;

runtime.ExecuteFile("Deepthought.rb");

// create a new instance of "Deepthought" calculator
var calc = globals.Deepthought.@new();

// set calculator input values
calc.a = 6;
calc.b = 7;

// calculate the result
var answer = calc.Calculate();

// create a new instance of "Deepthought" calculator
var calcClass = engine.eval("Deepthought");
var calc = invocable.invokeMethod(calcClass, "new");

// set calculator input values
invocable.invokeMethod(calc, "a=", 6);
invocable.invokeMethod(calc, "b=", 7);

// calculate the result
var answer = invocable.invokeMethod(calc, "Calculate");

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.

// The Fibonacci sequence
Stream.generate(new Supplier<Integer>() {
    int a = 0;
    int b = 1;

    public Integer get() {
        int temp = a;
        a = b;
        b = a + temp;
        return temp;
    }
}).limit(10).forEach(System.out::println);

// The Fibonacci sequence
public IEnumerable<int> Fibonacci() 
{
    int a = 0;
    int b = 1;

    while (true) 
    {
        yield return a;
        (a, b) = (b, a + b);
    }
}

// print the 10 first Fibonacci numbers
foreach (var it in Fibonacci().Take(10)) 
{
    Console.WriteLine(it);
}

Iterable<Integer> fibonacci(int limit) {
    return Stream.generate(new Supplier<Integer>() {
        int a = 0;
        int b = 1;
        
        public Integer get() {
            int temp = a;
            a = b;
            b = a + temp;
            return temp;
        }
    }).limit(limit)::iterator;
}

// print the 10 first Fibonacci numbers
for(int it: fibonacci(10)) {
    System.out.println(it);
}

var fibonacci = Stream.generate(new Supplier<Integer>() {
    int a = 0;
    int b = 1;
            
    public Integer get() {
        int temp = a;
        a = b;
        b = a + temp;
        return temp;
    }
});

// print the 10 first Fibonacci numbers
for(int it: fibonacci.limit(10).toList()) {
    System.out.println(it);
}

record Pair(int a, int b) {};

Stream
  .iterate(new Pair(0, 1), p -> new Pair(p.b, p.a + p.b))
  .limit(10)
  .map(p -> p.a)
  .forEach(System.out::println);