JLCA 3.0 - Serialization

Serialization corresponds with the core and native technology that Java provides to save/recover the state of objects. It is used by other Java technologies inherent in J2SE 1.3. Java provides two kinds of Serialization: Basic Serialization (Java managed) and Custom Serialization (User managed). In Java, Serialization could be used by means of interfaces and Serialization is primarily converted to .NET framework through System.Runtime.Serialization API.


Main conversion achieved by JLCA 3.0 corresponding to Serialization is related to the following features: Basic and Custom Serialization, Inheritance Hierarchy, Inner Classes Serialization, transient fields and serialPersistenFields and some JavaDoc tags.


Table 23 and Table 24 show the most relevant details for Serialization conversion. In a summarized manner, they enunciate the Serialization features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using Serialization.

Coverage Details

Class / Interface in Package


JLCA 3.0 Coverage




These interfaces support Serialization in Java.


Java’s Serializable classes are converted to System.Runtime.Serialization.ISerializable with an attribute System.SerializableAttribute.

Basic serialization mechanism is converted completely. Custom serialization (using methods writeObject and readObject) is converted by means of the method ISerializable.GetObjectData and a special constructor. This conversion has some restrictions.







Map to System.Runtime.Serialization.SerializationException.









These exceptions were converted to a more general exception (System.Exception).


ObjectOutputStream writes primitive data types and graphs of Java objects to an OutputStream.



Serialization-related behavior is converted through System.Runtime.Serialization.SerializationInfo.

Special methods (defaultWriteObject and defaultReadObject) are converted to a SupportClass using FormatterServices.GetSerializableMembers.

Table 23: Serialization Conversion Coverage – Package




Custom Serialization

Conversion of methods writeObject and readObject has conflicts with some source code patterns. Full conversion is achieved when the code -to serialize and deserialize- resides totally in these methods and it is not inside flow of control structures.

In general, conversion of serialization code inside flow-control structures –like loops, ifs or switches- will raise runtime exceptions because a same key is being used to serialize/deserialize two different values.

.NET Framework Serialization requires a unique key for the data. A workaround could require assigning a unique key for each value written/read.

Further, conversion of methods writeObject and readObject calling routines behind the serialization will raise compilation errors. A workaround could require adapting the code-behind routines to receive/use the respective SerializationInfo and assign unique –but synchronized- keys for the values written/read.


Conversion for Externalizable classes with custom serialization (using methods writeExternal and readExternal) is carried-out in the same manner as the Serializable classes. But defining a custom stream serialization format -as Externalization does- is not converted.

A workaround could require reviewing the hierarchies of Externalizable classes and consider add/remove attributes depending on the metadata required for each member of the hierarchy.

General Issues And Repository Convertion

Serialization Conversion is carried-out to .NET Framework Serialization. As in Java, .NET Framework serialize and deserialize objects use an own format. So, an object serialized in Java could not be deserialized in .NET framework because .NET Framework does not know how deal with Java’s format. The best conversion is achieved when the conversion includes both applications which serializes and deserializes the information, and when the objects’ repository is not to be converted.

If not, a workaround could require converting the objects repository, separately. This conversion process could be performed with a Java program reading the Java objects and writing them to an intermediate repository (with an intermediate format, if .NET Framework’s format is unknown). After which, a C# program could read this intermediate repository and write them in the .NET Framework’s objects repository using the converted application.

Serial Persistent Fields

Supported case is related when the array variable “serialPersistentFields” is declared and initialized at the same time and the initialization does not invoke/use methods or fields. After conversion, the array variable could be commented.

A workaround could require add/remove an attribute System.NonSerializedAttribute to fields not referenced by the array variable serialPersistentFields.

Table 24: Serialization Conversion Issues