29.2 Comparing Java and C#/.NET I shall start by discussing the limitations of Java in general. You can skip to the next section if academic comparisons do not interest you. I hope that the issues brought up in this section will show what you cannot accomplish in Java because of the absence of pointer operations, and also what you can do in C# because of the ability to perform pointer operations. Java has three significant limitations. [3] [3] You can perform some of the listed operations via JNI. However, JNI is not a pure-Java solution. -
Coding beyond the JVM is impossible . You cannot write very low-level codes below the JVM layer. For example, you cannot write codes that interact with the underlying operating system's API using pure Java. The JVM checks for errors at runtime and prevents overwriting memory outside the allocated buffers. -
Direct memory manipulation is not possible. You cannot write codes that deal with memory directly. And that completely eliminates Java as a programming language suitable for writing codes which interact with memory mapped devices, such as device drivers. It is impossible in Java to write to element n+1 , when an array has been set up to have only n elements. -
Operating system-specific features are not supported for portability. You cannot write codes for specific operating systems. And that means there is no way a pure Java program can make use of, say, the Windows registry. This is a trade-off for portability, and portability is one of the core tenets of the Java language. How does C#/ .NET compare with Java in the points discussed above? -
Coding beyond the .NET runtime is still not possible using C#. Like the way Java byte codes run within the JVM, .NET IL codes run within the .NET CLR. However, with C# it is possible to write unsafe codes. Unsafe codes are those which involve pointer operations, and are to be differentiated from unmanaged codes. [4] [4] Unmanaged codes are codes which run outside the boundaries of the .NET CLR, and you cannot write unmanaged codes using C#. Unsafe codes, however, allow you to invoke legacy and native (unmanaged) codes which are running outside the CLR. An example will be an unsafe statement in C# which invokes a method of the Windows API, or some method in a legacy Windows DLL written in Visual C++ 6.0. With pure Java, you can also interact with native codes running outside the JVM via JNI. -
Direct memory manipulation is possible in unsafe codes. You can perform pointer operations in unsafe codes. Pointer operations allow you to write codes that interact with memory directly. Theoretically, C# can be used to write low-level programs, such as those that deal with memory-mapped devices. With C#'s unsafe codes, you can write to element n + 1 , when an array has been set up to have only n elements. -
Windows-specific features are supported in .NET BCL. Despite claims that the .NET framework is portable to other operating systems, the .NET BCL actually contain code and functionality specific to Windows. It is probably possible to port a large part of the .NET framework to another platform, but I can almost certainly say that only the simplest .NET programs will be portable without requiring code-level changes of some kind or other. 29.2.1 Writing real time applications One issue that is haunting Java is the suitability of this language for writing real time applications. [5] Most real time applications are still written in C [6] and assembly language. Java isn't really suitable for real time applications for two main reasons. [5] Currently, we have the Real Time Specification produced by the JCP, and an alternative (non-complementary) specification for real time applications released by an independent group called the J-Consortium. [6] Even C++ may not be suitable in strict real time systems because of the overheads of object-oriented features embedded in the language. -
Code optimization via direct memory access is impossible. If you can perform pointer operations, you can tweak your code for the best performance. A good example is the manipulation of codes so that time-critical operations are performed on the stack instead of the heap. You can't do that in Java. -
Java's performance depends a lot on the JVM. With the advent of very efficient JVMs, [7] it seems that speed is no longer as damning a factor. Nonetheless, the uncontrollable behavior of the JVM leaves much to be desired. The JVM is just like a wild beast “ there is no way you can tell it when to perform a garbage collection sweep, and when not to. Critical real time systems cannot tolerate such unpredictable behavior, especially when each garbage collection sweep may temporarily stall the whole application for a few milliseconds . [7] Java JIT compilers and other high performing JVMs such as Sun's HotSpot Engine. C#, with its ability to write unsafe codes, seems to have solved these two problems partially. -
Code optimization via direct memory access is possible. You can write pointer operations in unsafe C#. With pointer operations, a good developer can write highly optimized code for specific purposes. You are talking about real pure power here “ the power to retrieve anything from any memory location, and the power to set the value stored in any memory location. Of course, good code optimization via direct memory access is still a very difficult task requiring lots of careful planning, a cool clear mind, and experience, but the point is that this is possible with C# and .NET. -
The .NET runtime is a little more controllable. At least, there are methods in the .NET BCL which C# codes can call to force a garbage collection. Other than that, IL codes are also 'controlled' by the .NET CLR. Although it still has to be seen if C# will ever become popular with real time engineers , [8] it is one step nearer than Java to solving optimization and performance problems. [8] My guess is that C and assembly will still remain the all-time favorites for real time teams . Not all .NET languages allow you to write unsafe codes. You can do so with C# and C++, but not with J# and VB .NET. Unsafe codes are tagged with the unsafe modifier, as you will see later. Codes involving direct memory access and pointer operations are considered unsafe, and must be specifically tagged with this modifier to prevent accidental use. Of course, you should be especially careful when writing unsafe codes because, like C/C++, you can crash a system or cause strange runtime results by writing garbage to random areas in memory. You have to be extremely careful about not corrupting other memory locations with random data. 29.2.2 Why write unsafe codes? Unsafe codes can perform pointer operations, read beyond an array boundary, and read/write directly to arbitrary memory locations. There are several scenarios in which you will need to write unsafe codes. -
To communicate with a memory-mapped device or write very low-level codes such as device drivers. -
To write highly optimized performance-critical codes. Unlike safe codes, unsafe codes are not scrutinized by the .NET CLR for security and type safety. Under normal circumstances, the CLR performs runtime checking, such as whether you are trying to access an out-of-bounds index of an array. Such checks cut down on bugs , but have a performance overhead. -
To interoperate with legacy codes (probably written in C or C++). Such legacy codes may contain methods/functions that take in pointers. Many existing DLLs written in C or C++ require pointer types to be passed into their methods. You can only invoke these legacy methods with unsafe codes. Many methods of the Windows API also take in strange pointer types, or return pointer types. Although the rich .NET BCL should abstract almost everything you would possibly want to do with the Windows operating system, you can still interact with the Windows API directly via unsafe codes if desired.  |
