Java to C# Mapping

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


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


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 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 System.Uri System.Uri System.Uri System.NET.IPHostEntry System.NET.IPHostEntry System.NET.EndPoint System.NET.EndPoint System.NET.IPEndPoint System.NET.IPEndPoint
java.sql.Date System.DateTime
java.sql.Time System.DateTime
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 generic
java.util.GregorianCalender generic
java.util.Date System.DateTime System.DateTime
java.util.Hashtable System.Collections.Hashtable System.Collections.Hashtable
java.util.HashMap System.Collections.Hashtable
java.util.HashSet System.Collections.ArrayList
java.util.IdentityHashMap System.Collections.Hashtable
java.util.LinkedHashMap System.Collections.Hashtable
java.util.LinkedHashSet System.Collections.ArrayList
java.util.LinkedList System.Collections.ArrayList
java.util.Locale System.Globalization.CultureInfo System.Globalization.CultureInfo
java.util.Properties System.Collections.Hashtable
java.util.Random generic
java.util.SimpleTimeZone generic
java.util.Stack System.Collections.Stack System.Collections.Stack
java.util.TreeMap System.Collections.Hashtable
java.util.TreeSet System.Collections.ArrayList
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. 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( ex ) {

posted on 2007-06-08 14:17 芥子 阅读(1319) 评论(1)  编辑 收藏 引用


# re: Java to C# Mapping 2009-03-13 01:14 henru

grr  回复  更多评论