river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Java 1.4, 5 and 6, Retrotranslator - further investigation, Serialization
Date Thu, 02 Apr 2009 03:07:28 GMT
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.


      Discussion Forums: Open Discussion
      <http://sourceforge.net/forum/forum.php?forum_id=513539>

Admin <http://sourceforge.net/forum/admin/?group_id=153566>
*Serialization 
<http://sourceforge.net/forum/message.php?msg_id=7028159>* (New)
By: Pete_ (pete_ <http://sourceforge.net/users/pete_/>) - 2009-03-31 03:37
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>* (New)
By: Taras Puchko (tarasp <http://sourceforge.net/users/tarasp/>Project 
Admin 
<http://sourceforge.net/help/icon_legend.php?context=group_admin&uname=tarasp&this_group=153566&return_to=%2F>)

- 2009-03-31 09:51
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>* (New)
      By: Pete_ (pete_ <http://sourceforge.net/users/pete_/>) -
      2009-04-01 00:42
      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>* (New)
            By: Taras Puchko (tarasp
            <http://sourceforge.net/users/tarasp/>Project Admin
            <http://sourceforge.net/help/icon_legend.php?context=group_admin&uname=tarasp&this_group=153566&return_to=%2F>)
            - 2009-04-01 12:07
            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>* (New)
By: Pete_ (pete_ <http://sourceforge.net/users/pete_/>) - 2009-04-01 05:59
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>* (New)
By: Pete_ (pete_ <http://sourceforge.net/users/pete_/>) - 2009-04-01 09:01
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>* (New)
By: Taras Puchko (tarasp <http://sourceforge.net/users/tarasp/>Project 
Admin 
<http://sourceforge.net/help/icon_legend.php?context=group_admin&uname=tarasp&this_group=153566&return_to=%2F>)

- 2009-04-01 12:08
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



Mime
View raw message