Java Connectivity: Java to C# Mapping
In this section we will give a brief overview of the Java to C# type mappings. Most Java types have a direct IDL (and therefore C#) counterpart. The basis for this mapping is the original OMG Java-to-IDL mapping of Java RMI types into CORBA IDL.
Basic Data Types
The following table lists the basic Java data types and their mapping into OMG IDL and C#.
| Java |
IDL Type |
.NET / C# |
| void |
void |
void |
| boolean |
boolean |
bool |
| char |
wchar |
char |
| byte |
octet |
byte |
| short |
short |
short |
| int |
long |
int |
| long |
long long |
long |
| float |
float |
float |
| double |
double |
double |
| String |
CORBA::WStringValue |
string |
Mapping of Java Names
Java names may contain characters that are illegal within OMG IDL identifiers such as '$' or other illegal Unicode characters (i.e. outside ISO Latin 1). These characters will be replaced (according to the OMG Java-to-IDL mapping) with a 'U' followed by 4 upper case hexadecimal characters representing the Unicode value of the replaced character.
Another problem may be a leading underscore, since Java identifiers that collide with reserved OMG IDL keywords are prepended with a leading underscore within the generated IDL code. To avoid possible name clashes with other identifiers resulting from this strategy, a leading underscore within a Java name are replaced by 'J_'.
Examples:
- _name maps to J_name
- <Unicode char> maps to Uxxxx
RMI Remote Interfaces
A Java RMI Remote interface (java.rmi.Remote) is mapped to an IDL interface, which in turn maps according to the usual J-Integra® Espresso IDL-to-C# mapping into a .NET interface derived from Ics.CORBA.Object.
Property accessors (pairs of get/set<property> methods) will result in standard .NET attributes.
If the Java interface contains overloaded method signatures, these signatures cannot be mapped directly into overloaded .NET/C# signatures because OMG's IDL does not allow method overloading. Thus, the OMG Java-to-IDL mapping defines a simple name mangling scheme for overloaded methods. If a method is unique in a base interface its name will not be mangled within that interface, but if the method is overloaded the name is enhanced within that derived interface by adding the parameter type's name to the original method name:
- void hello(boolean b) maps to void hello__boolean(bool b)
- void hello(int x) maps to void hello__long(int x)
- void hello(string n) maps to void hello__CORBA_ WStringValue(string n)
Please note that the generated name contains IDL types, not .NET types.
Java Serializables
RMI allows transporting objects by value provided they are Serializable (i.e. they implement the interface java.lang.Serializable). These objects are mapped into IDL ValueTypes and therefore result in C# classes derived from Ics.CORBA.portable.StreamableValue or Ics.CORBA.portable.CustomValue.
By contrast to a pure Java RMI environment, CORBA cannot move the code behind any object functionality together with the object's state (because the target environment of the transport may be on a different platform, implemented by a different programming language). Therefore, a separate implementation for the value type has to be provided on the transport's target side (i.e. the C# side) as well.
Arrays
Java arrays map directly into C# arrays.
Java Exceptions
Usually, a Java application will use an elaborated hierarchy of exception classes to realize fine grained exception handling. OMG IDL does not yet allow subclassing exceptions. Therefore, the OMG Java-to-IDL mapping defines a mapping of a Java user exception into two classes:
- A CORBA value type (which in fact can be derived from another value type) representing the Java user exception. This results on the C# side in a class derived from Ics.java.lang._Exception and Ics.CORBA.portable.StreamableValue.
- A standard CORBA exception with a "value" attribute containing this value type. The name of this exception will be generated by first removing any trailing "Exception" suffix and, secondly, adding a new "Ex" suffix. This results on the C# side in a class derived from the usual Ics.CORBA.UserException.
Be aware of the fact that for the Java user exception (as for all value types) an implementation has to be provided on the C# side.
Inner Classes
In Java, a class can contain inner classes. Due to the OMG Java-to-IDL mapping, such an inner class is mapped into a separate IDL interface with a composite name formed by concatenating the name of the outer class, two underscores, and the name of the inner class, which in turn maps into a standalone C# class. For example:
Java inner class TheInner within Java class TheOuter
- maps into IDL: interface TheOuter__TheInner
- maps into .NET: class TheOuter__TheInner
Mapping of Special Classes
Finally, there are some popular Java classes which either directly map into their .NET counterpart or they are represented by value types with an underlying .NET type.
| Java |
.NET / C# |
Underlying .NET / C# Type |
| java.net.URI |
System.Uri |
System.Uri |
| java.net.URL |
Ics.java.net.URL |
System.Uri |
| java.net.InetAddress |
System.NET.IPHostEntry |
System.NET.IPHostEntry |
| java.net.SocketAddress |
System.NET.EndPoint |
System.NET.EndPoint |
| java.net.InetSocketAddress |
System.NET.IPEndPoint |
System.NET.IPEndPoint |
| java.sql.Date |
Ics.java.sql.Date |
System.DateTime |
| java.sql.Time |
Ics.java.sql.Time |
System.DateTime |
| java.sql.TimeStamp |
Ics.java.sql.TimeStamp |
System.DateTime |
| java.util.ArrayList |
System.Collections.ArrayList |
System.Collections.ArrayList |
| Java.util.BitSet |
System.Collections.BitArray |
System.Collections.BitArray |
| java.util.Calender |
Ics.java.util.Calender |
generic |
| java.util.GregorianCalender |
Ics.java.util.GregorianCalender |
generic |
| java.util.Date |
System.DateTime |
System.DateTime |
| java.util.Hashtable |
System.Collections.Hashtable |
System.Collections.Hashtable |
| java.util.HashMap |
Ics.java.util.HashMap |
System.Collections.Hashtable |
| java.util.HashSet |
Ics.java.util.HashSet |
System.Collections.ArrayList |
| java.util.IdentityHashMap |
Ics.java.util.IdentityHashMap |
System.Collections.Hashtable |
| java.util.LinkedHashMap |
Ics.java.util.LinkedHashMap |
System.Collections.Hashtable |
| java.util.LinkedHashSet |
Ics.java.util.LinkedHashSet |
System.Collections.ArrayList |
| java.util.LinkedList |
Ics.java.util.LinkedList |
System.Collections.ArrayList |
| java.util.Locale |
System.Globalization.CultureInfo |
System.Globalization.CultureInfo |
| java.util.Properties |
Ics.java.util.Properties |
System.Collections.Hashtable |
| java.util.Random |
Ics.java.util.Random |
generic |
| java.util.SimpleTimeZone |
Ics.java.util.SimpleTimeZone |
generic |
| java.util.Stack |
System.Collections.Stack |
System.Collections.Stack |
| java.util.TreeMap |
Ics.java.util.TreeMap |
System.Collections.Hashtable |
| java.util.TreeSet |
Ics.java.util.TreeSet |
System.Collections.ArrayList |
| java.util.Vector |
Ics.java.util.Vector |
System.Collections.ArrayList |
| javax.naming.Name |
Ics.javax.naming.Name |
generic |
| javax.naming.CompositeName |
Ics.javax.naming.CompositeName |
System.Collections.ArrayList |
| javax.naming.CompoundName |
Ics.javax.naming.CompoundName |
System.Collections.ArrayList |
The underlying .NET type can be accessed by a property with a corresponding name (i.e. an underlying 'ArrayList' is accessed by a property called 'ArrayList'). Some of the mapped Java types do not have a suitable .NET type which could represent this type. These so-called generic types are essentially data containers which are meant to be used in a Java environment once they are transferred there. If the data needed to be interpreted on the .NET side this should be done with a remote Java interface as a delegate.
Built In Java Exceptions
A large number of Java exceptions and errors have been implemented. Since their use is fairly straight forward and uniform, an explicit listing is not necessary. Each corresponding .NET exception carries the same name as the Java exception with ics as prefix (e.g. Ics.java.lang.ArithmeticException). In contrast to the specified Java-to-IDL mapping (and therefore different to the use of Java user exceptions), the built in Java exceptions surface directly as .NET exceptions. An IDL exception as transport container is not used. The ToString() method in the base of each exception allows you to display reason and stack trace information.
try {
...
} catch( Ics.java.lang.ArithmeticException ex ) {
System.Console.WriteLine(ex);
}
|