Java, J, and the .NET Framework

The .NET Framework also contains arrays. .NET has the Array class defined in the System namespace, and every non-J# .NET array inherits from System.Array . The .NET arrays have their own properties and methods, which are different from but sometimes similar to those of Java arrays. For example, Java arrays have a length field that you can examine to determine the length of the array, and .NET arrays have a Length property. (Note the uppercase L). What this means is that J# arrays and arrays used by the other .NET languages are not the same. Happily, this is only of minor concern. First, you cannot create System.Array objects directly in J#, so there is little scope for ambiguity. Second, the J# compiler will freely convert from Java arrays to .NET arrays and back again. You can pass arrays from your C# code as parameters to methods written in J#, and vice-versa.

Java allows you to create multidimensional arrays. In the following example, variable i is a two-dimensional array of int elements:

int[][]i;

Strictly speaking, variable i is an array of arrays of int elements. The Java language permits such arrays to be ragged ”the second dimension can vary in length. For example, in the data array shown below, the second dimension comprises five elements in the first row of the array and three elements in the second row:

int[][]someData={{1,2,3,4,5},{6,7,8}};

The .NET Framework supports jagged arrays (notice the different nomenclature ” jagged rather than ragged ), which are essentially the same, and the J# compiler will convert Java ragged arrays into .NET jagged arrays and back again. However ”and this is a big however ”jagged arrays are not part of the Common Language Specification (CLS), and some languages, including Visual Basic .NET, do not have them! Instead, the CLS mandates rectangular arrays, where each dimension length is fixed and therefore cannot vary once it has been defined. In C#, a 5-by-3 two-dimensional rectangular array is declared using the following syntax:

int[,]moreData=newint[5,3];

Rectangular arrays are different beasts from jagged arrays, and you cannot assign a two-dimensional jagged array to a two-dimensional rectangular array (not even in C#). This posed a slight problem for J#. The Java language has only ragged arrays, which meant that J# would not be able to use any of the methods in the .NET Framework Class Library that passed or returned multidimensional arrays (because they're all rectangular, for CLS compliance). So Microsoft bit the bullet and added rectangular arrays to J#.

Exceptions

Both Java and .NET allow you to define, throw, and catch exceptions. Java exceptions descend from the generic Exception class in the java.lang package, but .NET exceptions descend from System.Exception . Java exceptions and .NET exceptions are different types that expose a similar functionality. To make interoperability with Java possible, an unqualified Exception refers to the java.lang.Exception class:

try
{

}
catch(Exceptione)//defaultstojava.lang.Exception
{

}

If you want to catch the .NET Exception class instead, you must qualify the Exception object:

try
{

}
catch(System.Exceptione)
{

}

One result of the way in which the Exception classes are defined with J# is that System.Exception will mask and catch java.lang.Exception (and consequently any other Java exceptions). However, the converse is not true ” java.lang.Exception will not catch System.Exception or any other .NET exceptions. So if your application throws a System.Exception or any of the other .NET exceptions, using a catch(Exception e) statement will not actually catch them. (You'll most likely get an error when you compile your code, informing you that possible exceptions have not been caught.) This has significant implications if you're using the .NET Framework Class Library with J# because many of the methods raise .NET exceptions. You should be prepared to handle them.

Interfaces

Java has interfaces, and .NET has interfaces. A J# class can implement a .NET interface, and a class written using one of the other .NET languages can implement a J# interface. An example C# interface is shown here:

//C#
publicinterfaceCBase
{
voiddoProcessing();
}

The J# JChild class that follows can implement this interface and even add a throws clause if the method can raise an exception:

//J#
publicclassJChildimplementsCBase
{
publicvoiddoProcessing()throwsException
{

thrownewException("Processingfailed");
}
}

The important point to remember when you use interfaces is that the specified methods must use types that are available in the implementing languages. (Trying to implement a C++ interface that uses pointer types in J# could be tricky, for example.) If you stick to the types in the CLS, you should not have any problems.

You might need to perform a bit of translation when you implement interfaces that define properties. For example, the following interface is valid in C#:

//C#
interfaceCSharpInterface
{
intdata
{
get;
set;
}
}

An implementation in J# would look like this:

publicclassJSharpPropertiesimplementsCSharpInterface
{
/**@property*/
intget_data()
{

}

/**@property*/
voidset_data(intvalue)
{

}
}

Other Issues

You should be aware of some other issues that will affect the way that your J# programs interact with the .NET Framework, as described in the following sections.

Methods with Variable Numbers of Arguments

The CLS allows you to create methods that take variable numbers of arguments (as opposed to creating overloaded methods). The following C# method allows the caller to pass in a variable number of int parameters. The params keyword indicates that the array parameter that follows can be interpreted as a list of int elements by the compiler. If you are a C or C++ developer, you might be familiar with varargs , which performs a similar function:

//C#
publicvoidUseParams(paramsint[]list)
{
for(inti=0;i<list.Length;i++)
{
//processelementi

}
}

If you want to pass a selection of different types, you can create a params array comprising Object elements. You can invoke this method from C# using statements such as this one:

//C#
UseParams(99,100,120);
UseParams(5);

At run time, the actual parameters will be packaged into an int array and passed to the UseParams method as the formal parameter list. However, if you try calling the method from J# using the same syntax, you'll receive a compile-time error because the Java language does not permit methods that take variable parameter lists. Instead, you must manually package the parameters into an array yourself, as shown here:

//J#
int[]i={99,100,120};
UseParams(i);

Console I/O

The JDK provides the System.out PrintStream object, which has the method println for displaying information on the console. The println method is overloaded, which allows you to output a single value of any type ”most often a java.lang.String . The .NET Framework contains the Console object in the System namespace, which fulfills a similar role. It has a method called WriteLine , which you can use to display information to the screen. You can print Java strings, objects, and primitive types, as shown here. (Objects will be rendered using the ToString method inherited from System.Object .)

importSystem.*;//ConsoleisintheSystemnamespace

Stringmessage= "Hello,World";
Console.WriteLine(message);

You might find it more convenient to use Console.WriteLine rather than System.out.println when you develop J# programs.

Getting keyboard input is notoriously troublesome in Java. The System.in InputStream object supplies a read method that you can use to read individual bytes from the keyboard, but it is all very low-level and error-prone . In contrast, the System.Console class in the .NET Framework Class Library contains the ReadLine method, which reads a System.String from the keyboard, up to the next carriage return. This method is easier to use, as this code shows:

importSystem.*;

System.Stringinput=Console.ReadLine();

The ubyte Type

Microsoft has tried hard to not make too many additions to the Java language in J#. You've already seen that rectangular arrays were added to maintain compliance with the CLS. One data type in the CLS that is used by a number of methods in the .NET Framework Class Library is Byte , which can hold 8-bit unsigned values. Java also has a byte data type, but it is signed. (.NET has the SByte data type for signed 8-bit values.) Microsoft therefore created the data type ubyte for J#, for 8-bit unsigned data. Try not to get too confused ”a .NET SByte corresponds to a J# byte , and a .NET Byte corresponds to a J# ubyte !

Threads

The JDK defines the Thread class in the java.lang package. Classes that extend Thread and override the run method can be executed asynchronously. If an object instantiates a Thread object and calls the start method, the JVM will invoke the Thread object's run method and return to the calling object without waiting for run to finish. Both the calling object and the Thread object can then execute concurrently. The Thread class also provides the stop method, which can halt a Thread object in its tracks, and the join method, which causes the creating object to wait for the Thread object to complete. Classes can define methods as synchronized , which prevents two concurrent threads from executing the same code in the same object at the same time ”the second thread will have to wait for the first to exit the method.

The following classes illustrate a simple Thread class called WorkerThread . The run method prints the values 0 through 499. The ThreadRunner class creates a new WorkerThread and invokes its run method asynchronously by executing the start method. The ThreadRunner then prints a farewell message and finishes.

JDK Threads

classWorkerThreadextendsThread
{
publicvoidrun()
{
for(inti=0;i<500;i++)
System.out.print(i+ " ");
}
}

classThreadRunner
{
publicstaticvoidmain(String[]args)
{
WorkerThreadwt=newWorkerThread();
wt.start();
System.out.println("ThreadRunnerfinished");
}
}

You can compile and run this program using the JDK or J# ”it will work with either. On our uniprocessor machine, both the JDK and the J# implementations cause the "ThreadRunner finished" message to be displayed before the numbers 0 to 499 are printed. The results you get when you run the program might not be the same, especially if you have a multiprocessor machine.

Bear in mind that when you use JDK threads, the JVM implements the threading model itself. Many operating systems, including Windows, have native support for threads, and the JVM might use this facility behind the scenes, but it will use its own data structures internally for managing them. The reason for this, once again, is portability. Any Java application can use threads whether the underlying platform supports them or not, and all implementations of the JDK must provide a consistent implementation of the Thread class.

Windows has its own multithreading capability, and the common language runtime permits managed access to it through the System.Threading namespace. This namespace is feature-rich compared to the JDK, and it exposes the System.Threading.Thread class, which you can use from J#. To some extent, common language runtime threads and JDK threads will interoperate ”they can be coordinated with each other using either synchronized methods or common language runtime Monitor objects. However, the System.Threading.Thread class is different from java.lang.Thread and they are not interchangeable. A common language runtime thread cannot be a member of a JDK ThreadGroup , for example. The main reason that the java.lang.Thread class exists is to support existing JDK code that you don't want to rewrite. If you're undertaking new development that involves threads, you should use the System.Threading namespace in preference to the java.lang.Thread .

You have probably gathered that threads are another area in which there's a namespace clash . By default, the J# compiler assumes that an unqualified Thread reference refers to a java.lang.Thread . If you want to use a common language runtime thread, you must qualify it as a System.Threading.Thread . Threads under the common language runtime will be explained in detail in Chapter 8.

Omissions from the JDK

Microsoft has implemented much of the JDK 1.1.4 functionality. The omissions include RMI, which we already mentioned, and there is also no support for the Java Native Interface (JNI) or for applets. However, .NET, together with Windows, does supply eminently suitable alternatives. Instead of RMI, you can use .NET Remoting or COM. JNI has been replaced by J/Direct (originally introduced with Visual J++) and the Platform Invoke service, and applets have been superseded by ASP.NET Web Forms.

Migrating to J#

Microsoft supplies some useful tools with the Visual Studio.NET IDE to help you migrate existing JDK and Visual J++ 6.0 applications to J#. You can migrate the source code, or you can convert class files. We'll look at these possibilities next.

Migrating Source Code

By now, you should appreciate that you can compile ordinary .java source code using the jc compiler to produce DLLs and EXEs. The compiler can take source code that conforms to the Java Language Specification version 2.0. If you have existing J++ 6.0 solutions, you can open them in Visual Studio .NET if you have Visual J# installed. Solution and project files will be upgraded automatically (the Visual J# Upgrade Wizard takes you through the process), but you should be aware of a few issues:

• The CLASSPATH variable is no longer used. Instead, you must add references to each assembly that implements the packages your application uses. This means you must first have upgraded those packages and converted them into assemblies.

• References to COM components are not preserved automatically. You must add them manually to the Visual J# project either during the upgrade process (the wizard will prompt you) or using the Add Reference command on the Project menu.

• The project upgrade process ignores Microsoft Visual SourceSafe (VSS) settings. You must check out all source files from VSS before upgrading.

• Not all deployment options are preserved, and neither are any prebuild or postbuild steps.

The compiler understands many of the directives Microsoft introduced with J++, such as @dll , @com , @conditional , and #if . This means you can quickly migrate much of your code that uses J/Direct for accessing native APIs and that implements COM components using JActiveX wrappers. (For more information about using J/Direct and migrating COM components, see Part IV of this book.) Also, alongside the JDK libraries, Microsoft has also implemented some of the extension packages that ship with J++, most notably com.ms.com, com.ms.dll, and com.ms.win32. The class libraries include an implementation of the JDBC-ODBC bridge driver in com.ms.jdbc.odbc. This driver requires an ODBC 3.0 or later driver. These packages are all held in the Vjslib.dll assembly. You'll also find an implementation of the WFC libraries in the Vjswfc.dll assembly.

The Profiler, Heap Monitoring, and Debug APIs that were provided with J++ have been omitted from J#. You should use the corresponding .NET Framework Class Library APIs instead.

Converting Class Files

If you do not have the source code for a given set of Java classes available, you can still migrate an application to .NET. Microsoft's Java Binary Converter tool, jbimp, converts .class files into MSIL assemblies ”DLLs and EXEs. The simplest way to use jbimp is to run it from the command line. You'll find jbimp.exe in the folder \Program Files\Microsoft Visual J# .NET\Framework\Bin. If you're migrating several class files, you can combine them into a single DLL using the /target:library switch, which is similar to that used by the vjc compiler. The name of the DLL is taken from the first class file supplied on the command line, or you can specify a name using the /out parameter.

Let's take the OvenBean, TemperatureEvent , TemperatureEventListener , and TemperatureWarning classes used by the components example earlier in this chapter. (These files are in the JDK OvenBean folder.) Pretend that you've lost the source code and have only the .class files created as a result of compiling using the JDK. You can convert them into a .NET DLL using the following command:

jbimp/target:library/out:OvenBean.dllOvenBean.class
TemperatureEvent.classTemperatureEventListener.classTemperatureWarning.class

You can build an EXE using the /target:exe parameter (the default), as long as one of the classes has a main method. You can also use the /reference parameter to link to another .NET assembly. Continuing with the OvenBean example, you can convert the test client ( BeanClient.class ) and link it to the OvenBean.dll assembly by using the following command:

jbimp/reference:OvenBean.dllBeanClient.class

Running this command will result in a .NET executable called BeanClient.exe. (You can use the /out parameter to generate an executable with a different name.)

The jbimp tool has a number of other options available, including /recurse , which will recursively process .class files in subdirectories. This option is useful if you have an entire package that you need to convert.