Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49D42E7D.1090804@zeus.net.au>
Date: Thu, 02 Apr 2009 13:18:21 +1000
From: Peter Firmstone <jini@zeus.net.au>
Reply-To: river-dev@incubator.apache.org
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Java 1.4, 5 and 6, Retrotranslator - further investigation,
 Serialization
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I've been looking into the use of Retrotranslator to support the legacy
JRE 1.4 platform, so we can move forward, taking advantage of later Java
language features.

Taras Puchko, the developer of Retrotranslator has kindly answered some
questions for me regarding Serialization compatibility of backported
classes, for Serialization compatibility between the River JRE 1.4
Backport release and the Java 5 and later release, we need to implement
backports of ObjectInputStream and ObjectOutputStream, as Taras Puchko
has suggested we begin with the sources from Apache Harmony.

Also I noticed on the Retrotranslator website
http://retrotranslator.sourceforge.net/  a number of Java 6 API features
are supported also.

That has made me ponder, based on comments on Migration to Java 6,
whether the Backport Release of River should be used for JRE 1.4 and JRE
5?  Note the backport concurrency utils used by Retrotranslator, have
the Bug fixes implemented in Java 6 and are well tested.

The consensus so far has been in favour of a move to Java 5, with some
people supporting a move to Java 6 instead.

What are your thoughts?

Cheers,

Peter.

Sorry about the format in previous message, its fixed here:


      http://sourceforge.net/forum/forum.php?forum_id=513539


How does Retrotranslator affect serialized objects?

Is there some documentation that identifies which objects are safe to
Serialize and those that aren't?

Best Regards,

Peter.


*RE: Serialization
http://sourceforge.net/forum/message.php?msg_id=7030583
By: Taras Puchko

Hi Peter!

It's unsafe to serialize an object with an original JDK 1.5 application
and deserialize it with the same application but translated, or vice
versa, but it's ok to serialize and deserialize any objects with the
same translated application.

Translated classes differ from their original counterparts in two ways.
First, they might have additional synthetic static fields, so computed
SerialVersionUID would be different. Second, they might reference
backports instead of classes introduced in JDK 1.5.

So if you want a JDK 1.5 application and a translated one to
interoperate via serialization, don't use JDK 1.5 features in serialized
classes (e.g. enums) and put SerialVersionUID into each class.

Regards,
Taras.

      *RE: Serialization
      http://sourceforge.net/forum/message.php?msg_id=7036667
      By: Pete_
      Thanks Taras,

      Neat program by the way ;) I like the elegant way you've enabled
      extensions to Retrotranslator.

      Getting into detailed specifics (please forgive me):

      For a JDK 1.5 application and a translated one, interoperating via
      serialization (I'm only interested in Value classes, not things
      that shouldn't be serialized).

      Case 1:

      Where a class such as String that is compatible across JVM
      versions with Serialization (has the same serialVersionUID).

      Where that class has synthetic static fields or methods in the
      translated version.

      Is it still Deserializable?

      Case 2:

      Where a backported class extends Serializable and has the same
      serialVersionUID as the native Java 5 class eg AtomicLong.

      Is it still Deserializable?

      Case 3:

      Java 5 Language Features (Excluding features with new API Classes
      like Enum) like Generics, Annotations and the enhanced For loop?

      Do these affect classes implementing Serializable?

      Case 4:

      What about this Enum?

      public enum Day {
      MONDAY,
      TUESDAY,
      WEDNESDAY,
      THURSDAY,
      FRIDAY,
      SATURDAY,
      SUNDAY;

      private static final long serialVersionUID = -4549794470754669710L;
      }

      If it can be Serialized / Deserialized, when it returns to the JVM
      1.4, will a new object be instantiated or will it honor the
      singleton pattern and not instantiate a second enum?

      Regards,

      Peter.


            *RE: Serialization
            http://sourceforge.net/forum/message.php?msg_id=7040977
            By: Taras Puchko

            Hi Peter,

            Case 1:
            Yes, as long as it has serialVersionUID and don't reference
            backported classes.

            Case 2:
            No, since the name of backported class is different.

            Case 3:
            Yes, I believe that most Java 5 language features (excluding
            enum) don't affect serialization.

            Case 4:
            Yes, when using the same translated application enums honor
            the singleton pattern.

            Cheers,
            Taras


*RE: Serialization
http://sourceforge.net/forum/message.php?msg_id=7038442
By: Pete_

Just a quick update,

Looks like you can't modify the serialVersionUID of an enum, its always
0L. Wishful thinking on my part ; )

Cheers,

Peter.

*RE: Serialization
http://sourceforge.net/forum/message.php?msg_id=7039529
By: Pete_

Hi Taras,

Just had a little play, I get it now, I think. Retrotranlator doesn't
attempt to support Serialization of API implementation / backported
classes, since the class fully qualified names are different, so that a
transformed class can run on a later platform without stepping on the
java namespace.

bash-3.00$ serialver net.sf.retrotranslator.runtime.java.lang.Enum_
net.sf.retrotranslator.runtime.java.lang.Enum_: static final long
serialVersionUID = 3370713009433686859L;

bash-3.00$ serialver java.lang.Enum
java.lang.Enum: static final long serialVersionUID = 0L;

I wonder if your implementation of Enum can be made Serialization
compatible with java.lang.Enum?

I wonder if its possible to change the fully qualified name of an
implementation class just after serialization, from a lookup registry
(perhaps wrap / intercept the ObjectOutputStream), to the standard Java
fully qualified name, and change it back to the implementation class's
fully qualified name during deserialization (perhaps wrap / intercept
ObjectInputStream)?

 From the javadoc on ObjectInputStream:

Enum constants are deserialized differently than ordinary serializable
or externalizable objects. The serialized form of an enum constant
consists solely of its name; field values of the constant are not
transmitted. To deserialize an enum constant, ObjectInputStream reads
the constant name from the stream; the deserialized constant is then
obtained by calling the static method Enum.valueOf(Class, String) with
the enum constant's base type and the received constant name as
arguments. Like other serializable or externalizable objects, enum
constants can function as the targets of back references appearing
subsequently in the serialization stream. The process by which enum
constants are deserialized cannot be customized: any class-specific
readObject, readObjectNoData, and readResolve methods defined by enum
types are ignored during deserialization. Similarly, any
serialPersistentFields or serialVersionUID field declarations are also
ignored--all enum types have a fixed serialVersionUID of 0L.

 From the Serialization Spec:

The ObjectStreamClass provides information about classes that are saved
in a Serialization stream. The descriptor provides the fully-qualified
name of the class and its serialization version UID. A SerialVersionUID
identifies the unique original class version for which this class is
capable of writing streams and from which it can read.

*RE: Serialization
http://sourceforge.net/forum/message.php?msg_id=7040978
By: Taras Puchko

Hi Peter,

Yes, you can achieve serialization compatibility of enums and other
backported classes using custom backports of
ObjectInputStream/ObjectOutputStream. The initial sources could be taken
from Apache Harmony.

Cheers,
Taras