You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2009/04/02 05:07:28 UTC
Java 1.4, 5 and 6, Retrotranslator - further investigation, Serialization
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