Contents - Cultural View

Comparison of Java and C Sharp 79
There are also differences between the two languages in treating the try-finally statement. The finally is always
executed, even if the try block contains control-passing statements like throw or return. In Java, this may result in
unexpected behavior if the try block is left by a return statement with some value, and then the finally block that is
executed afterwards is also left by a return statement with a different value. C# resolves this problem by prohibiting
any control-passing statements like return or break in the finally block.
A common reason for using try-finally blocks is to guard resource managing code, 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 Dispose() method of the object of the using is always called.
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:
int foo() {
}
try {
return 0;
} finally {
}
return 1;
In the above code, the return statement within try block causes control to leave it, and therefore finally block is
executed before the actual return happens. However, finally block itself performs a return as well; thus, the original
return that caused it to be entered is not actually executed, and the above method returns 1 rather than 0.
C# does not allow any statements which allow control flow to leave the 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.
Lower level code
The Java Native Interface (JNI) feature allows Java programs to call non-Java code. However, JNI does require the
code being called to follow several conventions and impose restrictions on types and names used. This means that an
extra adaption layer between legacy code and Java is often needed. This adaption code must be coded in a non-Java
language, often C or C++. Java Native Access (JNA) allows easier calling of native code that only requires writing
Java code, but comes at a performance cost.
In addition, third party libraries provide for Java-COM bridging, e.g. JACOB [19] (free), and J-Integra for COM [20]
(proprietary).
.NET Platform Invoke (P/Invoke) offers the same capability by allowing calls from C# to what Microsoft refers to as
unmanaged code. Through metadata attributes the programmer can control exactly how the parameters and results
are marshalled, thus avoiding the need for extra adaption code. P/Invoke allows almost complete access to
procedural APIs (such as Win32 or POSIX), but limited access to C++ class libraries.
In addition, .NET Framework also provides a .NET-COM bridge, allowing access to COM components as if they
were native .NET objects.
C# also allows the programmer to disable the normal type-checking and other safety features of the CLR, which then
enables the use of pointer variables. When using this feature, the programmer must mark the code using the 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