Known Limitations

Thread Safety

MethodInvocationRemoting is NOT thread safe by default. Concurrent calls to MethodInvocationRemoteSender or MethodInvocationRemoteReceiver objects from different threads would very likely cause the IMethodInvocationSerializer member to go into an inconsistent state, or cause problems in the underlying IRemoteSender or IRemoteReceiver members (potentially return values being picked up for the wrong method call).

Support for pass by reference methods

Any changes that are made to parameters passed as part of a method invocation (i.e. changes made by the receiving code), will not be preserved and sent back to the calling code. Only the return value is sent back to the caller. Hence the 'ref' and 'out' keywords in C# are implicitly not supported.

Support for multiple languages and character sets

MethodInvocationRemoting has only been tested with default utf-8 text encoding, US Locale in Java, and InvariantCulture CultureInfo in C#. Other text encodings, regional/locale settings, and languages have not been tested.

Null Java BigDecimal objects

The Java java.lang.BigDecimal type is an object type, and hence can hold a null value. However, the default MethodInvocationSerializer class maps BigDecimal to C#'s System.Decimal which is a primitive type, and hence cannot hold null. The Java side MethodInvocationSerializer will serialize a null BigDecimal, but it will cause an exception when the C# side MethodInvocationSerializer attempts to deserialize it. This could potentially be overcome by overriding the default mapping of BigDecimal to instead map to the nullable System.Decimal? type in C#.

Timezone component not passed from C# DateTime to Java GregorianCalendar

The default MethodInvocationSerializer class maps Java's java.util.GregorianCalendar to C#'s System.DateTime. Whilst the GregorianCalendar object contains a timezone component, C# DateTime does not. Hence if a GregorianCalendar object is serialized and sent to C#, the timezone portion will be lost. Similarly a DateTime which is serialized and sent to C#, will take the default system timezone when deserialized on the Java side.

Float and double do not support Nan (not a number)

The System.Single and System.Double types in C#, and java.lang.Float and java.lang.Double types support a special NaN (not a number) value. However C# NaN values cannot be deserialized by the Java MethodInvocationSerializer class and vice versa, and will cause an exception if received in a serialized method invocation or return value. The serialization methods on both sides could be simply extended and overridden if you require support for NaN values.

MethodInvocationSerializer class does not support arrays of Java primitive types

In C# primitive data types have an equivalent object type which is considered the same in the type system. On the other hand the Java type system considers primitive types different from the objects which wrap them. For example, in C# the GetType().FullName property of types declared as Int32[] and integer[], will return 'System.Int32[]' in both cases. However in java, types declared as int[] and Integer[] will produce '[I' and '[Ljava.lang.Integer;' respectively when the getClass().getName() methods are called. As a one-to-one mapping is required between C# and Java types, only object types like Integer[] are supported when serializing arrays in Java.