You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Paulex Yang (JIRA)" <ji...@apache.org> on 2006/03/07 08:57:38 UTC
[jira] Created: (HARMONY-184) java.util.TimeZone's default
implementation may cause many classes' serialization non-compatible with RI
java.util.TimeZone's default implementation may cause many classes' serialization non-compatible with RI
--------------------------------------------------------------------------------------------------------
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and getDefault(), are only ways to get a TimeZone instance, but Harmony and RI uses different classes as default implementation, which cause serialization non-compatible. Further, all classes whose serialization form includes TimeZone won't compatible with RI, too, for example, java.util.Calendar(with subclass), java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because Harmony use API class SimpleTimeZone as default implementation, but RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone("GMT");
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new FileOutputStream("TimeZone.ser"));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new FileInputStream("TimeZone.ser"));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
if (null != oinput) {
oinput.close();
}
} catch (Exception e) {
}
}
}
Run in RI, passes without any failure
Run in Harmony, exception throwed as below:
java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
at java.lang.Class.forName(Class.java:154)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
... ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
Geir
2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
> I see it as an opportunity. :)
>
> We should ask Sun what to do.... they are the "go to" people for
> compatibility questions, right?
Does it mean that you will ask Sun? :)
Thanks,
Mikhail.
>
> geir
>
>
> George Harley wrote:
> > Thanks Chris, your experience on this matter is very welcome. Even if it
> > does make me feel a little depressed ;-)
> >
> > Best regards,
> > George
> >
> >
> > Chris Gray wrote:
> >> Hi George,
> >>
> >>
> >>> I wonder what lessons other class library development teams have learned
> >>> in this area ?
> >>>
> >>
> >> I guess that our experience from Wonka can be summed up as
> >> "serialization is a PITA". Most of the time the problem can be solved,
> >> you just never know where the next one will pop up. We advise our
> >> cutomers against using serialization as a way to exchange data between
> >> VMs - use XML, use Hessian, use anything except serialization. That
> >> goes for RMI too. I guess it's easier for us to take this line in an
> >> embedded environment than in the context of, say, J2EE.
> >>
> >> Good luck,
> >>
> >> Chris
> >>
> >
> >
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I see it as an opportunity. :)
We should ask Sun what to do.... they are the "go to" people for
compatibility questions, right?
geir
George Harley wrote:
> Thanks Chris, your experience on this matter is very welcome. Even if it
> does make me feel a little depressed ;-)
>
> Best regards,
> George
>
>
> Chris Gray wrote:
>> Hi George,
>>
>>
>>> I wonder what lessons other class library development teams have learned
>>> in this area ?
>>>
>>
>> I guess that our experience from Wonka can be summed up as
>> "serialization is a PITA". Most of the time the problem can be solved,
>> you just never know where the next one will pop up. We advise our
>> cutomers against using serialization as a way to exchange data between
>> VMs - use XML, use Hessian, use anything except serialization. That
>> goes for RMI too. I guess it's easier for us to take this line in an
>> embedded environment than in the context of, say, J2EE.
>>
>> Good luck,
>>
>> Chris
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Thanks Chris, your experience on this matter is very welcome. Even if it
does make me feel a little depressed ;-)
Best regards,
George
Chris Gray wrote:
> Hi George,
>
>
>> I wonder what lessons other class library development teams have learned
>> in this area ?
>>
>
> I guess that our experience from Wonka can be summed up as "serialization is a
> PITA". Most of the time the problem can be solved, you just never know where
> the next one will pop up. We advise our cutomers against using serialization
> as a way to exchange data between VMs - use XML, use Hessian, use anything
> except serialization. That goes for RMI too. I guess it's easier for us to
> take this line in an embedded environment than in the context of, say, J2EE.
>
> Good luck,
>
> Chris
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Chris Gray <ch...@kiffer.be>.
Hi George,
> I wonder what lessons other class library development teams have learned
> in this area ?
I guess that our experience from Wonka can be summed up as "serialization is a
PITA". Most of the time the problem can be solved, you just never know where
the next one will pop up. We advise our cutomers against using serialization
as a way to exchange data between VMs - use XML, use Hessian, use anything
except serialization. That goes for RMI too. I guess it's easier for us to
take this line in an embedded environment than in the context of, say, J2EE.
Good luck,
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/3/7, George Harley <ge...@googlemail.com>:
> I wonder what lessons other class library development teams have learned
> in this area ?
BTW, the problem with serialization of crypto keys (various implementations of
java.security.Key) was resolved in 1.5 by introducing a new class
java.security.KeyRep
I'd say
>> 1. just let it be
Thanks,
Mikhail
>
> Best regards,
> George
>
>
> >
> > Paulex Yang (JIRA) wrote:
> >> java.util.TimeZone's default implementation may cause many classes'
> >> serialization non-compatible with RI
> >> --------------------------------------------------------------------------------------------------------
> >>
> >>
> >> Key: HARMONY-184
> >> URL: http://issues.apache.org/jira/browse/HARMONY-184
> >> Project: Harmony
> >> Type: Bug
> >> Components: Classlib Reporter: Paulex Yang
> >> Priority: Critical
> >>
> >>
> >> Static factory methods, java.util.TimeZone.getInstance(String) and
> >> getDefault(), are only ways to get a TimeZone instance, but Harmony
> >> and RI uses different classes as default implementation, which cause
> >> serialization non-compatible. Further, all classes whose
> >> serialization form includes TimeZone won't compatible with RI, too,
> >> for example, java.util.Calendar(with subclass),
> >> java.text.DateFormat(with subclass), etc.
> >>
> >> But the incompatiblity is hard to be imputed to Harmony, because
> >> Harmony use API class SimpleTimeZone as default implementation, but
> >> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
> >>
> >> The reproduce procedure:
> >> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> >> public void writeObject(){
> >> TimeZone zone = TimeZone.getTimeZone("GMT");
> >> ObjectOutputStream ooutput = null;
> >> try {
> >> ooutput = new ObjectOutputStream(new
> >> FileOutputStream("TimeZone.ser"));
> >> ooutput.writeObject(zone);
> >> } finally {
> >> try {
> >> if (null != ooutput) {
> >> ooutput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> 2. Trying to deserialize this object from file, run codes below
> >> public void readObject(){
> >> ObjectInputStream oinput = null;
> >> try {
> >> oinput = new ObjectInputStream(new
> >> FileInputStream("TimeZone.ser"));
> >> TimeZone newObj = (TimeZone)oinput.readObject();
> >> } finally {
> >> try {
> >> if (null != oinput) {
> >> oinput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> Run in RI, passes without any failure
> >> Run in Harmony, exception throwed as below:
> >> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> >> at java.lang.Class.forName(Class.java:154)
> >> at
> >> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> >> ... ...
> >>
> >>
> >
> >
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Chris Gray <ch...@kiffer.be>.
On Tuesday 07 March 2006 14:38, Geir Magnusson Jr wrote:
> This is somewhat terrifying, isn't it? Are there really references to
> com.sun.* in serialized API objects? This *has* to be a bug in the
> whole spec if so...
If you ask me, the serialization spec *is* a bug. There are just two many ways
to break serialization compatibility while remaining binary compatible, and
that ain't right.
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> The problem is serial form contains class name "sun.foo"
> and if you deal with "o.a.h.foo" then serialization framework
> will never know that you class's readObject() is to be invoked.
>
Yep, you're right : it really is a lot worse than I originally envisaged :-(
> Another option is provide 'pairs' to ObjectInputStream.readObject():
> for each 'foo' method it will know what is the corresponding harmony
> class.
>
Sounds like keeping the list of pairs up to date could become a
never-ending task :-(
Given this plus the valuable insight from Chris Gray, I'm starting to
see "let it be" as a serious option.
Best regards,
George
> Thanks,
> Mikhail
>
>
> 2006/3/7, George Harley <ge...@googlemail.com>:
>
>> Mikhail Loenko wrote:
>>
>>> George,
>>>
>>> 2006/3/7, George Harley <ge...@googlemail.com>:
>>>
>>>
>>>> Paulex Yang wrote:
>>>>
>>>>
>>>>> This kind of serialization compatibility issue may be found again
>>>>> later, if only RI use some non-API class as default implementation of
>>>>> serializable abstract class. So I think we need some discussion on
>>>>> this issue for a principle.
>>>>>
>>>>> I propose two choice:
>>>>> 1. just let it be
>>>>> 2. mimic a class as RI, in this TimeZone case, create a
>>>>> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
>>>>> works but risky and ugly, it is risky because RI may change the
>>>>> implementation class later(which will also break RI's serialization
>>>>> compatibility of course)
>>>>>
>>>>> comments?
>>>>>
>>>>>
>>>> Hi Paulex,
>>>>
>>>> When such RI->Harmony serialization incompatibilities come to light we
>>>> can aim to deal with it in readObject() methods added to the affected
>>>>
>>>>
>>> It is not quite clear, in which class you are going to deal with readObject() ?
>>>
>>> Are you suggesting modification of IO framework that does serialization?
>>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>>
>> Hi Mikhail,
>>
>> I mean the "private void readObject(ObjectInputStream os)" method that
>> every type implementing the Serializable interface can contain to
>> provide customised de-serialization.
>>
>> Best regards,
>> George
>>
>>
>>>> types. This will have to be done on a case-by-case basis of course. In
>>>> this particular case I could imagine that we could catch that
>>>> ClassNotFoundException in the method and proceed on from there.
>>>>
>>>> But what about Harmony->RI serialization incompatibilities ? That is,
>>>> what about Harmony applications serializing types to files and those
>>>> files being later read in by applications running on a RI JRE ? In some
>>>> cases we will probably "get away with it" as the differences in
>>>> implementation will not break compatibility. For instance, running your
>>>> test code so that Harmony produces the .ser file and the RI reads it in
>>>> seemed to work fine for me. But the risk of problems will always be
>>>> there. I am not certain that writing stubs of sun.* classes is a good
>>>> direction to set off in to counter those risks. It would be better to
>>>> try and work with the RI providers so that their classes can cope with
>>>> serialized Harmony types.
>>>>
>>>> I wonder what lessons other class library development teams have learned
>>>> in this area ?
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>
>>>>
>>>>
>>>>> Paulex Yang (JIRA) wrote:
>>>>>
>>>>>
>>>>>> java.util.TimeZone's default implementation may cause many classes'
>>>>>> serialization non-compatible with RI
>>>>>> --------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Key: HARMONY-184
>>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-184
>>>>>> Project: Harmony
>>>>>> Type: Bug
>>>>>> Components: Classlib Reporter: Paulex Yang
>>>>>> Priority: Critical
>>>>>>
>>>>>>
>>>>>> Static factory methods, java.util.TimeZone.getInstance(String) and
>>>>>> getDefault(), are only ways to get a TimeZone instance, but Harmony
>>>>>> and RI uses different classes as default implementation, which cause
>>>>>> serialization non-compatible. Further, all classes whose
>>>>>> serialization form includes TimeZone won't compatible with RI, too,
>>>>>> for example, java.util.Calendar(with subclass),
>>>>>> java.text.DateFormat(with subclass), etc.
>>>>>>
>>>>>> But the incompatiblity is hard to be imputed to Harmony, because
>>>>>> Harmony use API class SimpleTimeZone as default implementation, but
>>>>>> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
>>>>>>
>>>>>> The reproduce procedure:
>>>>>> 1. To serialize TimeZone object to a file in RI, run codes below in RI
>>>>>> public void writeObject(){
>>>>>> TimeZone zone = TimeZone.getTimeZone("GMT");
>>>>>> ObjectOutputStream ooutput = null;
>>>>>> try {
>>>>>> ooutput = new ObjectOutputStream(new
>>>>>> FileOutputStream("TimeZone.ser"));
>>>>>> ooutput.writeObject(zone);
>>>>>> } finally {
>>>>>> try {
>>>>>> if (null != ooutput) {
>>>>>> ooutput.close();
>>>>>> }
>>>>>> } catch (Exception e) {
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> 2. Trying to deserialize this object from file, run codes below
>>>>>> public void readObject(){
>>>>>> ObjectInputStream oinput = null;
>>>>>> try {
>>>>>> oinput = new ObjectInputStream(new
>>>>>> FileInputStream("TimeZone.ser"));
>>>>>> TimeZone newObj = (TimeZone)oinput.readObject();
>>>>>> } finally {
>>>>>> try {
>>>>>> if (null != oinput) {
>>>>>> oinput.close();
>>>>>> }
>>>>>> } catch (Exception e) {
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Run in RI, passes without any failure
>>>>>> Run in Harmony, exception throwed as below:
>>>>>> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
>>>>>> at java.lang.Class.forName(Class.java:154)
>>>>>> at
>>>>>> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
>>>>>> ... ...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Stepan Mishura <st...@gmail.com>.
Paulex,
see my comments below.
On 3/10/06, Paulex Yang <pa...@gmail.com> wrote:
>
> Stepan Mishura wrote:
> > Hi Paulex,
> >
> >
> >> Currently, we have three options:
> >> 1. let it be, and speak it loudly in Harmony JavaDoc
> >>
> >>
> >
> > I'd choose this option. It is open and honest - if we get unknown class
> for
> > deserialization (say sun.util.calendar.ZoneInfo or
> > com.someCompanyName.util.MyTimeZone) we should not do any tricks and
> create
> > illusion for a user that we know how to deserialize it. Also I don't
> think
> > that "to be compatible" means to provide compatible implementation of
> > com.sun.* classes.
> >
> In fact this is also my preferred choice:). So I suggest to mark the
> JIRA 184 (the TimeZone case) as "won't fix", and wait to see if any
> application is broken by this.
Agree.
> IMHO, the best we can do in Harmony implementation is not to do the same
> > "serialization bug". I mean the following: factory methods of TimeZone
> class
> > should return instances of SimpleTimeZone class. So Harmony
> implementation
> > will produce serial form that will be deserializable on any other
> > implementation. However I don't know whether it is possible or not to
> > implement in this way.
> >
> Yes, currently the Harmony DOES use SimpleTimeZone, and the serialized
> bytes by Harmony can be deserialized by RI. So it is definitely
> possible, at least for this case.
Great!
>
> >> 2. try to compatible with RI, by creating some adapter with RI's
> >> serializable class name, i.e. com.sun.*, etc, and the behavior is even
> >> not necessarily compatible with RI. we can even separate them all to a
> >> new component named as "compatibility", so that it is easily modify
> them
> >> when RI changes its mind and improve. Not sure if it is legally fine.
> >>
> >
> > IMHO, it is not the option. The word 'adapter' is used here only to
> soften
> > the fact that we have to implement a set of com.sun.* classes. And
> > definitely they won't be "compatible". So without them we are not
> > "compatible" and with them were are not still "compatible" :-) Why we
> should
> > do this?
> >
> >
> >> 3. also try to compatible with RI, by maintaining pairs in
> >> ObjectInputStream, this approach maybe has less legal risk? (I have no
> >> idea in fact.)
> >>
> >>
> >
> > Not quite clear what you mean. Do you suggest changing serialization
> > framework? I mean that if it detects during deserialization, for
> example,
> > sun.util.calendar.ZoneInfo it will substitute it with
> > o.a.h.util.calendar.ZoneInfo. Right?
> >
> Yes, this's my understanding of Mikhail's idea.
If so it is not the option for me too. I can not find a quotation in serial
spec. that explicitly forbids changing a class name during deserialization
but I believe that the spec. implies this.
Thanks,
Stepan.
Pls. refer to his former mail in this thread for details if you want.
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
> >
> > On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
> >
> >> Mikhail
> >>
> >> Mikhail Loenko wrote:
> >>
> >>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
> >>>
> >>>
> >>>> This is somewhat terrifying, isn't it? Are there really references
> to
> >>>> com.sun.* in serialized API objects?
> >>>>
> >>>>
> >>> Yes, there are.
> >>> For example, TimeZone.ser produced by the example from the JIRA issue
> >>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
> >>>
> >>>
> >> yes, and as I mentioned before, the TimeZone is composited by other
> >> serializable class, so that all these classes cannot be serialization
> >> compatible, feel like something as cancer :(
> >>
> >>> Can we list all the popular applications that exchange by serialized
> >>>
> >> objects
> >>
> >>> and identify which objects do they send/receive?
> >>>
> >>>
> >> Rather than investigating almost infinite and uncertain(i.e. how to
> >> define popular?) applications, I'd like to test all the serializable
> >> class in JSE, at least it is a certain and limited set, we can just
> find
> >> all these kind of incompatibilities one by one, and take some actions.
> >>
> >> Currently, we have three options:
> >> 1. let it be, and speak it loudly in Harmony JavaDoc
> >> 2. try to compatible with RI, by creating some adapter with RI's
> >> serializable class name, i.e. com.sun.*, etc, and the behavior is even
> >> not necessarily compatible with RI. we can even separate them all to a
> >> new component named as "compatibility", so that it is easily modify
> them
> >> when RI changes its mind and improve. Not sure if it is legally fine.
> >> 3. also try to compatible with RI, by maintaining pairs in
> >> ObjectInputStream, this approach maybe has less legal risk? (I have no
> >> idea in fact.)
> >>
> >> Any other good ideas?
> >>
> >> And before all of this, I cannot agree with Geir more - we should make
> >> Sun be aware of this issue.
> >>
> >>> Thanks,
> >>> Mikhail
> >>>
> >>>
> >>>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Paulex Yang wrote:
> Stepan Mishura wrote:
>> Hi Paulex,
>>
>>
>>> Currently, we have three options:
>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>>
>>>
>>
>> I'd choose this option. It is open and honest - if we get unknown
>> class for
>> deserialization (say sun.util.calendar.ZoneInfo or
>> com.someCompanyName.util.MyTimeZone) we should not do any tricks and
>> create
>> illusion for a user that we know how to deserialize it. Also I don't
>> think
>> that "to be compatible" means to provide compatible implementation of
>> com.sun.* classes.
>>
> In fact this is also my preferred choice:). So I suggest to mark the
> JIRA 184 (the TimeZone case) as "won't fix", and wait to see if any
> application is broken by this.
I think that the Javadoc comments in java.util.TimeZone should be
updated to clarify precisely what this Java implementation returns from
the static methods under discussion. It would be a small example of the
"value add" of Harmony.
Best regards,
George
>> IMHO, the best we can do in Harmony implementation is not to do the same
>> "serialization bug". I mean the following: factory methods of
>> TimeZone class
>> should return instances of SimpleTimeZone class. So Harmony
>> implementation
>> will produce serial form that will be deserializable on any other
>> implementation. However I don't know whether it is possible or not to
>> implement in this way.
>>
> Yes, currently the Harmony DOES use SimpleTimeZone, and the serialized
> bytes by Harmony can be deserialized by RI. So it is definitely
> possible, at least for this case.
>>
>>> 2. try to compatible with RI, by creating some adapter with RI's
>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>> not necessarily compatible with RI. we can even separate them all to a
>>> new component named as "compatibility", so that it is easily modify
>>> them
>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>>
>>
>> IMHO, it is not the option. The word 'adapter' is used here only to
>> soften
>> the fact that we have to implement a set of com.sun.* classes. And
>> definitely they won't be "compatible". So without them we are not
>> "compatible" and with them were are not still "compatible" :-) Why we
>> should
>> do this?
>>
>>> 3. also try to compatible with RI, by maintaining pairs in
>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>> idea in fact.)
>>>
>>>
>>
>> Not quite clear what you mean. Do you suggest changing serialization
>> framework? I mean that if it detects during deserialization, for
>> example,
>> sun.util.calendar.ZoneInfo it will substitute it with
>> o.a.h.util.calendar.ZoneInfo. Right?
>>
> Yes, this's my understanding of Mikhail's idea.
>
> Pls. refer to his former mail in this thread for details if you want.
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>>
>> On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
>>
>>> Mikhail
>>>
>>> Mikhail Loenko wrote:
>>>
>>>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>>>
>>>>
>>>>> This is somewhat terrifying, isn't it? Are there really
>>>>> references to
>>>>> com.sun.* in serialized API objects?
>>>>>
>>>>>
>>>> Yes, there are.
>>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>>
>>>>
>>> yes, and as I mentioned before, the TimeZone is composited by other
>>> serializable class, so that all these classes cannot be serialization
>>> compatible, feel like something as cancer :(
>>>
>>>> Can we list all the popular applications that exchange by serialized
>>>>
>>> objects
>>>
>>>> and identify which objects do they send/receive?
>>>>
>>>>
>>> Rather than investigating almost infinite and uncertain(i.e. how to
>>> define popular?) applications, I'd like to test all the serializable
>>> class in JSE, at least it is a certain and limited set, we can just
>>> find
>>> all these kind of incompatibilities one by one, and take some actions.
>>>
>>> Currently, we have three options:
>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>> 2. try to compatible with RI, by creating some adapter with RI's
>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>> not necessarily compatible with RI. we can even separate them all to a
>>> new component named as "compatibility", so that it is easily modify
>>> them
>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>> 3. also try to compatible with RI, by maintaining pairs in
>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>> idea in fact.)
>>>
>>> Any other good ideas?
>>>
>>> And before all of this, I cannot agree with Geir more - we should make
>>> Sun be aware of this issue.
>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>>
>>>>
>>> --
>>> Paulex Yang
>>> China Software Development Lab
>>> IBM
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
Stepan Mishura wrote:
> Hi Paulex,
>
>
>> Currently, we have three options:
>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>
>>
>
> I'd choose this option. It is open and honest - if we get unknown class for
> deserialization (say sun.util.calendar.ZoneInfo or
> com.someCompanyName.util.MyTimeZone) we should not do any tricks and create
> illusion for a user that we know how to deserialize it. Also I don't think
> that "to be compatible" means to provide compatible implementation of
> com.sun.* classes.
>
In fact this is also my preferred choice:). So I suggest to mark the
JIRA 184 (the TimeZone case) as "won't fix", and wait to see if any
application is broken by this.
> IMHO, the best we can do in Harmony implementation is not to do the same
> "serialization bug". I mean the following: factory methods of TimeZone class
> should return instances of SimpleTimeZone class. So Harmony implementation
> will produce serial form that will be deserializable on any other
> implementation. However I don't know whether it is possible or not to
> implement in this way.
>
Yes, currently the Harmony DOES use SimpleTimeZone, and the serialized
bytes by Harmony can be deserialized by RI. So it is definitely
possible, at least for this case.
>
>> 2. try to compatible with RI, by creating some adapter with RI's
>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>> not necessarily compatible with RI. we can even separate them all to a
>> new component named as "compatibility", so that it is easily modify them
>> when RI changes its mind and improve. Not sure if it is legally fine.
>>
>
> IMHO, it is not the option. The word 'adapter' is used here only to soften
> the fact that we have to implement a set of com.sun.* classes. And
> definitely they won't be "compatible". So without them we are not
> "compatible" and with them were are not still "compatible" :-) Why we should
> do this?
>
>
>> 3. also try to compatible with RI, by maintaining pairs in
>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>> idea in fact.)
>>
>>
>
> Not quite clear what you mean. Do you suggest changing serialization
> framework? I mean that if it detects during deserialization, for example,
> sun.util.calendar.ZoneInfo it will substitute it with
> o.a.h.util.calendar.ZoneInfo. Right?
>
Yes, this's my understanding of Mikhail's idea.
Pls. refer to his former mail in this thread for details if you want.
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
>
> On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
>
>> Mikhail
>>
>> Mikhail Loenko wrote:
>>
>>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>>
>>>
>>>> This is somewhat terrifying, isn't it? Are there really references to
>>>> com.sun.* in serialized API objects?
>>>>
>>>>
>>> Yes, there are.
>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>
>>>
>> yes, and as I mentioned before, the TimeZone is composited by other
>> serializable class, so that all these classes cannot be serialization
>> compatible, feel like something as cancer :(
>>
>>> Can we list all the popular applications that exchange by serialized
>>>
>> objects
>>
>>> and identify which objects do they send/receive?
>>>
>>>
>> Rather than investigating almost infinite and uncertain(i.e. how to
>> define popular?) applications, I'd like to test all the serializable
>> class in JSE, at least it is a certain and limited set, we can just find
>> all these kind of incompatibilities one by one, and take some actions.
>>
>> Currently, we have three options:
>> 1. let it be, and speak it loudly in Harmony JavaDoc
>> 2. try to compatible with RI, by creating some adapter with RI's
>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>> not necessarily compatible with RI. we can even separate them all to a
>> new component named as "compatibility", so that it is easily modify them
>> when RI changes its mind and improve. Not sure if it is legally fine.
>> 3. also try to compatible with RI, by maintaining pairs in
>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>> idea in fact.)
>>
>> Any other good ideas?
>>
>> And before all of this, I cannot agree with Geir more - we should make
>> Sun be aware of this issue.
>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
As we discussed, I just attached a patch for JIRA 184 on TimeZone case
http://issues.apache.org/jira/browse/HARMONY-184
and suggested to mark this issue as "won't fix".
George Harley wrote:
> Richard Liang wrote:
>> Stepan Mishura wrote:
>>> Hi Paulex,
>>>
>>>
>>>> Currently, we have three options:
>>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>>>
>>>>
>>>
>>> I'd choose this option. It is open and honest - if we get unknown
>>> class for
>>> deserialization (say sun.util.calendar.ZoneInfo or
>>> com.someCompanyName.util.MyTimeZone) we should not do any tricks and
>>> create
>>> illusion for a user that we know how to deserialize it. Also I don't
>>> think
>>> that "to be compatible" means to provide compatible implementation of
>>> com.sun.* classes.
>>>
>>> IMHO, the best we can do in Harmony implementation is not to do the
>>> same
>>> "serialization bug". I mean the following: factory methods of
>>> TimeZone class
>>> should return instances of SimpleTimeZone class. So Harmony
>>> implementation
>>> will produce serial form that will be deserializable on any other
>>> implementation. However I don't know whether it is possible or not to
>>> implement in this way.
>>>
>>>
>> Agree. I'm just wondering what we shall say in Harmony JavaDoc. It's
>> RI (SUN) who breaks its spec.
>
> Hi Richard,
>
> I sent a mail on this topic yesterday (maybe my mail client is playing
> up again ?) : the RI Javadoc for the java.util.TimeZone method
> getDefault() states that "The source of the default TimeZone may vary
> with implementation". Given that I personally do not think that they
> are breaking "the spec" in this instance : they are pretty much
> stating that this method is dependent on the Java implementation.
>
> IMHO, their Javadoc needs to make it clearer that the return from
> their implementation of this method cannot be guaranteed to be
> interoperate with other Java implementations. Likewise, the Harmony
> Javadoc for the corresponding methods, and others like it that we have
> yet to discover, should seek to remove all such ambiguities. This is a
> great example of how our documentation can exceed that of the RI.
>
> Best regards,
> George
>
>
>>>> 2. try to compatible with RI, by creating some adapter with RI's
>>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>>> not necessarily compatible with RI. we can even separate them all
>>>> to a
>>>> new component named as "compatibility", so that it is easily modify
>>>> them
>>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>>>
>>>
>>> IMHO, it is not the option. The word 'adapter' is used here only to
>>> soften
>>> the fact that we have to implement a set of com.sun.* classes. And
>>> definitely they won't be "compatible". So without them we are not
>>> "compatible" and with them were are not still "compatible" :-) Why
>>> we should
>>> do this?
>>>
>>>
>>>> 3. also try to compatible with RI, by maintaining pairs in
>>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>>> idea in fact.)
>>>>
>>>>
>>>
>>> Not quite clear what you mean. Do you suggest changing serialization
>>> framework? I mean that if it detects during deserialization, for
>>> example,
>>> sun.util.calendar.ZoneInfo it will substitute it with
>>> o.a.h.util.calendar.ZoneInfo. Right?
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
>>>
>>>> Mikhail
>>>>
>>>> Mikhail Loenko wrote:
>>>>
>>>>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>>>>
>>>>>
>>>>>> This is somewhat terrifying, isn't it? Are there really
>>>>>> references to
>>>>>> com.sun.* in serialized API objects?
>>>>>>
>>>>>>
>>>>> Yes, there are.
>>>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>>>
>>>>>
>>>> yes, and as I mentioned before, the TimeZone is composited by other
>>>> serializable class, so that all these classes cannot be serialization
>>>> compatible, feel like something as cancer :(
>>>>
>>>>> Can we list all the popular applications that exchange by serialized
>>>>>
>>>> objects
>>>>
>>>>> and identify which objects do they send/receive?
>>>>>
>>>>>
>>>> Rather than investigating almost infinite and uncertain(i.e. how to
>>>> define popular?) applications, I'd like to test all the serializable
>>>> class in JSE, at least it is a certain and limited set, we can just
>>>> find
>>>> all these kind of incompatibilities one by one, and take some actions.
>>>>
>>>> Currently, we have three options:
>>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>>> 2. try to compatible with RI, by creating some adapter with RI's
>>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>>> not necessarily compatible with RI. we can even separate them all
>>>> to a
>>>> new component named as "compatibility", so that it is easily modify
>>>> them
>>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>>> 3. also try to compatible with RI, by maintaining pairs in
>>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>>> idea in fact.)
>>>>
>>>> Any other good ideas?
>>>>
>>>> And before all of this, I cannot agree with Geir more - we should make
>>>> Sun be aware of this issue.
>>>>
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Paulex Yang
>>>> China Software Development Lab
>>>> IBM
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Richard Liang wrote:
> Stepan Mishura wrote:
>> Hi Paulex,
>>
>>
>>> Currently, we have three options:
>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>>
>>>
>>
>> I'd choose this option. It is open and honest - if we get unknown
>> class for
>> deserialization (say sun.util.calendar.ZoneInfo or
>> com.someCompanyName.util.MyTimeZone) we should not do any tricks and
>> create
>> illusion for a user that we know how to deserialize it. Also I don't
>> think
>> that "to be compatible" means to provide compatible implementation of
>> com.sun.* classes.
>>
>> IMHO, the best we can do in Harmony implementation is not to do the same
>> "serialization bug". I mean the following: factory methods of
>> TimeZone class
>> should return instances of SimpleTimeZone class. So Harmony
>> implementation
>> will produce serial form that will be deserializable on any other
>> implementation. However I don't know whether it is possible or not to
>> implement in this way.
>>
>>
> Agree. I'm just wondering what we shall say in Harmony JavaDoc. It's
> RI (SUN) who breaks its spec.
Hi Richard,
I sent a mail on this topic yesterday (maybe my mail client is playing
up again ?) : the RI Javadoc for the java.util.TimeZone method
getDefault() states that "The source of the default TimeZone may vary
with implementation". Given that I personally do not think that they are
breaking "the spec" in this instance : they are pretty much stating that
this method is dependent on the Java implementation.
IMHO, their Javadoc needs to make it clearer that the return from their
implementation of this method cannot be guaranteed to be interoperate
with other Java implementations. Likewise, the Harmony Javadoc for the
corresponding methods, and others like it that we have yet to discover,
should seek to remove all such ambiguities. This is a great example of
how our documentation can exceed that of the RI.
Best regards,
George
>>> 2. try to compatible with RI, by creating some adapter with RI's
>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>> not necessarily compatible with RI. we can even separate them all to a
>>> new component named as "compatibility", so that it is easily modify
>>> them
>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>>
>>
>> IMHO, it is not the option. The word 'adapter' is used here only to
>> soften
>> the fact that we have to implement a set of com.sun.* classes. And
>> definitely they won't be "compatible". So without them we are not
>> "compatible" and with them were are not still "compatible" :-) Why we
>> should
>> do this?
>>
>>
>>> 3. also try to compatible with RI, by maintaining pairs in
>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>> idea in fact.)
>>>
>>>
>>
>> Not quite clear what you mean. Do you suggest changing serialization
>> framework? I mean that if it detects during deserialization, for
>> example,
>> sun.util.calendar.ZoneInfo it will substitute it with
>> o.a.h.util.calendar.ZoneInfo. Right?
>>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>>
>> On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
>>
>>> Mikhail
>>>
>>> Mikhail Loenko wrote:
>>>
>>>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>>>
>>>>
>>>>> This is somewhat terrifying, isn't it? Are there really
>>>>> references to
>>>>> com.sun.* in serialized API objects?
>>>>>
>>>>>
>>>> Yes, there are.
>>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>>
>>>>
>>> yes, and as I mentioned before, the TimeZone is composited by other
>>> serializable class, so that all these classes cannot be serialization
>>> compatible, feel like something as cancer :(
>>>
>>>> Can we list all the popular applications that exchange by serialized
>>>>
>>> objects
>>>
>>>> and identify which objects do they send/receive?
>>>>
>>>>
>>> Rather than investigating almost infinite and uncertain(i.e. how to
>>> define popular?) applications, I'd like to test all the serializable
>>> class in JSE, at least it is a certain and limited set, we can just
>>> find
>>> all these kind of incompatibilities one by one, and take some actions.
>>>
>>> Currently, we have three options:
>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>> 2. try to compatible with RI, by creating some adapter with RI's
>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>> not necessarily compatible with RI. we can even separate them all to a
>>> new component named as "compatibility", so that it is easily modify
>>> them
>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>> 3. also try to compatible with RI, by maintaining pairs in
>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>> idea in fact.)
>>>
>>> Any other good ideas?
>>>
>>> And before all of this, I cannot agree with Geir more - we should make
>>> Sun be aware of this issue.
>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>>
>>>>
>>> --
>>> Paulex Yang
>>> China Software Development Lab
>>> IBM
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Richard Liang <ri...@gmail.com>.
Stepan Mishura wrote:
> Hi Paulex,
>
>
>> Currently, we have three options:
>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>
>>
>
> I'd choose this option. It is open and honest - if we get unknown class for
> deserialization (say sun.util.calendar.ZoneInfo or
> com.someCompanyName.util.MyTimeZone) we should not do any tricks and create
> illusion for a user that we know how to deserialize it. Also I don't think
> that "to be compatible" means to provide compatible implementation of
> com.sun.* classes.
>
> IMHO, the best we can do in Harmony implementation is not to do the same
> "serialization bug". I mean the following: factory methods of TimeZone class
> should return instances of SimpleTimeZone class. So Harmony implementation
> will produce serial form that will be deserializable on any other
> implementation. However I don't know whether it is possible or not to
> implement in this way.
>
>
Agree. I'm just wondering what we shall say in Harmony JavaDoc. It's RI
(SUN) who breaks its spec.
>> 2. try to compatible with RI, by creating some adapter with RI's
>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>> not necessarily compatible with RI. we can even separate them all to a
>> new component named as "compatibility", so that it is easily modify them
>> when RI changes its mind and improve. Not sure if it is legally fine.
>>
>
> IMHO, it is not the option. The word 'adapter' is used here only to soften
> the fact that we have to implement a set of com.sun.* classes. And
> definitely they won't be "compatible". So without them we are not
> "compatible" and with them were are not still "compatible" :-) Why we should
> do this?
>
>
>> 3. also try to compatible with RI, by maintaining pairs in
>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>> idea in fact.)
>>
>>
>
> Not quite clear what you mean. Do you suggest changing serialization
> framework? I mean that if it detects during deserialization, for example,
> sun.util.calendar.ZoneInfo it will substitute it with
> o.a.h.util.calendar.ZoneInfo. Right?
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
>
> On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
>
>> Mikhail
>>
>> Mikhail Loenko wrote:
>>
>>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>>
>>>
>>>> This is somewhat terrifying, isn't it? Are there really references to
>>>> com.sun.* in serialized API objects?
>>>>
>>>>
>>> Yes, there are.
>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>
>>>
>> yes, and as I mentioned before, the TimeZone is composited by other
>> serializable class, so that all these classes cannot be serialization
>> compatible, feel like something as cancer :(
>>
>>> Can we list all the popular applications that exchange by serialized
>>>
>> objects
>>
>>> and identify which objects do they send/receive?
>>>
>>>
>> Rather than investigating almost infinite and uncertain(i.e. how to
>> define popular?) applications, I'd like to test all the serializable
>> class in JSE, at least it is a certain and limited set, we can just find
>> all these kind of incompatibilities one by one, and take some actions.
>>
>> Currently, we have three options:
>> 1. let it be, and speak it loudly in Harmony JavaDoc
>> 2. try to compatible with RI, by creating some adapter with RI's
>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>> not necessarily compatible with RI. we can even separate them all to a
>> new component named as "compatibility", so that it is easily modify them
>> when RI changes its mind and improve. Not sure if it is legally fine.
>> 3. also try to compatible with RI, by maintaining pairs in
>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>> idea in fact.)
>>
>> Any other good ideas?
>>
>> And before all of this, I cannot agree with Geir more - we should make
>> Sun be aware of this issue.
>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by Stepan Mishura <st...@gmail.com>.
Hi Paulex,
>
>Currently, we have three options:
>1. let it be, and speak it loudly in Harmony JavaDoc
>
I'd choose this option. It is open and honest - if we get unknown class for
deserialization (say sun.util.calendar.ZoneInfo or
com.someCompanyName.util.MyTimeZone) we should not do any tricks and create
illusion for a user that we know how to deserialize it. Also I don't think
that "to be compatible" means to provide compatible implementation of
com.sun.* classes.
IMHO, the best we can do in Harmony implementation is not to do the same
"serialization bug". I mean the following: factory methods of TimeZone class
should return instances of SimpleTimeZone class. So Harmony implementation
will produce serial form that will be deserializable on any other
implementation. However I don't know whether it is possible or not to
implement in this way.
>
>2. try to compatible with RI, by creating some adapter with RI's
>serializable class name, i.e. com.sun.*, etc, and the behavior is even
>not necessarily compatible with RI. we can even separate them all to a
>new component named as "compatibility", so that it is easily modify them
>when RI changes its mind and improve. Not sure if it is legally fine.
IMHO, it is not the option. The word 'adapter' is used here only to soften
the fact that we have to implement a set of com.sun.* classes. And
definitely they won't be "compatible". So without them we are not
"compatible" and with them were are not still "compatible" :-) Why we should
do this?
>3. also try to compatible with RI, by maintaining pairs in
>ObjectInputStream, this approach maybe has less legal risk? (I have no
>idea in fact.)
>
Not quite clear what you mean. Do you suggest changing serialization
framework? I mean that if it detects during deserialization, for example,
sun.util.calendar.ZoneInfo it will substitute it with
o.a.h.util.calendar.ZoneInfo. Right?
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 3/8/06, Paulex Yang <pa...@gmail.com> wrote:
>
> Mikhail
>
> Mikhail Loenko wrote:
> > 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
> >
> >> This is somewhat terrifying, isn't it? Are there really references to
> >> com.sun.* in serialized API objects?
> >>
> >
> > Yes, there are.
> > For example, TimeZone.ser produced by the example from the JIRA issue
> > that started this thread, refers to "sun.util.calendar.ZoneInfo"
> >
> yes, and as I mentioned before, the TimeZone is composited by other
> serializable class, so that all these classes cannot be serialization
> compatible, feel like something as cancer :(
> > Can we list all the popular applications that exchange by serialized
> objects
> > and identify which objects do they send/receive?
> >
> Rather than investigating almost infinite and uncertain(i.e. how to
> define popular?) applications, I'd like to test all the serializable
> class in JSE, at least it is a certain and limited set, we can just find
> all these kind of incompatibilities one by one, and take some actions.
>
> Currently, we have three options:
> 1. let it be, and speak it loudly in Harmony JavaDoc
> 2. try to compatible with RI, by creating some adapter with RI's
> serializable class name, i.e. com.sun.*, etc, and the behavior is even
> not necessarily compatible with RI. we can even separate them all to a
> new component named as "compatibility", so that it is easily modify them
> when RI changes its mind and improve. Not sure if it is legally fine.
> 3. also try to compatible with RI, by maintaining pairs in
> ObjectInputStream, this approach maybe has less legal risk? (I have no
> idea in fact.)
>
> Any other good ideas?
>
> And before all of this, I cannot agree with Geir more - we should make
> Sun be aware of this issue.
> > Thanks,
> > Mikhail
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: Location of test data files
Posted by Tim Ellison <t....@gmail.com>.
Why not describe it in a doc, and submit it for the website?
Regards,
Tim
George Harley wrote:
> Hi Stepan,
>
> Good idea. I will raise it today. It will only cover the proposed layout
> of these test resources in a given module and not discuss how the
> serialization tests are carried out since that discussion is still ongoing.
>
> Best regards,
> George
>
>
> Stepan Mishura wrote:
>> Hi George,
>>
>> I'd like to fix outcome of this discussion. I think a JIRA issue should
>> filed to track tests reorg. As far as it'll be next massive reorg. and
>> can
>> not be applied right now (there are other massive updates pending in
>> JIRA).
>> And JIRA won't let us to forget about our decision.
>>
>> Thanks,
>> Stepan
>>
>>
>> On 3/14/06, George Harley wrote:
>>
>>> Stepan Mishura wrote:
>>>
>>>> On 3/13/06, George Harley wrote:
>>>>
>>>>
>>>>> Richard Liang wrote:
>>>>>
>>>>>
>>>>>> George Harley wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Mikhail (again),
>>>>>>>
>>>>>>> Just a couple of brief observations about the SerializationTest.java
>>>>>>> code as it stands in SVN today :
>>>>>>>
>>>>>>> 1) The reference/golden .dat files for Serializable classes in a
>>>>>>> given module could be added under the module's src/test/resources
>>>>>>> directory (in sub-folders corresponding to their package names). In
>>>>>>> an Ant build these would be copied under the test bin using a
>>>>>>> tweaked
>>>>>>> version of the "copy-test-resources" target (see the proposed
>>>>>>> changes
>>>>>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
>>>>>>> would make the .dat files available from the classpath.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hello George,
>>>>>>
>>>>>> It's good to put all test data files for one module into one folder,
>>>>>> such as "src/test/resources". However, there may be other options,
>>>>>> personally I'd like to put the test data file into the same directory
>>>>>> of the test case which uses the data file. This may make the
>>>>>> maintenance work easy. :-)
>>>>>> Anyway, I think we shall follow the same style.
>>>>>>
>>>>>>
>>>>> Hi Richard,
>>>>>
>>>>> Just to avoid any ambiguity here, what I proposed was to place the
>>>>> reference serialization files *under* a given module's
>>>>> src/test/resources folder in sub-folders that matched the package name
>>>>> of the test class - and not just have them all in one folder.
>>>>>
>>>>> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
>>>>> located in the folder
>>>>> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>>>>>
>>>>> Another alternative would be to use a tree structure that mirrored the
>>>>> package name of the Serializable type under test.
>>>>> e.g.
>>>>>
>>>>>
>>>>>
>>> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
>>>
>>>
>>>> To make it more clear because we talked only about data files for
>>>>
>>> testing
>>>
>>>> serialization but I'm aware of all resource files. So we have the
>>>>
>>> following
>>>
>>>> proposal:
>>>> <MODULE_ROOT>/src/test/resources
>>>> img/ <== image files
>>>> net/ <== net resource files
>>>> other/ <== disembodied files, for example, policy files
>>>> serialization/ <== data files for serialization
>>>>
>>>> And during the build all resource files will be copied to:
>>>>
>>> build/resources
>>>
>>>> directory. Right?
>>>>
>>>> Thanks,
>>>> Stepan
>>>>
>>>>
>>>>
>>> Hi Stepan,
>>>
>>> Yes, that sounds great - with the very minor suggestion that at build
>>> time these test resource files go to their corresponding sub-directories
>>> under the test bin (e.g. bin/test) which is separate from the bin folder
>>> (e.g. bin/main) that the stuff getting tested is compiled to.
>>>
>>> Best regards,
>>> George
>>>
>>>
>>>
>>>> I think that separating out all test artefacts from actual source code
>>>>
>>>>
>>>>> is cleaner and IMHO makes the maintenance easier :-)
>>>>>
>>>>> Using either Ant or <IDE of choice> it is pretty straightforward to
>>>>> get
>>>>> these resources placed on the classpath when the tests are run.
>>>>>
>>>>>
>>>>> Best regards,
>>>>> George
>>>>>
>>>>>
>>>>>
>>>>>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
>>>>>>> method getDataFile() were updated to use java.net.URI.
>>>>>>> e.g,
>>>>>>>
>>>>>>> protected File getDataFile(int index) {
>>>>>>> String name = "/" + this.getClass().getName().replace('.', '/') +
>>>>>>>
>>>>>>>
>>>>> "."
>>>>>
>>>>>
>>>>>>> + index + ".dat";
>>>>>>> return new
>>>>>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>>>>>
>>>>>>>
>>>>>>> It seems to me that the src/test/resources directory would be an
>>>>>>> ideal place to keep a module's reference .dat files.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> George
>>>>>>>
>>>>>>>
>>>>>>> George Harley wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Mikhail Loenko wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> BTW, there is a framework for serialization testing which is
>>>>>>>>>
>>>>>>>>>
>>>>> currently
>>>>>
>>>>>
>>>>>>>>> in the security module:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>
>>>
>>>>>>>>> It serves to simplify serialization testing and has the docs
>>>>>>>>> inside. Actually
>>>>>>>>> almost all serializable security-related classes are tested with
>>>>>>>>> this framework.
>>>>>>>>>
>>>>>>>>> Does it make sense to move the framework to a common place?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hi Mikhail !
>>>>>>>>
>>>>>>>> I've spent a little bit of time running this (with a couple of my
>>>>>>>>
>>> own
>>>
>>>>>>>> little concrete subclasses of SerializationTest) and I really like
>>>>>>>>
>>> it.
>>>
>>>>>>>> It was pretty straightforward to create a JUnit error for the case
>>>>>>>>
>>> of
>>>
>>>>>>>> java.util.TimeZone after my overridden version of getData() used
>>>>>>>> TimeZone.getDefault() to generate a couple of TimeZone instances
>>>>>>>>
>>> from
>>>
>>>>>>>> the RI.
>>>>>>>>
>>>>>>>> I can definitely see a case for broadening this approach outside
>>>>>>>>
>>> just
>>>
>>>>>>>> the security classes. Really impressive stuff !
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> George
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mikhail
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> --
>>>> Thanks,
>>>> Stepan Mishura
>>>> Intel Middleware Products Division
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
Hi Stepan,
Good idea. I will raise it today. It will only cover the proposed layout
of these test resources in a given module and not discuss how the
serialization tests are carried out since that discussion is still ongoing.
Best regards,
George
Stepan Mishura wrote:
> Hi George,
>
> I'd like to fix outcome of this discussion. I think a JIRA issue should
> filed to track tests reorg. As far as it'll be next massive reorg. and can
> not be applied right now (there are other massive updates pending in JIRA).
> And JIRA won't let us to forget about our decision.
>
> Thanks,
> Stepan
>
>
> On 3/14/06, George Harley wrote:
>
>> Stepan Mishura wrote:
>>
>>> On 3/13/06, George Harley wrote:
>>>
>>>
>>>> Richard Liang wrote:
>>>>
>>>>
>>>>> George Harley wrote:
>>>>>
>>>>>
>>>>>> Hi Mikhail (again),
>>>>>>
>>>>>> Just a couple of brief observations about the SerializationTest.java
>>>>>> code as it stands in SVN today :
>>>>>>
>>>>>> 1) The reference/golden .dat files for Serializable classes in a
>>>>>> given module could be added under the module's src/test/resources
>>>>>> directory (in sub-folders corresponding to their package names). In
>>>>>> an Ant build these would be copied under the test bin using a tweaked
>>>>>> version of the "copy-test-resources" target (see the proposed changes
>>>>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
>>>>>> would make the .dat files available from the classpath.
>>>>>>
>>>>>>
>>>>>>
>>>>> Hello George,
>>>>>
>>>>> It's good to put all test data files for one module into one folder,
>>>>> such as "src/test/resources". However, there may be other options,
>>>>> personally I'd like to put the test data file into the same directory
>>>>> of the test case which uses the data file. This may make the
>>>>> maintenance work easy. :-)
>>>>> Anyway, I think we shall follow the same style.
>>>>>
>>>>>
>>>> Hi Richard,
>>>>
>>>> Just to avoid any ambiguity here, what I proposed was to place the
>>>> reference serialization files *under* a given module's
>>>> src/test/resources folder in sub-folders that matched the package name
>>>> of the test class - and not just have them all in one folder.
>>>>
>>>> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
>>>> located in the folder
>>>> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>>>>
>>>> Another alternative would be to use a tree structure that mirrored the
>>>> package name of the Serializable type under test.
>>>> e.g.
>>>>
>>>>
>>>>
>> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
>>
>>> To make it more clear because we talked only about data files for
>>>
>> testing
>>
>>> serialization but I'm aware of all resource files. So we have the
>>>
>> following
>>
>>> proposal:
>>> <MODULE_ROOT>/src/test/resources
>>> img/ <== image files
>>> net/ <== net resource files
>>> other/ <== disembodied files, for example, policy files
>>> serialization/ <== data files for serialization
>>>
>>> And during the build all resource files will be copied to:
>>>
>> build/resources
>>
>>> directory. Right?
>>>
>>> Thanks,
>>> Stepan
>>>
>>>
>>>
>> Hi Stepan,
>>
>> Yes, that sounds great - with the very minor suggestion that at build
>> time these test resource files go to their corresponding sub-directories
>> under the test bin (e.g. bin/test) which is separate from the bin folder
>> (e.g. bin/main) that the stuff getting tested is compiled to.
>>
>> Best regards,
>> George
>>
>>
>>
>>> I think that separating out all test artefacts from actual source code
>>>
>>>
>>>> is cleaner and IMHO makes the maintenance easier :-)
>>>>
>>>> Using either Ant or <IDE of choice> it is pretty straightforward to get
>>>> these resources placed on the classpath when the tests are run.
>>>>
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>
>>>>
>>>>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
>>>>>> method getDataFile() were updated to use java.net.URI.
>>>>>> e.g,
>>>>>>
>>>>>> protected File getDataFile(int index) {
>>>>>> String name = "/" + this.getClass().getName().replace('.', '/') +
>>>>>>
>>>>>>
>>>> "."
>>>>
>>>>
>>>>>> + index + ".dat";
>>>>>> return new
>>>>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>>>>
>>>>>>
>>>>>> It seems to me that the src/test/resources directory would be an
>>>>>> ideal place to keep a module's reference .dat files.
>>>>>>
>>>>>> Best regards,
>>>>>> George
>>>>>>
>>>>>>
>>>>>> George Harley wrote:
>>>>>>
>>>>>>
>>>>>>> Mikhail Loenko wrote:
>>>>>>>
>>>>>>>
>>>>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> BTW, there is a framework for serialization testing which is
>>>>>>>>
>>>>>>>>
>>>> currently
>>>>
>>>>
>>>>>>>> in the security module:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>
>>>>>>>> It serves to simplify serialization testing and has the docs
>>>>>>>> inside. Actually
>>>>>>>> almost all serializable security-related classes are tested with
>>>>>>>> this framework.
>>>>>>>>
>>>>>>>> Does it make sense to move the framework to a common place?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Mikhail !
>>>>>>>
>>>>>>> I've spent a little bit of time running this (with a couple of my
>>>>>>>
>> own
>>
>>>>>>> little concrete subclasses of SerializationTest) and I really like
>>>>>>>
>> it.
>>
>>>>>>> It was pretty straightforward to create a JUnit error for the case
>>>>>>>
>> of
>>
>>>>>>> java.util.TimeZone after my overridden version of getData() used
>>>>>>> TimeZone.getDefault() to generate a couple of TimeZone instances
>>>>>>>
>> from
>>
>>>>>>> the RI.
>>>>>>>
>>>>>>> I can definitely see a case for broadening this approach outside
>>>>>>>
>> just
>>
>>>>>>> the security classes. Really impressive stuff !
>>>>>>>
>>>>>>> Best regards,
>>>>>>> George
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikhail
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> --
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
Re: Location of test data files
Posted by Stepan Mishura <st...@gmail.com>.
Hi George,
I'd like to fix outcome of this discussion. I think a JIRA issue should
filed to track tests reorg. As far as it'll be next massive reorg. and can
not be applied right now (there are other massive updates pending in JIRA).
And JIRA won't let us to forget about our decision.
Thanks,
Stepan
On 3/14/06, George Harley wrote:
>
> Stepan Mishura wrote:
> > On 3/13/06, George Harley wrote:
> >
> >> Richard Liang wrote:
> >>
> >>> George Harley wrote:
> >>>
> >>>> Hi Mikhail (again),
> >>>>
> >>>> Just a couple of brief observations about the SerializationTest.java
> >>>> code as it stands in SVN today :
> >>>>
> >>>> 1) The reference/golden .dat files for Serializable classes in a
> >>>> given module could be added under the module's src/test/resources
> >>>> directory (in sub-folders corresponding to their package names). In
> >>>> an Ant build these would be copied under the test bin using a tweaked
> >>>> version of the "copy-test-resources" target (see the proposed changes
> >>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
> >>>> would make the .dat files available from the classpath.
> >>>>
> >>>>
> >>> Hello George,
> >>>
> >>> It's good to put all test data files for one module into one folder,
> >>> such as "src/test/resources". However, there may be other options,
> >>> personally I'd like to put the test data file into the same directory
> >>> of the test case which uses the data file. This may make the
> >>> maintenance work easy. :-)
> >>> Anyway, I think we shall follow the same style.
> >>>
> >> Hi Richard,
> >>
> >> Just to avoid any ambiguity here, what I proposed was to place the
> >> reference serialization files *under* a given module's
> >> src/test/resources folder in sub-folders that matched the package name
> >> of the test class - and not just have them all in one folder.
> >>
> >> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
> >> located in the folder
> >> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
> >>
> >> Another alternative would be to use a tree structure that mirrored the
> >> package name of the Serializable type under test.
> >> e.g.
> >>
> >>
> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
> >>
> >
> >
> > To make it more clear because we talked only about data files for
> testing
> > serialization but I'm aware of all resource files. So we have the
> following
> > proposal:
> > <MODULE_ROOT>/src/test/resources
> > img/ <== image files
> > net/ <== net resource files
> > other/ <== disembodied files, for example, policy files
> > serialization/ <== data files for serialization
> >
> > And during the build all resource files will be copied to:
> build/resources
> > directory. Right?
> >
> > Thanks,
> > Stepan
> >
> >
>
> Hi Stepan,
>
> Yes, that sounds great - with the very minor suggestion that at build
> time these test resource files go to their corresponding sub-directories
> under the test bin (e.g. bin/test) which is separate from the bin folder
> (e.g. bin/main) that the stuff getting tested is compiled to.
>
> Best regards,
> George
>
>
> > I think that separating out all test artefacts from actual source code
> >
> >> is cleaner and IMHO makes the maintenance easier :-)
> >>
> >> Using either Ant or <IDE of choice> it is pretty straightforward to get
> >> these resources placed on the classpath when the tests are run.
> >>
> >>
> >> Best regards,
> >> George
> >>
> >>
> >>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
> >>>> method getDataFile() were updated to use java.net.URI.
> >>>> e.g,
> >>>>
> >>>> protected File getDataFile(int index) {
> >>>> String name = "/" + this.getClass().getName().replace('.', '/') +
> >>>>
> >> "."
> >>
> >>>> + index + ".dat";
> >>>> return new
> >>>> File(URI.create(this.getClass().getResource(name).toString()));
> >>>>
> >>>>
> >>>> It seems to me that the src/test/resources directory would be an
> >>>> ideal place to keep a module's reference .dat files.
> >>>>
> >>>> Best regards,
> >>>> George
> >>>>
> >>>>
> >>>> George Harley wrote:
> >>>>
> >>>>> Mikhail Loenko wrote:
> >>>>>
> >>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
> >>>>>> ...
> >>>>>>
> >>>>>>
> >>>>>>> Such a testing effort still sounds pretty daunting though.
> >>>>>>>
> >>>>>>>
> >>>>>> BTW, there is a framework for serialization testing which is
> >>>>>>
> >> currently
> >>
> >>>>>> in the security module:
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
> >>
> >>>>>> It serves to simplify serialization testing and has the docs
> >>>>>> inside. Actually
> >>>>>> almost all serializable security-related classes are tested with
> >>>>>> this framework.
> >>>>>>
> >>>>>> Does it make sense to move the framework to a common place?
> >>>>>>
> >>>>>>
> >>>>> Hi Mikhail !
> >>>>>
> >>>>> I've spent a little bit of time running this (with a couple of my
> own
> >>>>> little concrete subclasses of SerializationTest) and I really like
> it.
> >>>>> It was pretty straightforward to create a JUnit error for the case
> of
> >>>>> java.util.TimeZone after my overridden version of getData() used
> >>>>> TimeZone.getDefault() to generate a couple of TimeZone instances
> from
> >>>>> the RI.
> >>>>>
> >>>>> I can definitely see a case for broadening this approach outside
> just
> >>>>> the security classes. Really impressive stuff !
> >>>>>
> >>>>> Best regards,
> >>>>> George
> >>>>>
> >>>>>
> >>>>>> Thanks,
> >>>>>> Mikhail
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: Location of test data files
Posted by Stepan Mishura <st...@gmail.com>.
Hi George,
>
>Yes, that sounds great - with the very minor suggestion that at build
>time these test resource files go to their corresponding sub-directories
>under the test bin (e.g. bin/test) which is separate from the bin folder
>(e.g. bin/main) that the stuff getting tested is compiled to.
>
Agree.
Thanks,
Stepan.
On 3/14/06, George Harley wrote:
>
> Stepan Mishura wrote:
> > On 3/13/06, George Harley wrote:
> >
> >> Richard Liang wrote:
> >>
> >>> George Harley wrote:
> >>>
> >>>> Hi Mikhail (again),
> >>>>
> >>>> Just a couple of brief observations about the SerializationTest.java
> >>>> code as it stands in SVN today :
> >>>>
> >>>> 1) The reference/golden .dat files for Serializable classes in a
> >>>> given module could be added under the module's src/test/resources
> >>>> directory (in sub-folders corresponding to their package names). In
> >>>> an Ant build these would be copied under the test bin using a tweaked
> >>>> version of the "copy-test-resources" target (see the proposed changes
> >>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
> >>>> would make the .dat files available from the classpath.
> >>>>
> >>>>
> >>> Hello George,
> >>>
> >>> It's good to put all test data files for one module into one folder,
> >>> such as "src/test/resources". However, there may be other options,
> >>> personally I'd like to put the test data file into the same directory
> >>> of the test case which uses the data file. This may make the
> >>> maintenance work easy. :-)
> >>> Anyway, I think we shall follow the same style.
> >>>
> >> Hi Richard,
> >>
> >> Just to avoid any ambiguity here, what I proposed was to place the
> >> reference serialization files *under* a given module's
> >> src/test/resources folder in sub-folders that matched the package name
> >> of the test class - and not just have them all in one folder.
> >>
> >> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
> >> located in the folder
> >> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
> >>
> >> Another alternative would be to use a tree structure that mirrored the
> >> package name of the Serializable type under test.
> >> e.g.
> >>
> >>
> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
> >>
> >
> >
> > To make it more clear because we talked only about data files for
> testing
> > serialization but I'm aware of all resource files. So we have the
> following
> > proposal:
> > <MODULE_ROOT>/src/test/resources
> > img/ <== image files
> > net/ <== net resource files
> > other/ <== disembodied files, for example, policy files
> > serialization/ <== data files for serialization
> >
> > And during the build all resource files will be copied to:
> build/resources
> > directory. Right?
> >
> > Thanks,
> > Stepan
> >
> >
>
> Hi Stepan,
>
> Yes, that sounds great - with the very minor suggestion that at build
> time these test resource files go to their corresponding sub-directories
> under the test bin (e.g. bin/test) which is separate from the bin folder
> (e.g. bin/main) that the stuff getting tested is compiled to.
>
> Best regards,
> George
>
>
> > I think that separating out all test artefacts from actual source code
> >
> >> is cleaner and IMHO makes the maintenance easier :-)
> >>
> >> Using either Ant or <IDE of choice> it is pretty straightforward to get
> >> these resources placed on the classpath when the tests are run.
> >>
> >>
> >> Best regards,
> >> George
> >>
> >>
> >>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
> >>>> method getDataFile() were updated to use java.net.URI.
> >>>> e.g,
> >>>>
> >>>> protected File getDataFile(int index) {
> >>>> String name = "/" + this.getClass().getName().replace('.', '/') +
> >>>>
> >> "."
> >>
> >>>> + index + ".dat";
> >>>> return new
> >>>> File(URI.create(this.getClass().getResource(name).toString()));
> >>>>
> >>>>
> >>>> It seems to me that the src/test/resources directory would be an
> >>>> ideal place to keep a module's reference .dat files.
> >>>>
> >>>> Best regards,
> >>>> George
> >>>>
> >>>>
> >>>> George Harley wrote:
> >>>>
> >>>>> Mikhail Loenko wrote:
> >>>>>
> >>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
> >>>>>> ...
> >>>>>>
> >>>>>>
> >>>>>>> Such a testing effort still sounds pretty daunting though.
> >>>>>>>
> >>>>>>>
> >>>>>> BTW, there is a framework for serialization testing which is
> >>>>>>
> >> currently
> >>
> >>>>>> in the security module:
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
> >>
> >>>>>> It serves to simplify serialization testing and has the docs
> >>>>>> inside. Actually
> >>>>>> almost all serializable security-related classes are tested with
> >>>>>> this framework.
> >>>>>>
> >>>>>> Does it make sense to move the framework to a common place?
> >>>>>>
> >>>>>>
> >>>>> Hi Mikhail !
> >>>>>
> >>>>> I've spent a little bit of time running this (with a couple of my
> own
> >>>>> little concrete subclasses of SerializationTest) and I really like
> it.
> >>>>> It was pretty straightforward to create a JUnit error for the case
> of
> >>>>> java.util.TimeZone after my overridden version of getData() used
> >>>>> TimeZone.getDefault() to generate a couple of TimeZone instances
> from
> >>>>> the RI.
> >>>>>
> >>>>> I can definitely see a case for broadening this approach outside
> just
> >>>>> the security classes. Really impressive stuff !
> >>>>>
> >>>>> Best regards,
> >>>>> George
> >>>>>
> >>>>>
> >>>>>> Thanks,
> >>>>>> Mikhail
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: Location of test data files
Posted by Richard Liang <ri...@gmail.com>.
George Harley wrote:
> Stepan Mishura wrote:
>> On 3/13/06, George Harley wrote:
>>
>>> Richard Liang wrote:
>>>
>>>> George Harley wrote:
>>>>
>>>>> Hi Mikhail (again),
>>>>>
>>>>> Just a couple of brief observations about the SerializationTest.java
>>>>> code as it stands in SVN today :
>>>>>
>>>>> 1) The reference/golden .dat files for Serializable classes in a
>>>>> given module could be added under the module's src/test/resources
>>>>> directory (in sub-folders corresponding to their package names). In
>>>>> an Ant build these would be copied under the test bin using a tweaked
>>>>> version of the "copy-test-resources" target (see the proposed changes
>>>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
>>>>> would make the .dat files available from the classpath.
>>>>>
>>>>>
>>>> Hello George,
>>>>
>>>> It's good to put all test data files for one module into one folder,
>>>> such as "src/test/resources". However, there may be other options,
>>>> personally I'd like to put the test data file into the same directory
>>>> of the test case which uses the data file. This may make the
>>>> maintenance work easy. :-)
>>>> Anyway, I think we shall follow the same style.
>>>>
>>> Hi Richard,
>>>
>>> Just to avoid any ambiguity here, what I proposed was to place the
>>> reference serialization files *under* a given module's
>>> src/test/resources folder in sub-folders that matched the package name
>>> of the test class - and not just have them all in one folder.
>>>
>>> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
>>> located in the folder
>>> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>>>
>>> Another alternative would be to use a tree structure that mirrored the
>>> package name of the Serializable type under test.
>>> e.g.
>>>
>>> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
>>>
>>>
>>
>>
>> To make it more clear because we talked only about data files for
>> testing
>> serialization but I'm aware of all resource files. So we have the
>> following
>> proposal:
>> <MODULE_ROOT>/src/test/resources
>> img/ <== image files
>> net/ <== net resource files
>> other/ <== disembodied files, for example, policy files
>> serialization/ <== data files for serialization
>>
>> And during the build all resource files will be copied to:
>> build/resources
>> directory. Right?
>>
>> Thanks,
>> Stepan
>>
>>
>
> Hi Stepan,
>
> Yes, that sounds great - with the very minor suggestion that at build
> time these test resource files go to their corresponding
> sub-directories under the test bin (e.g. bin/test) which is separate
> from the bin folder (e.g. bin/main) that the stuff getting tested is
> compiled to.
>
> Best regards,
> George
>
>
Hello George,
It's good. :-)
>> I think that separating out all test artefacts from actual source code
>>
>>> is cleaner and IMHO makes the maintenance easier :-)
>>>
>>> Using either Ant or <IDE of choice> it is pretty straightforward to get
>>> these resources placed on the classpath when the tests are run.
>>>
>>>
>>> Best regards,
>>> George
>>>
>>>
>>>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
>>>>> method getDataFile() were updated to use java.net.URI.
>>>>> e.g,
>>>>>
>>>>> protected File getDataFile(int index) {
>>>>> String name = "/" + this.getClass().getName().replace('.', '/') +
>>>>>
>>> "."
>>>
>>>>> + index + ".dat";
>>>>> return new
>>>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>>>
>>>>>
>>>>> It seems to me that the src/test/resources directory would be an
>>>>> ideal place to keep a module's reference .dat files.
>>>>>
>>>>> Best regards,
>>>>> George
>>>>>
>>>>>
>>>>> George Harley wrote:
>>>>>
>>>>>> Mikhail Loenko wrote:
>>>>>>
>>>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>>>
>>>>>>>>
>>>>>>> BTW, there is a framework for serialization testing which is
>>>>>>>
>>> currently
>>>
>>>>>>> in the security module:
>>>>>>>
>>>>>>>
>>>>>>>
>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>
>>>
>>>>>>> It serves to simplify serialization testing and has the docs
>>>>>>> inside. Actually
>>>>>>> almost all serializable security-related classes are tested with
>>>>>>> this framework.
>>>>>>>
>>>>>>> Does it make sense to move the framework to a common place?
>>>>>>>
>>>>>>>
>>>>>> Hi Mikhail !
>>>>>>
>>>>>> I've spent a little bit of time running this (with a couple of my
>>>>>> own
>>>>>> little concrete subclasses of SerializationTest) and I really
>>>>>> like it.
>>>>>> It was pretty straightforward to create a JUnit error for the
>>>>>> case of
>>>>>> java.util.TimeZone after my overridden version of getData() used
>>>>>> TimeZone.getDefault() to generate a couple of TimeZone instances
>>>>>> from
>>>>>> the RI.
>>>>>>
>>>>>> I can definitely see a case for broadening this approach outside
>>>>>> just
>>>>>> the security classes. Really impressive stuff !
>>>>>>
>>>>>> Best regards,
>>>>>> George
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Mikhail
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
Stepan Mishura wrote:
> On 3/13/06, George Harley wrote:
>
>> Richard Liang wrote:
>>
>>> George Harley wrote:
>>>
>>>> Hi Mikhail (again),
>>>>
>>>> Just a couple of brief observations about the SerializationTest.java
>>>> code as it stands in SVN today :
>>>>
>>>> 1) The reference/golden .dat files for Serializable classes in a
>>>> given module could be added under the module's src/test/resources
>>>> directory (in sub-folders corresponding to their package names). In
>>>> an Ant build these would be copied under the test bin using a tweaked
>>>> version of the "copy-test-resources" target (see the proposed changes
>>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
>>>> would make the .dat files available from the classpath.
>>>>
>>>>
>>> Hello George,
>>>
>>> It's good to put all test data files for one module into one folder,
>>> such as "src/test/resources". However, there may be other options,
>>> personally I'd like to put the test data file into the same directory
>>> of the test case which uses the data file. This may make the
>>> maintenance work easy. :-)
>>> Anyway, I think we shall follow the same style.
>>>
>> Hi Richard,
>>
>> Just to avoid any ambiguity here, what I proposed was to place the
>> reference serialization files *under* a given module's
>> src/test/resources folder in sub-folders that matched the package name
>> of the test class - and not just have them all in one folder.
>>
>> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
>> located in the folder
>> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>>
>> Another alternative would be to use a tree structure that mirrored the
>> package name of the Serializable type under test.
>> e.g.
>>
>> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
>>
>
>
> To make it more clear because we talked only about data files for testing
> serialization but I'm aware of all resource files. So we have the following
> proposal:
> <MODULE_ROOT>/src/test/resources
> img/ <== image files
> net/ <== net resource files
> other/ <== disembodied files, for example, policy files
> serialization/ <== data files for serialization
>
> And during the build all resource files will be copied to: build/resources
> directory. Right?
>
> Thanks,
> Stepan
>
>
Hi Stepan,
Yes, that sounds great - with the very minor suggestion that at build
time these test resource files go to their corresponding sub-directories
under the test bin (e.g. bin/test) which is separate from the bin folder
(e.g. bin/main) that the stuff getting tested is compiled to.
Best regards,
George
> I think that separating out all test artefacts from actual source code
>
>> is cleaner and IMHO makes the maintenance easier :-)
>>
>> Using either Ant or <IDE of choice> it is pretty straightforward to get
>> these resources placed on the classpath when the tests are run.
>>
>>
>> Best regards,
>> George
>>
>>
>>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
>>>> method getDataFile() were updated to use java.net.URI.
>>>> e.g,
>>>>
>>>> protected File getDataFile(int index) {
>>>> String name = "/" + this.getClass().getName().replace('.', '/') +
>>>>
>> "."
>>
>>>> + index + ".dat";
>>>> return new
>>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>>
>>>>
>>>> It seems to me that the src/test/resources directory would be an
>>>> ideal place to keep a module's reference .dat files.
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>
>>>> George Harley wrote:
>>>>
>>>>> Mikhail Loenko wrote:
>>>>>
>>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>>>> ...
>>>>>>
>>>>>>
>>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>>
>>>>>>>
>>>>>> BTW, there is a framework for serialization testing which is
>>>>>>
>> currently
>>
>>>>>> in the security module:
>>>>>>
>>>>>>
>>>>>>
>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>
>>>>>> It serves to simplify serialization testing and has the docs
>>>>>> inside. Actually
>>>>>> almost all serializable security-related classes are tested with
>>>>>> this framework.
>>>>>>
>>>>>> Does it make sense to move the framework to a common place?
>>>>>>
>>>>>>
>>>>> Hi Mikhail !
>>>>>
>>>>> I've spent a little bit of time running this (with a couple of my own
>>>>> little concrete subclasses of SerializationTest) and I really like it.
>>>>> It was pretty straightforward to create a JUnit error for the case of
>>>>> java.util.TimeZone after my overridden version of getData() used
>>>>> TimeZone.getDefault() to generate a couple of TimeZone instances from
>>>>> the RI.
>>>>>
>>>>> I can definitely see a case for broadening this approach outside just
>>>>> the security classes. Really impressive stuff !
>>>>>
>>>>> Best regards,
>>>>> George
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Mikhail
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
Re: Location of test data files
Posted by Stepan Mishura <st...@gmail.com>.
On 3/13/06, George Harley wrote:
>
> Richard Liang wrote:
> > George Harley wrote:
> >> Hi Mikhail (again),
> >>
> >> Just a couple of brief observations about the SerializationTest.java
> >> code as it stands in SVN today :
> >>
> >> 1) The reference/golden .dat files for Serializable classes in a
> >> given module could be added under the module's src/test/resources
> >> directory (in sub-folders corresponding to their package names). In
> >> an Ant build these would be copied under the test bin using a tweaked
> >> version of the "copy-test-resources" target (see the proposed changes
> >> to make/build-java.xml contained in the HARMONY-57). At runtime this
> >> would make the .dat files available from the classpath.
> >>
> > Hello George,
> >
> > It's good to put all test data files for one module into one folder,
> > such as "src/test/resources". However, there may be other options,
> > personally I'd like to put the test data file into the same directory
> > of the test case which uses the data file. This may make the
> > maintenance work easy. :-)
> > Anyway, I think we shall follow the same style.
>
> Hi Richard,
>
> Just to avoid any ambiguity here, what I proposed was to place the
> reference serialization files *under* a given module's
> src/test/resources folder in sub-folders that matched the package name
> of the test class - and not just have them all in one folder.
>
> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
> located in the folder
> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>
> Another alternative would be to use a tree structure that mirrored the
> package name of the Serializable type under test.
> e.g.
>
> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
To make it more clear because we talked only about data files for testing
serialization but I'm aware of all resource files. So we have the following
proposal:
<MODULE_ROOT>/src/test/resources
img/ <== image files
net/ <== net resource files
other/ <== disembodied files, for example, policy files
serialization/ <== data files for serialization
And during the build all resource files will be copied to: build/resources
directory. Right?
Thanks,
Stepan
I think that separating out all test artefacts from actual source code
> is cleaner and IMHO makes the maintenance easier :-)
>
> Using either Ant or <IDE of choice> it is pretty straightforward to get
> these resources placed on the classpath when the tests are run.
>
>
> Best regards,
> George
>
> >
> >> 2) The need for the "TEST_SRC_DIR" system property goes away if
> >> method getDataFile() were updated to use java.net.URI.
> >> e.g,
> >>
> >> protected File getDataFile(int index) {
> >> String name = "/" + this.getClass().getName().replace('.', '/') +
> "."
> >> + index + ".dat";
> >> return new
> >> File(URI.create(this.getClass().getResource(name).toString()));
> >>
> >>
> >> It seems to me that the src/test/resources directory would be an
> >> ideal place to keep a module's reference .dat files.
> >>
> >> Best regards,
> >> George
> >>
> >>
> >> George Harley wrote:
> >>> Mikhail Loenko wrote:
> >>>> 2006/3/9, George Harley <ge...@googlemail.com>:
> >>>> ...
> >>>>
> >>>>> Such a testing effort still sounds pretty daunting though.
> >>>>>
> >>>>
> >>>> BTW, there is a framework for serialization testing which is
> currently
> >>>> in the security module:
> >>>>
> >>>>
> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
> >>>>
> >>>>
> >>>> It serves to simplify serialization testing and has the docs
> >>>> inside. Actually
> >>>> almost all serializable security-related classes are tested with
> >>>> this framework.
> >>>>
> >>>> Does it make sense to move the framework to a common place?
> >>>>
> >>>
> >>> Hi Mikhail !
> >>>
> >>> I've spent a little bit of time running this (with a couple of my own
> >>> little concrete subclasses of SerializationTest) and I really like it.
> >>> It was pretty straightforward to create a JUnit error for the case of
> >>> java.util.TimeZone after my overridden version of getData() used
> >>> TimeZone.getDefault() to generate a couple of TimeZone instances from
> >>> the RI.
> >>>
> >>> I can definitely see a case for broadening this approach outside just
> >>> the security classes. Really impressive stuff !
> >>>
> >>> Best regards,
> >>> George
> >>>
> >>>> Thanks,
> >>>> Mikhail
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: Location of test data files
Posted by Geir Magnusson Jr <ge...@pobox.com>.
George Harley wrote:
> Richard Liang wrote:
>> George Harley wrote:
>>> Hi Mikhail (again),
>>>
>>> Just a couple of brief observations about the SerializationTest.java
>>> code as it stands in SVN today :
>>>
>>> 1) The reference/golden .dat files for Serializable classes in a
>>> given module could be added under the module's src/test/resources
>>> directory (in sub-folders corresponding to their package names). In
>>> an Ant build these would be copied under the test bin using a tweaked
>>> version of the "copy-test-resources" target (see the proposed changes
>>> to make/build-java.xml contained in the HARMONY-57). At runtime this
>>> would make the .dat files available from the classpath.
>>>
>> Hello George,
>>
>> It's good to put all test data files for one module into one folder,
>> such as "src/test/resources". However, there may be other options,
>> personally I'd like to put the test data file into the same directory
>> of the test case which uses the data file. This may make the
>> maintenance work easy. :-)
>> Anyway, I think we shall follow the same style.
>
> Hi Richard,
>
> Just to avoid any ambiguity here, what I proposed was to place the
> reference serialization files *under* a given module's
> src/test/resources folder in sub-folders that matched the package name
> of the test class - and not just have them all in one folder.
>
Great - that wasn't clear. This works for me.
geir
Re: Location of test data files
Posted by Richard Liang <ri...@gmail.com>.
George Harley wrote:
> Richard Liang wrote:
>> George Harley wrote:
>>> Hi Mikhail (again),
>>>
>>> Just a couple of brief observations about the SerializationTest.java
>>> code as it stands in SVN today :
>>>
>>> 1) The reference/golden .dat files for Serializable classes in a
>>> given module could be added under the module's src/test/resources
>>> directory (in sub-folders corresponding to their package names). In
>>> an Ant build these would be copied under the test bin using a
>>> tweaked version of the "copy-test-resources" target (see the
>>> proposed changes to make/build-java.xml contained in the
>>> HARMONY-57). At runtime this would make the .dat files available
>>> from the classpath.
>>>
>> Hello George,
>>
>> It's good to put all test data files for one module into one folder,
>> such as "src/test/resources". However, there may be other options,
>> personally I'd like to put the test data file into the same directory
>> of the test case which uses the data file. This may make the
>> maintenance work easy. :-)
>> Anyway, I think we shall follow the same style.
>
> Hi Richard,
>
> Just to avoid any ambiguity here, what I proposed was to place the
> reference serialization files *under* a given module's
> src/test/resources folder in sub-folders that matched the package name
> of the test class - and not just have them all in one folder.
>
Yes, George. That's make sense :-)
> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
> located in the folder
> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>
> Another alternative would be to use a tree structure that mirrored the
> package name of the Serializable type under test.
> e.g.
> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
>
>
>
> I think that separating out all test artefacts from actual source code
> is cleaner and IMHO makes the maintenance easier :-)
>
I think there is no big difference. But anyway we shall agree with one
of the three options.
1) Put test data files into a separated folder, and use the package name
of test case as its namespace.
e.g., <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
2) Put test data files into a separated folder, and use the package
name of the class under test as its namespace.
e.g.
<MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
3. Put test data files into the same location as the test case.
Shall we vote? :-)
> Using either Ant or <IDE of choice> it is pretty straightforward to
> get these resources placed on the classpath when the tests are run.
>
Yes. I think we all agree with this.
>
> Best regards,
> George
>
>>
>>> 2) The need for the "TEST_SRC_DIR" system property goes away if
>>> method getDataFile() were updated to use java.net.URI.
>>> e.g,
>>>
>>> protected File getDataFile(int index) {
>>> String name = "/" + this.getClass().getName().replace('.', '/') +
>>> "."
>>> + index + ".dat";
>>> return new
>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>
>>>
>>> It seems to me that the src/test/resources directory would be an
>>> ideal place to keep a module's reference .dat files.
>>>
>>> Best regards,
>>> George
>>>
>>>
>>> George Harley wrote:
>>>> Mikhail Loenko wrote:
>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>>> ...
>>>>>
>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>
>>>>>
>>>>> BTW, there is a framework for serialization testing which is
>>>>> currently
>>>>> in the security module:
>>>>>
>>>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>>>
>>>>>
>>>>> It serves to simplify serialization testing and has the docs
>>>>> inside. Actually
>>>>> almost all serializable security-related classes are tested with
>>>>> this framework.
>>>>>
>>>>> Does it make sense to move the framework to a common place?
>>>>>
>>>>
>>>> Hi Mikhail !
>>>>
>>>> I've spent a little bit of time running this (with a couple of my own
>>>> little concrete subclasses of SerializationTest) and I really like it.
>>>> It was pretty straightforward to create a JUnit error for the case of
>>>> java.util.TimeZone after my overridden version of getData() used
>>>> TimeZone.getDefault() to generate a couple of TimeZone instances from
>>>> the RI.
>>>>
>>>> I can definitely see a case for broadening this approach outside just
>>>> the security classes. Really impressive stuff !
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
Richard Liang wrote:
> George Harley wrote:
>> Hi Mikhail (again),
>>
>> Just a couple of brief observations about the SerializationTest.java
>> code as it stands in SVN today :
>>
>> 1) The reference/golden .dat files for Serializable classes in a
>> given module could be added under the module's src/test/resources
>> directory (in sub-folders corresponding to their package names). In
>> an Ant build these would be copied under the test bin using a tweaked
>> version of the "copy-test-resources" target (see the proposed changes
>> to make/build-java.xml contained in the HARMONY-57). At runtime this
>> would make the .dat files available from the classpath.
>>
> Hello George,
>
> It's good to put all test data files for one module into one folder,
> such as "src/test/resources". However, there may be other options,
> personally I'd like to put the test data file into the same directory
> of the test case which uses the data file. This may make the
> maintenance work easy. :-)
> Anyway, I think we shall follow the same style.
Hi Richard,
Just to avoid any ambiguity here, what I proposed was to place the
reference serialization files *under* a given module's
src/test/resources folder in sub-folders that matched the package name
of the test class - and not just have them all in one folder.
For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
located in the folder
<MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
Another alternative would be to use a tree structure that mirrored the
package name of the Serializable type under test.
e.g.
<MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
I think that separating out all test artefacts from actual source code
is cleaner and IMHO makes the maintenance easier :-)
Using either Ant or <IDE of choice> it is pretty straightforward to get
these resources placed on the classpath when the tests are run.
Best regards,
George
>
>> 2) The need for the "TEST_SRC_DIR" system property goes away if
>> method getDataFile() were updated to use java.net.URI.
>> e.g,
>>
>> protected File getDataFile(int index) {
>> String name = "/" + this.getClass().getName().replace('.', '/') + "."
>> + index + ".dat";
>> return new
>> File(URI.create(this.getClass().getResource(name).toString()));
>>
>>
>> It seems to me that the src/test/resources directory would be an
>> ideal place to keep a module's reference .dat files.
>>
>> Best regards,
>> George
>>
>>
>> George Harley wrote:
>>> Mikhail Loenko wrote:
>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>> ...
>>>>
>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>
>>>>
>>>> BTW, there is a framework for serialization testing which is currently
>>>> in the security module:
>>>>
>>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>>
>>>>
>>>> It serves to simplify serialization testing and has the docs
>>>> inside. Actually
>>>> almost all serializable security-related classes are tested with
>>>> this framework.
>>>>
>>>> Does it make sense to move the framework to a common place?
>>>>
>>>
>>> Hi Mikhail !
>>>
>>> I've spent a little bit of time running this (with a couple of my own
>>> little concrete subclasses of SerializationTest) and I really like it.
>>> It was pretty straightforward to create a JUnit error for the case of
>>> java.util.TimeZone after my overridden version of getData() used
>>> TimeZone.getDefault() to generate a couple of TimeZone instances from
>>> the RI.
>>>
>>> I can definitely see a case for broadening this approach outside just
>>> the security classes. Really impressive stuff !
>>>
>>> Best regards,
>>> George
>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Location of test data files
Posted by Geir Magnusson Jr <ge...@pobox.com>.
George Harley wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Richard Liang wrote:
>>> George Harley wrote:
>>>> Hi Mikhail (again),
>>>>
>>>> Just a couple of brief observations about the SerializationTest.java
>>>> code as it stands in SVN today :
>>>>
>>>> 1) The reference/golden .dat files for Serializable classes in a
>>>> given module could be added under the module's src/test/resources
>>>> directory (in sub-folders corresponding to their package names). In
>>>> an Ant build these would be copied under the test bin using a
>>>> tweaked version of the "copy-test-resources" target (see the
>>>> proposed changes to make/build-java.xml contained in the
>>>> HARMONY-57). At runtime this would make the .dat files available
>>>> from the classpath.
>>>>
>>> Hello George,
>>>
>>> It's good to put all test data files for one module into one folder,
>>> such as "src/test/resources". However, there may be other options,
>>> personally I'd like to put the test data file into the same directory
>>> of the test case which uses the data file. This may make the
>>> maintenance work easy. :-)
>>
>> Yes - for maintenance and name collision, this makes sense. That is
>> how security does it now.
>>
>> geir
>>
> Sorry, I don't understand the "name collision" issue. Could you explain ?
I guess it depends on what you are proposing, but if there isn't a
parallel package structure in resources/ as we have in java/ then we may
have file name collisions...
geir
>
> Best regards,
> George
>
>
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
Geir Magnusson Jr wrote:
>
>
> Richard Liang wrote:
>> George Harley wrote:
>>> Hi Mikhail (again),
>>>
>>> Just a couple of brief observations about the SerializationTest.java
>>> code as it stands in SVN today :
>>>
>>> 1) The reference/golden .dat files for Serializable classes in a
>>> given module could be added under the module's src/test/resources
>>> directory (in sub-folders corresponding to their package names). In
>>> an Ant build these would be copied under the test bin using a
>>> tweaked version of the "copy-test-resources" target (see the
>>> proposed changes to make/build-java.xml contained in the
>>> HARMONY-57). At runtime this would make the .dat files available
>>> from the classpath.
>>>
>> Hello George,
>>
>> It's good to put all test data files for one module into one folder,
>> such as "src/test/resources". However, there may be other options,
>> personally I'd like to put the test data file into the same directory
>> of the test case which uses the data file. This may make the
>> maintenance work easy. :-)
>
> Yes - for maintenance and name collision, this makes sense. That is
> how security does it now.
>
> geir
>
Sorry, I don't understand the "name collision" issue. Could you explain ?
Best regards,
George
Re: Location of test data files
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Richard Liang wrote:
> George Harley wrote:
>> Hi Mikhail (again),
>>
>> Just a couple of brief observations about the SerializationTest.java
>> code as it stands in SVN today :
>>
>> 1) The reference/golden .dat files for Serializable classes in a given
>> module could be added under the module's src/test/resources directory
>> (in sub-folders corresponding to their package names). In an Ant build
>> these would be copied under the test bin using a tweaked version of
>> the "copy-test-resources" target (see the proposed changes to
>> make/build-java.xml contained in the HARMONY-57). At runtime this
>> would make the .dat files available from the classpath.
>>
> Hello George,
>
> It's good to put all test data files for one module into one folder,
> such as "src/test/resources". However, there may be other options,
> personally I'd like to put the test data file into the same directory of
> the test case which uses the data file. This may make the maintenance
> work easy. :-)
Yes - for maintenance and name collision, this makes sense. That is how
security does it now.
geir
Location of test data files (was:How to deal with this kind of serialization
compatibility issue?)
Posted by Richard Liang <ri...@gmail.com>.
George Harley wrote:
> Hi Mikhail (again),
>
> Just a couple of brief observations about the SerializationTest.java
> code as it stands in SVN today :
>
> 1) The reference/golden .dat files for Serializable classes in a given
> module could be added under the module's src/test/resources directory
> (in sub-folders corresponding to their package names). In an Ant build
> these would be copied under the test bin using a tweaked version of
> the "copy-test-resources" target (see the proposed changes to
> make/build-java.xml contained in the HARMONY-57). At runtime this
> would make the .dat files available from the classpath.
>
Hello George,
It's good to put all test data files for one module into one folder,
such as "src/test/resources". However, there may be other options,
personally I'd like to put the test data file into the same directory of
the test case which uses the data file. This may make the maintenance
work easy. :-)
Anyway, I think we shall follow the same style.
> 2) The need for the "TEST_SRC_DIR" system property goes away if method
> getDataFile() were updated to use java.net.URI.
> e.g,
>
> protected File getDataFile(int index) {
> String name = "/" + this.getClass().getName().replace('.', '/') + "."
> + index + ".dat";
> return new
> File(URI.create(this.getClass().getResource(name).toString()));
>
>
> It seems to me that the src/test/resources directory would be an ideal
> place to keep a module's reference .dat files.
>
> Best regards,
> George
>
>
> George Harley wrote:
>> Mikhail Loenko wrote:
>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>> ...
>>>
>>>> Such a testing effort still sounds pretty daunting though.
>>>>
>>>
>>> BTW, there is a framework for serialization testing which is currently
>>> in the security module:
>>>
>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>
>>>
>>> It serves to simplify serialization testing and has the docs inside.
>>> Actually
>>> almost all serializable security-related classes are tested with
>>> this framework.
>>>
>>> Does it make sense to move the framework to a common place?
>>>
>>
>> Hi Mikhail !
>>
>> I've spent a little bit of time running this (with a couple of my own
>> little concrete subclasses of SerializationTest) and I really like it.
>> It was pretty straightforward to create a JUnit error for the case of
>> java.util.TimeZone after my overridden version of getData() used
>> TimeZone.getDefault() to generate a couple of TimeZone instances from
>> the RI.
>>
>> I can definitely see a case for broadening this approach outside just
>> the security classes. Really impressive stuff !
>>
>> Best regards,
>> George
>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>
>>
>>
>>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a given
module could be added under the module's src/test/resources directory
(in sub-folders corresponding to their package names). In an Ant build
these would be copied under the test bin using a tweaked version of the
"copy-test-resources" target (see the proposed changes to
make/build-java.xml contained in the HARMONY-57). At runtime this would
make the .dat files available from the classpath.
2) The need for the "TEST_SRC_DIR" system property goes away if method
getDataFile() were updated to use java.net.URI.
e.g,
protected File getDataFile(int index) {
String name = "/" + this.getClass().getName().replace('.', '/') + "."
+ index + ".dat";
return new
File(URI.create(this.getClass().getResource(name).toString()));
It seems to me that the src/test/resources directory would be an ideal
place to keep a module's reference .dat files.
Best regards,
George
George Harley wrote:
> Mikhail Loenko wrote:
>> 2006/3/9, George Harley <ge...@googlemail.com>:
>> ...
>>
>>> Such a testing effort still sounds pretty daunting though.
>>>
>>
>> BTW, there is a framework for serialization testing which is currently
>> in the security module:
>>
>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>
>>
>> It serves to simplify serialization testing and has the docs inside.
>> Actually
>> almost all serializable security-related classes are tested with this
>> framework.
>>
>> Does it make sense to move the framework to a common place?
>>
>
> Hi Mikhail !
>
> I've spent a little bit of time running this (with a couple of my own
> little concrete subclasses of SerializationTest) and I really like it.
> It was pretty straightforward to create a JUnit error for the case of
> java.util.TimeZone after my overridden version of getData() used
> TimeZone.getDefault() to generate a couple of TimeZone instances from
> the RI.
>
> I can definitely see a case for broadening this approach outside just
> the security classes. Really impressive stuff !
>
> Best regards,
> George
>
>> Thanks,
>> Mikhail
>>
>>
>
>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> 2006/3/9, George Harley <ge...@googlemail.com>:
> ...
>
>> Such a testing effort still sounds pretty daunting though.
>>
>
> BTW, there is a framework for serialization testing which is currently
> in the security module:
>
> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>
> It serves to simplify serialization testing and has the docs inside. Actually
> almost all serializable security-related classes are tested with this framework.
>
> Does it make sense to move the framework to a common place?
>
Hi Mikhail !
I've spent a little bit of time running this (with a couple of my own
little concrete subclasses of SerializationTest) and I really like it.
It was pretty straightforward to create a JUnit error for the case of
java.util.TimeZone after my overridden version of getData() used
TimeZone.getDefault() to generate a couple of TimeZone instances from
the RI.
I can definitely see a case for broadening this approach outside just
the security classes. Really impressive stuff !
Best regards,
George
> Thanks,
> Mikhail
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
Using serialization framework from security module,
the test would look like as follows:
public class CharacterCodingExceptionTest extends SerializationTest {
protected Object[] getData() {
return new Object[] { new CharacterCodingExceptionTest ()};
}
protected void assertDeserialized(Object oref, Object otest) {
CharacterCodingExceptionTest ref = (CharacterCodingExceptionTest ) oref;
CharacterCodingExceptionTest test =
(CharacterCodingExceptionTest ) otest;
assertNull(test.getMessage());
}
}
Thanks,
Mikhail
2006/3/15, Paulex Yang <pa...@gmail.com>:
> Hi, Mikhail,
>
> Mikhail Loenko wrote:
> > Hi George!
> >
> >
> >> I need to study H-57 SerializationTester, likely it makes sense taking
> >> best ideas from both
> >>
> >
> > I was trying to find out how the framework works and how a test
> > based on that framework looks like.
> >
> > I've taken the first class refering to SerializationTester, it was
> > CharacterCodingExceptionTest
> >
> > it has two serialization related test methods:
> > testSerialization()
> > testSerializationCompatibility()
> >
> > They both call SerializationTester methods but I did not find that they check
> > that the objects are the same. Did I miss anything?
> >
> The CharacterCodingException don't necessary to be assertSame() for
> serialization test, because it has no predefined constants:).
>
> I think the classes commonly needs to override readResolve() method to
> implement predefined constants serialization properly, so that it is
> easy to find all the candidates from the JavaDoc page of serilization
> form. But, of course, readResolve() is not a suffient condition:(.
>
> > Thanks,
> > Mikhail
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
Hi, Mikhail,
Mikhail Loenko wrote:
> Hi George!
>
>
>> I need to study H-57 SerializationTester, likely it makes sense taking
>> best ideas from both
>>
>
> I was trying to find out how the framework works and how a test
> based on that framework looks like.
>
> I've taken the first class refering to SerializationTester, it was
> CharacterCodingExceptionTest
>
> it has two serialization related test methods:
> testSerialization()
> testSerializationCompatibility()
>
> They both call SerializationTester methods but I did not find that they check
> that the objects are the same. Did I miss anything?
>
The CharacterCodingException don't necessary to be assertSame() for
serialization test, because it has no predefined constants:).
I think the classes commonly needs to override readResolve() method to
implement predefined constants serialization properly, so that it is
easy to find all the candidates from the JavaDoc page of serilization
form. But, of course, readResolve() is not a suffient condition:(.
> Thanks,
> Mikhail
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> Hi George!
>
>
>> I need to study H-57 SerializationTester, likely it makes sense taking
>> best ideas from both
>>
>
> I was trying to find out how the framework works and how a test
> based on that framework looks like.
>
> I've taken the first class refering to SerializationTester, it was
> CharacterCodingExceptionTest
>
> it has two serialization related test methods:
> testSerialization()
> testSerializationCompatibility()
>
> They both call SerializationTester methods but I did not find that they check
> that the objects are the same. Did I miss anything?
>
> Thanks,
> Mikhail
>
Hi Mikhail,
LOL ! That's a brilliant catch - hopefully there are not too many test
cases like those in the rest of the zip :-)
You could try taking a look at
tests.api.java.nio.charset.MalformedInputExceptionTest in the nio_char
tests for a better example of using the SerializationTester methods.
Even better is something like
tests.api.java.beans.PropertyChangeEventTest in the unit tests submitted
in HARMONY-88. Sorry for having to point at yet another different JIRA
attachment.
Best regards,
George
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi George!
> I need to study H-57 SerializationTester, likely it makes sense taking
> best ideas from both
I was trying to find out how the framework works and how a test
based on that framework looks like.
I've taken the first class refering to SerializationTester, it was
CharacterCodingExceptionTest
it has two serialization related test methods:
testSerialization()
testSerializationCompatibility()
They both call SerializationTester methods but I did not find that they check
that the objects are the same. Did I miss anything?
Thanks,
Mikhail
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
Mikhail
Mikhail Loenko wrote:
> Hi Paulex,
>
> 2006/3/15, Paulex Yang <pa...@gmail.com>:
>
>> Hi, Mikhail,
>>
>> Mikhail Loenko wrote:
>>
>>> Hi Paulex,
>>>
>>> 2006/3/14, Paulex Yang <pa...@gmail.com>:
>>>
>>>
>>>> Mikhail
>>>>
>>>> I spent a little time on the framework, and I must say that this
>>>> framework is very easy to use. Impressive!
>>>>
>>>> But I still have some thoughts on it:
>>>> 1. Sometime assertEquals() is not enough for the deserialized objects,
>>>> i.e., if the predefined constants is serialized first by JRE instance A
>>>> and deserialized later on JRE instance B, it should has same object
>>>> identity with the existing constants in B, for example, the Locale.CHINA
>>>> should be unique in any JRE instance. So it will be perfect if some
>>>> helper method like assertSame() is provided.
>>>>
>>>> It is also worth mentioning that some other time assertEquals() is too
>>>> strict, because some serializable class may not override j.l.Object's
>>>> equals(), so that the assertEquals() is equivalent to assertSame(), and
>>>> it may not necessary.
>>>>
>>>>
>>> There is assertDeserialized() method in the framework (SerializationTest.java)
>>> do you mean something like that?
>>>
>>>
>>>
>> Yes, something like that, but invoke assertSame() instead of
>> assertEquals(), or switch case by some configuration.
>>
>
> Actually framework calls assertDeserialized() who in its turn by default
> calls assertEquals().
>
> For each specific test an author may override assertDeserialized() by
> something like you call assertSame(). Please have a look at an example:
>
> modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
>
OK, I'm fine with this solution.
>
>>>> 2. I have some concerns on the abstract-class mode of SerializationTest,
>>>> i.e., if some test want to leverage it, it must subclass this abstract
>>>> class at first. What to do if it needs to inherited other abstract test
>>>> cases, say, PerformanceTest? So personally I prefer the less
>>>> "intrusive" way like utility class. Another option is make the test case
>>>> implements an interface with getData(), say ISerializationTest, and pass
>>>> an instance of this interface to the utility class(similar with command
>>>> pattern).
>>>>
>>>>
>>> SerializationTest.java has bodies of two test methods:
>>> testSelf()
>>> testGolden()
>>>
>>> These methods are inherited and called by JUnit, so test developer do not have
>>> to care about them.
>>>
>>>
>>>
>> Sure, that's the advantages of abstract class mode, but the utility
>> class is more *flexible*, i.e. less "intrusive" to the concrete test
>> classes.
>>
>> Maybe there is another way to achieve both convenience and flexibility,
>> by separate test case for serialization to a single file, say ,
>> for:
>> public class AClass implements Serializable{...}
>>
>> we have:
>> AClassTest, for common test cases,
>> and
>> AClassSerializationTest extends SerializationTest, for serialization test.
>>
>
> That is what we have now in security module:
>
> modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
> and
> modules/security/test/common/unit/java/security/CodeSignerTest.java
>
> Thanks,
> Mikhail
>
That's great.
>
>
>>>> btw, I noticed there is also a serialization test utility class in the
>>>> Harmony-57 contribution. The class is located in
>>>> Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
>>>> It is a helper class which only providing some handy utility methods.
>>>> But seems it lacks of adaptability to generate "GoldenFile" by reading
>>>> configuration and not well documented.
>>>>
>>>> What I suggest is to merge the two classes in some way, so that the
>>>> whole class library test suites can leverage the benefits of unified
>>>> serialization test framework/utility/anything.
>>>>
>>>>
>>> I need to study H-57 SerializationTester, likely it makes sense taking
>>> best ideas from both
>>>
>>> Thanks,
>>> Mikhail.
>>>
>>>
>>>
>>>> thoughts?
>>>>
>>>> Mikhail Loenko wrote:
>>>>
>>>>
>>>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>>>> ...
>>>>>
>>>>>
>>>>>
>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>
>>>>>>
>>>>>>
>>>>> BTW, there is a framework for serialization testing which is currently
>>>>> in the security module:
>>>>>
>>>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>>>
>>>>> It serves to simplify serialization testing and has the docs inside. Actually
>>>>> almost all serializable security-related classes are tested with this framework.
>>>>>
>>>>> Does it make sense to move the framework to a common place?
>>>>>
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Paulex Yang
>>>> China Software Development Lab
>>>> IBM
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Paulex,
2006/3/15, Paulex Yang <pa...@gmail.com>:
> Hi, Mikhail,
>
> Mikhail Loenko wrote:
> > Hi Paulex,
> >
> > 2006/3/14, Paulex Yang <pa...@gmail.com>:
> >
> >> Mikhail
> >>
> >> I spent a little time on the framework, and I must say that this
> >> framework is very easy to use. Impressive!
> >>
> >> But I still have some thoughts on it:
> >> 1. Sometime assertEquals() is not enough for the deserialized objects,
> >> i.e., if the predefined constants is serialized first by JRE instance A
> >> and deserialized later on JRE instance B, it should has same object
> >> identity with the existing constants in B, for example, the Locale.CHINA
> >> should be unique in any JRE instance. So it will be perfect if some
> >> helper method like assertSame() is provided.
> >>
> >> It is also worth mentioning that some other time assertEquals() is too
> >> strict, because some serializable class may not override j.l.Object's
> >> equals(), so that the assertEquals() is equivalent to assertSame(), and
> >> it may not necessary.
> >>
> >
> > There is assertDeserialized() method in the framework (SerializationTest.java)
> > do you mean something like that?
> >
> >
> Yes, something like that, but invoke assertSame() instead of
> assertEquals(), or switch case by some configuration.
Actually framework calls assertDeserialized() who in its turn by default
calls assertEquals().
For each specific test an author may override assertDeserialized() by
something like you call assertSame(). Please have a look at an example:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
> >> 2. I have some concerns on the abstract-class mode of SerializationTest,
> >> i.e., if some test want to leverage it, it must subclass this abstract
> >> class at first. What to do if it needs to inherited other abstract test
> >> cases, say, PerformanceTest? So personally I prefer the less
> >> "intrusive" way like utility class. Another option is make the test case
> >> implements an interface with getData(), say ISerializationTest, and pass
> >> an instance of this interface to the utility class(similar with command
> >> pattern).
> >>
> >
> > SerializationTest.java has bodies of two test methods:
> > testSelf()
> > testGolden()
> >
> > These methods are inherited and called by JUnit, so test developer do not have
> > to care about them.
> >
> >
> Sure, that's the advantages of abstract class mode, but the utility
> class is more *flexible*, i.e. less "intrusive" to the concrete test
> classes.
>
> Maybe there is another way to achieve both convenience and flexibility,
> by separate test case for serialization to a single file, say ,
> for:
> public class AClass implements Serializable{...}
>
> we have:
> AClassTest, for common test cases,
> and
> AClassSerializationTest extends SerializationTest, for serialization test.
That is what we have now in security module:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
and
modules/security/test/common/unit/java/security/CodeSignerTest.java
Thanks,
Mikhail
> >> btw, I noticed there is also a serialization test utility class in the
> >> Harmony-57 contribution. The class is located in
> >> Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
> >> It is a helper class which only providing some handy utility methods.
> >> But seems it lacks of adaptability to generate "GoldenFile" by reading
> >> configuration and not well documented.
> >>
> >> What I suggest is to merge the two classes in some way, so that the
> >> whole class library test suites can leverage the benefits of unified
> >> serialization test framework/utility/anything.
> >>
> >
> > I need to study H-57 SerializationTester, likely it makes sense taking
> > best ideas from both
> >
> > Thanks,
> > Mikhail.
> >
> >
> >> thoughts?
> >>
> >> Mikhail Loenko wrote:
> >>
> >>> 2006/3/9, George Harley <ge...@googlemail.com>:
> >>> ...
> >>>
> >>>
> >>>> Such a testing effort still sounds pretty daunting though.
> >>>>
> >>>>
> >>> BTW, there is a framework for serialization testing which is currently
> >>> in the security module:
> >>>
> >>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
> >>>
> >>> It serves to simplify serialization testing and has the docs inside. Actually
> >>> almost all serializable security-related classes are tested with this framework.
> >>>
> >>> Does it make sense to move the framework to a common place?
> >>>
> >>> Thanks,
> >>> Mikhail
> >>>
> >>>
> >>>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
Hi, Mikhail,
Mikhail Loenko wrote:
> Hi Paulex,
>
> 2006/3/14, Paulex Yang <pa...@gmail.com>:
>
>> Mikhail
>>
>> I spent a little time on the framework, and I must say that this
>> framework is very easy to use. Impressive!
>>
>> But I still have some thoughts on it:
>> 1. Sometime assertEquals() is not enough for the deserialized objects,
>> i.e., if the predefined constants is serialized first by JRE instance A
>> and deserialized later on JRE instance B, it should has same object
>> identity with the existing constants in B, for example, the Locale.CHINA
>> should be unique in any JRE instance. So it will be perfect if some
>> helper method like assertSame() is provided.
>>
>> It is also worth mentioning that some other time assertEquals() is too
>> strict, because some serializable class may not override j.l.Object's
>> equals(), so that the assertEquals() is equivalent to assertSame(), and
>> it may not necessary.
>>
>
> There is assertDeserialized() method in the framework (SerializationTest.java)
> do you mean something like that?
>
>
Yes, something like that, but invoke assertSame() instead of
assertEquals(), or switch case by some configuration.
>> 2. I have some concerns on the abstract-class mode of SerializationTest,
>> i.e., if some test want to leverage it, it must subclass this abstract
>> class at first. What to do if it needs to inherited other abstract test
>> cases, say, PerformanceTest? So personally I prefer the less
>> "intrusive" way like utility class. Another option is make the test case
>> implements an interface with getData(), say ISerializationTest, and pass
>> an instance of this interface to the utility class(similar with command
>> pattern).
>>
>
> SerializationTest.java has bodies of two test methods:
> testSelf()
> testGolden()
>
> These methods are inherited and called by JUnit, so test developer do not have
> to care about them.
>
>
Sure, that's the advantages of abstract class mode, but the utility
class is more *flexible*, i.e. less "intrusive" to the concrete test
classes.
Maybe there is another way to achieve both convenience and flexibility,
by separate test case for serialization to a single file, say ,
for:
public class AClass implements Serializable{...}
we have:
AClassTest, for common test cases,
and
AClassSerializationTest extends SerializationTest, for serialization test.
>> btw, I noticed there is also a serialization test utility class in the
>> Harmony-57 contribution. The class is located in
>> Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
>> It is a helper class which only providing some handy utility methods.
>> But seems it lacks of adaptability to generate "GoldenFile" by reading
>> configuration and not well documented.
>>
>> What I suggest is to merge the two classes in some way, so that the
>> whole class library test suites can leverage the benefits of unified
>> serialization test framework/utility/anything.
>>
>
> I need to study H-57 SerializationTester, likely it makes sense taking
> best ideas from both
>
> Thanks,
> Mikhail.
>
>
>> thoughts?
>>
>> Mikhail Loenko wrote:
>>
>>> 2006/3/9, George Harley <ge...@googlemail.com>:
>>> ...
>>>
>>>
>>>> Such a testing effort still sounds pretty daunting though.
>>>>
>>>>
>>> BTW, there is a framework for serialization testing which is currently
>>> in the security module:
>>>
>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>
>>> It serves to simplify serialization testing and has the docs inside. Actually
>>> almost all serializable security-related classes are tested with this framework.
>>>
>>> Does it make sense to move the framework to a common place?
>>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Paulex,
2006/3/14, Paulex Yang <pa...@gmail.com>:
> Mikhail
>
> I spent a little time on the framework, and I must say that this
> framework is very easy to use. Impressive!
>
> But I still have some thoughts on it:
> 1. Sometime assertEquals() is not enough for the deserialized objects,
> i.e., if the predefined constants is serialized first by JRE instance A
> and deserialized later on JRE instance B, it should has same object
> identity with the existing constants in B, for example, the Locale.CHINA
> should be unique in any JRE instance. So it will be perfect if some
> helper method like assertSame() is provided.
>
> It is also worth mentioning that some other time assertEquals() is too
> strict, because some serializable class may not override j.l.Object's
> equals(), so that the assertEquals() is equivalent to assertSame(), and
> it may not necessary.
There is assertDeserialized() method in the framework (SerializationTest.java)
do you mean something like that?
>
> 2. I have some concerns on the abstract-class mode of SerializationTest,
> i.e., if some test want to leverage it, it must subclass this abstract
> class at first. What to do if it needs to inherited other abstract test
> cases, say, PerformanceTest? So personally I prefer the less
> "intrusive" way like utility class. Another option is make the test case
> implements an interface with getData(), say ISerializationTest, and pass
> an instance of this interface to the utility class(similar with command
> pattern).
SerializationTest.java has bodies of two test methods:
testSelf()
testGolden()
These methods are inherited and called by JUnit, so test developer do not have
to care about them.
>
> btw, I noticed there is also a serialization test utility class in the
> Harmony-57 contribution. The class is located in
> Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
> It is a helper class which only providing some handy utility methods.
> But seems it lacks of adaptability to generate "GoldenFile" by reading
> configuration and not well documented.
>
> What I suggest is to merge the two classes in some way, so that the
> whole class library test suites can leverage the benefits of unified
> serialization test framework/utility/anything.
I need to study H-57 SerializationTester, likely it makes sense taking
best ideas from both
Thanks,
Mikhail.
>
> thoughts?
>
> Mikhail Loenko wrote:
> > 2006/3/9, George Harley <ge...@googlemail.com>:
> > ...
> >
> >> Such a testing effort still sounds pretty daunting though.
> >>
> >
> > BTW, there is a framework for serialization testing which is currently
> > in the security module:
> >
> > modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
> >
> > It serves to simplify serialization testing and has the docs inside. Actually
> > almost all serializable security-related classes are tested with this framework.
> >
> > Does it make sense to move the framework to a common place?
> >
> > Thanks,
> > Mikhail
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Paulex Yang wrote:
> Mikhail
>
> I spent a little time on the framework, and I must say that this
> framework is very easy to use. Impressive!
>
> But I still have some thoughts on it:
> 1. Sometime assertEquals() is not enough for the deserialized objects,
> i.e., if the predefined constants is serialized first by JRE instance
> A and deserialized later on JRE instance B, it should has same
> object identity with the existing constants in B, for example, the
> Locale.CHINA should be unique in any JRE instance. So it will be
> perfect if some helper method like assertSame() is provided.
>
> It is also worth mentioning that some other time assertEquals() is too
> strict, because some serializable class may not override j.l.Object's
> equals(), so that the assertEquals() is equivalent to assertSame(),
> and it may not necessary.
>
> 2. I have some concerns on the abstract-class mode of
> SerializationTest, i.e., if some test want to leverage it, it must
> subclass this abstract class at first. What to do if it needs to
> inherited other abstract test cases, say, PerformanceTest? So
> personally I prefer the less "intrusive" way like utility class.
> Another option is make the test case implements an interface with
> getData(), say ISerializationTest, and pass an instance of this
> interface to the utility class(similar with command pattern).
>
> btw, I noticed there is also a serialization test utility class in the
> Harmony-57 contribution. The class is located in
> Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
> It is a helper class which only providing some handy utility methods.
> But seems it lacks of adaptability to generate "GoldenFile" by reading
> configuration and not well documented.
>
> What I suggest is to merge the two classes in some way, so that the
> whole class library test suites can leverage the benefits of unified
> serialization test framework/utility/anything.
>
> thoughts?
Hi Paulex,
I was aware that the HARMONY-57 archive contained equivalent
functionality but, revisiting it just now, had forgotten just how
similar the two utilities are. IMHO there is definitely *lots* to be
taken from both approaches if we move towards a unified approach.
* From a Java language perspective, I like the fact that the HARMONY-57
SerializationTester does not mandate other test classes to extend it.
But, on the other hand, having that functionality encapsulated in static
helper methods belonging to another type does not force test developers
to actually use it. So, from a "force people to think about
serialization when writing their tests !!" perspective, the security
module's approach of mandating classes extend their abstract
SerializationTest is kind of appealing. OK, I am being totally
schizophrenic here. Your idea of an interface that test classes of
Serializable types should implement sounds like a good way forwards here.
* I like the way that the HARMONY-57 SerializationTester checks on
predefined constant objects being the same.
* It's good that the security module's code encourages more than one
.ser/.dat file to be produced for testing a wide range of object states.
* I like the security module code's template method
assertDeserialization() that enables test code to have a means of
checking the success of the serialization/deserialization functionality
customised for the specific type under test.
What still bothers me is the fact that developers can't be forced to
implement any notional ISerializationTest interface nor extend any
abstract SerializationTest class in a unit test class that tests out a
Serializable type. But that's a whole different story altogether...
Best regards,
George
>
> Mikhail Loenko wrote:
>> 2006/3/9, George Harley <ge...@googlemail.com>:
>> ...
>>
>>> Such a testing effort still sounds pretty daunting though.
>>>
>>
>> BTW, there is a framework for serialization testing which is currently
>> in the security module:
>>
>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>
>>
>> It serves to simplify serialization testing and has the docs inside.
>> Actually
>> almost all serializable security-related classes are tested with this
>> framework.
>>
>> Does it make sense to move the framework to a common place?
>>
>> Thanks,
>> Mikhail
>>
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
Mikhail
I spent a little time on the framework, and I must say that this
framework is very easy to use. Impressive!
But I still have some thoughts on it:
1. Sometime assertEquals() is not enough for the deserialized objects,
i.e., if the predefined constants is serialized first by JRE instance A
and deserialized later on JRE instance B, it should has same object
identity with the existing constants in B, for example, the Locale.CHINA
should be unique in any JRE instance. So it will be perfect if some
helper method like assertSame() is provided.
It is also worth mentioning that some other time assertEquals() is too
strict, because some serializable class may not override j.l.Object's
equals(), so that the assertEquals() is equivalent to assertSame(), and
it may not necessary.
2. I have some concerns on the abstract-class mode of SerializationTest,
i.e., if some test want to leverage it, it must subclass this abstract
class at first. What to do if it needs to inherited other abstract test
cases, say, PerformanceTest? So personally I prefer the less
"intrusive" way like utility class. Another option is make the test case
implements an interface with getData(), say ISerializationTest, and pass
an instance of this interface to the utility class(similar with command
pattern).
btw, I noticed there is also a serialization test utility class in the
Harmony-57 contribution. The class is located in
Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
It is a helper class which only providing some handy utility methods.
But seems it lacks of adaptability to generate "GoldenFile" by reading
configuration and not well documented.
What I suggest is to merge the two classes in some way, so that the
whole class library test suites can leverage the benefits of unified
serialization test framework/utility/anything.
thoughts?
Mikhail Loenko wrote:
> 2006/3/9, George Harley <ge...@googlemail.com>:
> ...
>
>> Such a testing effort still sounds pretty daunting though.
>>
>
> BTW, there is a framework for serialization testing which is currently
> in the security module:
>
> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>
> It serves to simplify serialization testing and has the docs inside. Actually
> almost all serializable security-related classes are tested with this framework.
>
> Does it make sense to move the framework to a common place?
>
> Thanks,
> Mikhail
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/3/9, George Harley <ge...@googlemail.com>:
...
> Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs inside. Actually
almost all serializable security-related classes are tested with this framework.
Does it make sense to move the framework to a common place?
Thanks,
Mikhail
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
George Harley wrote:
> Paulex Yang wrote:
>> Mikhail
>>
>> Mikhail Loenko wrote:
>>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>>
>>>> This is somewhat terrifying, isn't it? Are there really references to
>>>> com.sun.* in serialized API objects?
>>>>
>>>
>>> Yes, there are.
>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>
>> yes, and as I mentioned before, the TimeZone is composited by other
>> serializable class, so that all these classes cannot be serialization
>> compatible, feel like something as cancer :(
>>> Can we list all the popular applications that exchange by serialized
>>> objects
>>> and identify which objects do they send/receive?
>>>
>> Rather than investigating almost infinite and uncertain(i.e. how to
>> define popular?) applications, I'd like to test all the serializable
>> class in JSE, at least it is a certain and limited set, we can just
>> find all these kind of incompatibilities one by one, and take some
>> actions.
>
> Hi Paulex,
>
> To restrict the scope of the set of serializable types to be
> compatibility tested we could start by looking for those that are
> abstract types which get instantiated via factory methods. The
> abstract class java.util.TimeZone is a perfect example while concrete
> type java.util.SimpleTimeZone does successfully serialize/de-serialize
> across Harmony and the RI.
This is good idea.
>
> Such a testing effort still sounds pretty daunting though.
Anyway, I think the serialization compatibility test is necessary,
because it is an important feature, especially for many J2EE
applications, and we should try our best to maintain the this kind of
compatibility. It IS tedious, but just like all the tests for
NullPointerException/IllegalArgumentException, etc. they are part of
implementation.
>
>>
>> Currently, we have three options:
>> 1. let it be, and speak it loudly in Harmony JavaDoc
>> 2. try to compatible with RI, by creating some adapter with RI's
>> serializable class name, i.e. com.sun.*, etc, and the behavior is
>> even not necessarily compatible with RI. we can even separate them
>> all to a new component named as "compatibility", so that it is easily
>> modify them when RI changes its mind and improve. Not sure if it is
>> legally fine.
>> 3. also try to compatible with RI, by maintaining pairs in
>> ObjectInputStream, this approach maybe has less legal risk? (I have
>> no idea in fact.)
>>
>> Any other good ideas?
>>
>> And before all of this, I cannot agree with Geir more - we should
>> make Sun be aware of this issue.
>
> Interestingly enough, the RI Javadoc "specification" for the
> java.util.TimeZone factory method does contain the telling phrase "the
> source of the default TimeZone may vary with implementation". Sure, on
> its own that may not emphasise that a user could hit
> serialization/de-serialization problems if working across different
> implementations - but it hopefully does serve to alert users that the
> type of JRE does matter when invoking that method (and perhaps writing
> mission-critical applications that rely on storing the returned object
> in serialized form is not a great idea). At a very minimum, the quoted
> RI Javadoc (and equivalents throughout the rest of the Javadoc files)
> should be expanded to explain the potential serialization issue when a
> concrete type depends on the JRE.
>
> Best regards,
> George
>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Paulex Yang wrote:
> Mikhail
>
> Mikhail Loenko wrote:
>> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>>
>>> This is somewhat terrifying, isn't it? Are there really references to
>>> com.sun.* in serialized API objects?
>>>
>>
>> Yes, there are.
>> For example, TimeZone.ser produced by the example from the JIRA issue
>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>
> yes, and as I mentioned before, the TimeZone is composited by other
> serializable class, so that all these classes cannot be serialization
> compatible, feel like something as cancer :(
>> Can we list all the popular applications that exchange by serialized
>> objects
>> and identify which objects do they send/receive?
>>
> Rather than investigating almost infinite and uncertain(i.e. how to
> define popular?) applications, I'd like to test all the serializable
> class in JSE, at least it is a certain and limited set, we can just
> find all these kind of incompatibilities one by one, and take some
> actions.
Hi Paulex,
To restrict the scope of the set of serializable types to be
compatibility tested we could start by looking for those that are
abstract types which get instantiated via factory methods. The abstract
class java.util.TimeZone is a perfect example while concrete type
java.util.SimpleTimeZone does successfully serialize/de-serialize across
Harmony and the RI.
Such a testing effort still sounds pretty daunting though.
>
> Currently, we have three options:
> 1. let it be, and speak it loudly in Harmony JavaDoc
> 2. try to compatible with RI, by creating some adapter with RI's
> serializable class name, i.e. com.sun.*, etc, and the behavior is even
> not necessarily compatible with RI. we can even separate them all to
> a new component named as "compatibility", so that it is easily modify
> them when RI changes its mind and improve. Not sure if it is legally
> fine.
> 3. also try to compatible with RI, by maintaining pairs in
> ObjectInputStream, this approach maybe has less legal risk? (I have no
> idea in fact.)
>
> Any other good ideas?
>
> And before all of this, I cannot agree with Geir more - we should make
> Sun be aware of this issue.
Interestingly enough, the RI Javadoc "specification" for the
java.util.TimeZone factory method does contain the telling phrase "the
source of the default TimeZone may vary with implementation". Sure, on
its own that may not emphasise that a user could hit
serialization/de-serialization problems if working across different
implementations - but it hopefully does serve to alert users that the
type of JRE does matter when invoking that method (and perhaps writing
mission-critical applications that rely on storing the returned object
in serialized form is not a great idea). At a very minimum, the quoted
RI Javadoc (and equivalents throughout the rest of the Javadoc files)
should be expanded to explain the potential serialization issue when a
concrete type depends on the JRE.
Best regards,
George
>> Thanks,
>> Mikhail
>>
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
Mikhail
Mikhail Loenko wrote:
> 2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
>
>> This is somewhat terrifying, isn't it? Are there really references to
>> com.sun.* in serialized API objects?
>>
>
> Yes, there are.
> For example, TimeZone.ser produced by the example from the JIRA issue
> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>
yes, and as I mentioned before, the TimeZone is composited by other
serializable class, so that all these classes cannot be serialization
compatible, feel like something as cancer :(
> Can we list all the popular applications that exchange by serialized objects
> and identify which objects do they send/receive?
>
Rather than investigating almost infinite and uncertain(i.e. how to
define popular?) applications, I'd like to test all the serializable
class in JSE, at least it is a certain and limited set, we can just find
all these kind of incompatibilities one by one, and take some actions.
Currently, we have three options:
1. let it be, and speak it loudly in Harmony JavaDoc
2. try to compatible with RI, by creating some adapter with RI's
serializable class name, i.e. com.sun.*, etc, and the behavior is even
not necessarily compatible with RI. we can even separate them all to a
new component named as "compatibility", so that it is easily modify them
when RI changes its mind and improve. Not sure if it is legally fine.
3. also try to compatible with RI, by maintaining pairs in
ObjectInputStream, this approach maybe has less legal risk? (I have no
idea in fact.)
Any other good ideas?
And before all of this, I cannot agree with Geir more - we should make
Sun be aware of this issue.
> Thanks,
> Mikhail
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/3/7, Geir Magnusson Jr <ge...@pobox.com>:
> This is somewhat terrifying, isn't it? Are there really references to
> com.sun.* in serialized API objects?
Yes, there are.
For example, TimeZone.ser produced by the example from the JIRA issue
that started this thread, refers to "sun.util.calendar.ZoneInfo"
Can we list all the popular applications that exchange by serialized objects
and identify which objects do they send/receive?
Thanks,
Mikhail
Re: How to deal with this kind of serialization compatibility issue?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
This is somewhat terrifying, isn't it? Are there really references to
com.sun.* in serialized API objects? This *has* to be a bug in the
whole spec if so...
Is serialization called out as being non-portable?
(I never thought of this before because I always worked in homogeneous
JRE environments...)
geir
Mikhail Loenko wrote:
> The problem is serial form contains class name "sun.foo"
> and if you deal with "o.a.h.foo" then serialization framework
> will never know that you class's readObject() is to be invoked.
>
> Another option is provide 'pairs' to ObjectInputStream.readObject():
> for each 'foo' method it will know what is the corresponding harmony
> class.
>
> Thanks,
> Mikhail
>
>
> 2006/3/7, George Harley <ge...@googlemail.com>:
>> Mikhail Loenko wrote:
>>> George,
>>>
>>> 2006/3/7, George Harley <ge...@googlemail.com>:
>>>
>>>> Paulex Yang wrote:
>>>>
>>>>> This kind of serialization compatibility issue may be found again
>>>>> later, if only RI use some non-API class as default implementation of
>>>>> serializable abstract class. So I think we need some discussion on
>>>>> this issue for a principle.
>>>>>
>>>>> I propose two choice:
>>>>> 1. just let it be
>>>>> 2. mimic a class as RI, in this TimeZone case, create a
>>>>> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
>>>>> works but risky and ugly, it is risky because RI may change the
>>>>> implementation class later(which will also break RI's serialization
>>>>> compatibility of course)
>>>>>
>>>>> comments?
>>>>>
>>>> Hi Paulex,
>>>>
>>>> When such RI->Harmony serialization incompatibilities come to light we
>>>> can aim to deal with it in readObject() methods added to the affected
>>>>
>>> It is not quite clear, in which class you are going to deal with readObject() ?
>>>
>>> Are you suggesting modification of IO framework that does serialization?
>>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>> Hi Mikhail,
>>
>> I mean the "private void readObject(ObjectInputStream os)" method that
>> every type implementing the Serializable interface can contain to
>> provide customised de-serialization.
>>
>> Best regards,
>> George
>>
>>>> types. This will have to be done on a case-by-case basis of course. In
>>>> this particular case I could imagine that we could catch that
>>>> ClassNotFoundException in the method and proceed on from there.
>>>>
>>>> But what about Harmony->RI serialization incompatibilities ? That is,
>>>> what about Harmony applications serializing types to files and those
>>>> files being later read in by applications running on a RI JRE ? In some
>>>> cases we will probably "get away with it" as the differences in
>>>> implementation will not break compatibility. For instance, running your
>>>> test code so that Harmony produces the .ser file and the RI reads it in
>>>> seemed to work fine for me. But the risk of problems will always be
>>>> there. I am not certain that writing stubs of sun.* classes is a good
>>>> direction to set off in to counter those risks. It would be better to
>>>> try and work with the RI providers so that their classes can cope with
>>>> serialized Harmony types.
>>>>
>>>> I wonder what lessons other class library development teams have learned
>>>> in this area ?
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>
>>>>
>>>>> Paulex Yang (JIRA) wrote:
>>>>>
>>>>>> java.util.TimeZone's default implementation may cause many classes'
>>>>>> serialization non-compatible with RI
>>>>>> --------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Key: HARMONY-184
>>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-184
>>>>>> Project: Harmony
>>>>>> Type: Bug
>>>>>> Components: Classlib Reporter: Paulex Yang
>>>>>> Priority: Critical
>>>>>>
>>>>>>
>>>>>> Static factory methods, java.util.TimeZone.getInstance(String) and
>>>>>> getDefault(), are only ways to get a TimeZone instance, but Harmony
>>>>>> and RI uses different classes as default implementation, which cause
>>>>>> serialization non-compatible. Further, all classes whose
>>>>>> serialization form includes TimeZone won't compatible with RI, too,
>>>>>> for example, java.util.Calendar(with subclass),
>>>>>> java.text.DateFormat(with subclass), etc.
>>>>>>
>>>>>> But the incompatiblity is hard to be imputed to Harmony, because
>>>>>> Harmony use API class SimpleTimeZone as default implementation, but
>>>>>> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
>>>>>>
>>>>>> The reproduce procedure:
>>>>>> 1. To serialize TimeZone object to a file in RI, run codes below in RI
>>>>>> public void writeObject(){
>>>>>> TimeZone zone = TimeZone.getTimeZone("GMT");
>>>>>> ObjectOutputStream ooutput = null;
>>>>>> try {
>>>>>> ooutput = new ObjectOutputStream(new
>>>>>> FileOutputStream("TimeZone.ser"));
>>>>>> ooutput.writeObject(zone);
>>>>>> } finally {
>>>>>> try {
>>>>>> if (null != ooutput) {
>>>>>> ooutput.close();
>>>>>> }
>>>>>> } catch (Exception e) {
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> 2. Trying to deserialize this object from file, run codes below
>>>>>> public void readObject(){
>>>>>> ObjectInputStream oinput = null;
>>>>>> try {
>>>>>> oinput = new ObjectInputStream(new
>>>>>> FileInputStream("TimeZone.ser"));
>>>>>> TimeZone newObj = (TimeZone)oinput.readObject();
>>>>>> } finally {
>>>>>> try {
>>>>>> if (null != oinput) {
>>>>>> oinput.close();
>>>>>> }
>>>>>> } catch (Exception e) {
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Run in RI, passes without any failure
>>>>>> Run in Harmony, exception throwed as below:
>>>>>> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
>>>>>> at java.lang.Class.forName(Class.java:154)
>>>>>> at
>>>>>> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
>>>>>> ... ...
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
The problem is serial form contains class name "sun.foo"
and if you deal with "o.a.h.foo" then serialization framework
will never know that you class's readObject() is to be invoked.
Another option is provide 'pairs' to ObjectInputStream.readObject():
for each 'foo' method it will know what is the corresponding harmony
class.
Thanks,
Mikhail
2006/3/7, George Harley <ge...@googlemail.com>:
> Mikhail Loenko wrote:
> > George,
> >
> > 2006/3/7, George Harley <ge...@googlemail.com>:
> >
> >> Paulex Yang wrote:
> >>
> >>> This kind of serialization compatibility issue may be found again
> >>> later, if only RI use some non-API class as default implementation of
> >>> serializable abstract class. So I think we need some discussion on
> >>> this issue for a principle.
> >>>
> >>> I propose two choice:
> >>> 1. just let it be
> >>> 2. mimic a class as RI, in this TimeZone case, create a
> >>> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
> >>> works but risky and ugly, it is risky because RI may change the
> >>> implementation class later(which will also break RI's serialization
> >>> compatibility of course)
> >>>
> >>> comments?
> >>>
> >> Hi Paulex,
> >>
> >> When such RI->Harmony serialization incompatibilities come to light we
> >> can aim to deal with it in readObject() methods added to the affected
> >>
> >
> > It is not quite clear, in which class you are going to deal with readObject() ?
> >
> > Are you suggesting modification of IO framework that does serialization?
> >
> > Thanks,
> > Mikhail
> >
> >
>
> Hi Mikhail,
>
> I mean the "private void readObject(ObjectInputStream os)" method that
> every type implementing the Serializable interface can contain to
> provide customised de-serialization.
>
> Best regards,
> George
>
> >> types. This will have to be done on a case-by-case basis of course. In
> >> this particular case I could imagine that we could catch that
> >> ClassNotFoundException in the method and proceed on from there.
> >>
> >> But what about Harmony->RI serialization incompatibilities ? That is,
> >> what about Harmony applications serializing types to files and those
> >> files being later read in by applications running on a RI JRE ? In some
> >> cases we will probably "get away with it" as the differences in
> >> implementation will not break compatibility. For instance, running your
> >> test code so that Harmony produces the .ser file and the RI reads it in
> >> seemed to work fine for me. But the risk of problems will always be
> >> there. I am not certain that writing stubs of sun.* classes is a good
> >> direction to set off in to counter those risks. It would be better to
> >> try and work with the RI providers so that their classes can cope with
> >> serialized Harmony types.
> >>
> >> I wonder what lessons other class library development teams have learned
> >> in this area ?
> >>
> >> Best regards,
> >> George
> >>
> >>
> >>
> >>> Paulex Yang (JIRA) wrote:
> >>>
> >>>> java.util.TimeZone's default implementation may cause many classes'
> >>>> serialization non-compatible with RI
> >>>> --------------------------------------------------------------------------------------------------------
> >>>>
> >>>>
> >>>> Key: HARMONY-184
> >>>> URL: http://issues.apache.org/jira/browse/HARMONY-184
> >>>> Project: Harmony
> >>>> Type: Bug
> >>>> Components: Classlib Reporter: Paulex Yang
> >>>> Priority: Critical
> >>>>
> >>>>
> >>>> Static factory methods, java.util.TimeZone.getInstance(String) and
> >>>> getDefault(), are only ways to get a TimeZone instance, but Harmony
> >>>> and RI uses different classes as default implementation, which cause
> >>>> serialization non-compatible. Further, all classes whose
> >>>> serialization form includes TimeZone won't compatible with RI, too,
> >>>> for example, java.util.Calendar(with subclass),
> >>>> java.text.DateFormat(with subclass), etc.
> >>>>
> >>>> But the incompatiblity is hard to be imputed to Harmony, because
> >>>> Harmony use API class SimpleTimeZone as default implementation, but
> >>>> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
> >>>>
> >>>> The reproduce procedure:
> >>>> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> >>>> public void writeObject(){
> >>>> TimeZone zone = TimeZone.getTimeZone("GMT");
> >>>> ObjectOutputStream ooutput = null;
> >>>> try {
> >>>> ooutput = new ObjectOutputStream(new
> >>>> FileOutputStream("TimeZone.ser"));
> >>>> ooutput.writeObject(zone);
> >>>> } finally {
> >>>> try {
> >>>> if (null != ooutput) {
> >>>> ooutput.close();
> >>>> }
> >>>> } catch (Exception e) {
> >>>> }
> >>>> }
> >>>> }
> >>>>
> >>>> 2. Trying to deserialize this object from file, run codes below
> >>>> public void readObject(){
> >>>> ObjectInputStream oinput = null;
> >>>> try {
> >>>> oinput = new ObjectInputStream(new
> >>>> FileInputStream("TimeZone.ser"));
> >>>> TimeZone newObj = (TimeZone)oinput.readObject();
> >>>> } finally {
> >>>> try {
> >>>> if (null != oinput) {
> >>>> oinput.close();
> >>>> }
> >>>> } catch (Exception e) {
> >>>> }
> >>>> }
> >>>> }
> >>>>
> >>>> Run in RI, passes without any failure
> >>>> Run in Harmony, exception throwed as below:
> >>>> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> >>>> at java.lang.Class.forName(Class.java:154)
> >>>> at
> >>>> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> >>>> ... ...
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> George,
>
> 2006/3/7, George Harley <ge...@googlemail.com>:
>
>> Paulex Yang wrote:
>>
>>> This kind of serialization compatibility issue may be found again
>>> later, if only RI use some non-API class as default implementation of
>>> serializable abstract class. So I think we need some discussion on
>>> this issue for a principle.
>>>
>>> I propose two choice:
>>> 1. just let it be
>>> 2. mimic a class as RI, in this TimeZone case, create a
>>> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
>>> works but risky and ugly, it is risky because RI may change the
>>> implementation class later(which will also break RI's serialization
>>> compatibility of course)
>>>
>>> comments?
>>>
>> Hi Paulex,
>>
>> When such RI->Harmony serialization incompatibilities come to light we
>> can aim to deal with it in readObject() methods added to the affected
>>
>
> It is not quite clear, in which class you are going to deal with readObject() ?
>
> Are you suggesting modification of IO framework that does serialization?
>
> Thanks,
> Mikhail
>
>
Hi Mikhail,
I mean the "private void readObject(ObjectInputStream os)" method that
every type implementing the Serializable interface can contain to
provide customised de-serialization.
Best regards,
George
>> types. This will have to be done on a case-by-case basis of course. In
>> this particular case I could imagine that we could catch that
>> ClassNotFoundException in the method and proceed on from there.
>>
>> But what about Harmony->RI serialization incompatibilities ? That is,
>> what about Harmony applications serializing types to files and those
>> files being later read in by applications running on a RI JRE ? In some
>> cases we will probably "get away with it" as the differences in
>> implementation will not break compatibility. For instance, running your
>> test code so that Harmony produces the .ser file and the RI reads it in
>> seemed to work fine for me. But the risk of problems will always be
>> there. I am not certain that writing stubs of sun.* classes is a good
>> direction to set off in to counter those risks. It would be better to
>> try and work with the RI providers so that their classes can cope with
>> serialized Harmony types.
>>
>> I wonder what lessons other class library development teams have learned
>> in this area ?
>>
>> Best regards,
>> George
>>
>>
>>
>>> Paulex Yang (JIRA) wrote:
>>>
>>>> java.util.TimeZone's default implementation may cause many classes'
>>>> serialization non-compatible with RI
>>>> --------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Key: HARMONY-184
>>>> URL: http://issues.apache.org/jira/browse/HARMONY-184
>>>> Project: Harmony
>>>> Type: Bug
>>>> Components: Classlib Reporter: Paulex Yang
>>>> Priority: Critical
>>>>
>>>>
>>>> Static factory methods, java.util.TimeZone.getInstance(String) and
>>>> getDefault(), are only ways to get a TimeZone instance, but Harmony
>>>> and RI uses different classes as default implementation, which cause
>>>> serialization non-compatible. Further, all classes whose
>>>> serialization form includes TimeZone won't compatible with RI, too,
>>>> for example, java.util.Calendar(with subclass),
>>>> java.text.DateFormat(with subclass), etc.
>>>>
>>>> But the incompatiblity is hard to be imputed to Harmony, because
>>>> Harmony use API class SimpleTimeZone as default implementation, but
>>>> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
>>>>
>>>> The reproduce procedure:
>>>> 1. To serialize TimeZone object to a file in RI, run codes below in RI
>>>> public void writeObject(){
>>>> TimeZone zone = TimeZone.getTimeZone("GMT");
>>>> ObjectOutputStream ooutput = null;
>>>> try {
>>>> ooutput = new ObjectOutputStream(new
>>>> FileOutputStream("TimeZone.ser"));
>>>> ooutput.writeObject(zone);
>>>> } finally {
>>>> try {
>>>> if (null != ooutput) {
>>>> ooutput.close();
>>>> }
>>>> } catch (Exception e) {
>>>> }
>>>> }
>>>> }
>>>>
>>>> 2. Trying to deserialize this object from file, run codes below
>>>> public void readObject(){
>>>> ObjectInputStream oinput = null;
>>>> try {
>>>> oinput = new ObjectInputStream(new
>>>> FileInputStream("TimeZone.ser"));
>>>> TimeZone newObj = (TimeZone)oinput.readObject();
>>>> } finally {
>>>> try {
>>>> if (null != oinput) {
>>>> oinput.close();
>>>> }
>>>> } catch (Exception e) {
>>>> }
>>>> }
>>>> }
>>>>
>>>> Run in RI, passes without any failure
>>>> Run in Harmony, exception throwed as below:
>>>> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
>>>> at java.lang.Class.forName(Class.java:154)
>>>> at
>>>> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
>>>> ... ...
>>>>
>>>>
>>>>
>>>
>>
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by Mikhail Loenko <ml...@gmail.com>.
George,
2006/3/7, George Harley <ge...@googlemail.com>:
> Paulex Yang wrote:
> > This kind of serialization compatibility issue may be found again
> > later, if only RI use some non-API class as default implementation of
> > serializable abstract class. So I think we need some discussion on
> > this issue for a principle.
> >
> > I propose two choice:
> > 1. just let it be
> > 2. mimic a class as RI, in this TimeZone case, create a
> > sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
> > works but risky and ugly, it is risky because RI may change the
> > implementation class later(which will also break RI's serialization
> > compatibility of course)
> >
> > comments?
>
> Hi Paulex,
>
> When such RI->Harmony serialization incompatibilities come to light we
> can aim to deal with it in readObject() methods added to the affected
It is not quite clear, in which class you are going to deal with readObject() ?
Are you suggesting modification of IO framework that does serialization?
Thanks,
Mikhail
> types. This will have to be done on a case-by-case basis of course. In
> this particular case I could imagine that we could catch that
> ClassNotFoundException in the method and proceed on from there.
>
> But what about Harmony->RI serialization incompatibilities ? That is,
> what about Harmony applications serializing types to files and those
> files being later read in by applications running on a RI JRE ? In some
> cases we will probably "get away with it" as the differences in
> implementation will not break compatibility. For instance, running your
> test code so that Harmony produces the .ser file and the RI reads it in
> seemed to work fine for me. But the risk of problems will always be
> there. I am not certain that writing stubs of sun.* classes is a good
> direction to set off in to counter those risks. It would be better to
> try and work with the RI providers so that their classes can cope with
> serialized Harmony types.
>
> I wonder what lessons other class library development teams have learned
> in this area ?
>
> Best regards,
> George
>
>
> >
> > Paulex Yang (JIRA) wrote:
> >> java.util.TimeZone's default implementation may cause many classes'
> >> serialization non-compatible with RI
> >> --------------------------------------------------------------------------------------------------------
> >>
> >>
> >> Key: HARMONY-184
> >> URL: http://issues.apache.org/jira/browse/HARMONY-184
> >> Project: Harmony
> >> Type: Bug
> >> Components: Classlib Reporter: Paulex Yang
> >> Priority: Critical
> >>
> >>
> >> Static factory methods, java.util.TimeZone.getInstance(String) and
> >> getDefault(), are only ways to get a TimeZone instance, but Harmony
> >> and RI uses different classes as default implementation, which cause
> >> serialization non-compatible. Further, all classes whose
> >> serialization form includes TimeZone won't compatible with RI, too,
> >> for example, java.util.Calendar(with subclass),
> >> java.text.DateFormat(with subclass), etc.
> >>
> >> But the incompatiblity is hard to be imputed to Harmony, because
> >> Harmony use API class SimpleTimeZone as default implementation, but
> >> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
> >>
> >> The reproduce procedure:
> >> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> >> public void writeObject(){
> >> TimeZone zone = TimeZone.getTimeZone("GMT");
> >> ObjectOutputStream ooutput = null;
> >> try {
> >> ooutput = new ObjectOutputStream(new
> >> FileOutputStream("TimeZone.ser"));
> >> ooutput.writeObject(zone);
> >> } finally {
> >> try {
> >> if (null != ooutput) {
> >> ooutput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> 2. Trying to deserialize this object from file, run codes below
> >> public void readObject(){
> >> ObjectInputStream oinput = null;
> >> try {
> >> oinput = new ObjectInputStream(new
> >> FileInputStream("TimeZone.ser"));
> >> TimeZone newObj = (TimeZone)oinput.readObject();
> >> } finally {
> >> try {
> >> if (null != oinput) {
> >> oinput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> Run in RI, passes without any failure
> >> Run in Harmony, exception throwed as below:
> >> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> >> at java.lang.Class.forName(Class.java:154)
> >> at
> >> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> >> ... ...
> >>
> >>
> >
> >
>
>
Re: How to deal with this kind of serialization compatibility issue?
Posted by George Harley <ge...@googlemail.com>.
Paulex Yang wrote:
> This kind of serialization compatibility issue may be found again
> later, if only RI use some non-API class as default implementation of
> serializable abstract class. So I think we need some discussion on
> this issue for a principle.
>
> I propose two choice:
> 1. just let it be
> 2. mimic a class as RI, in this TimeZone case, create a
> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
> works but risky and ugly, it is risky because RI may change the
> implementation class later(which will also break RI's serialization
> compatibility of course)
>
> comments?
Hi Paulex,
When such RI->Harmony serialization incompatibilities come to light we
can aim to deal with it in readObject() methods added to the affected
types. This will have to be done on a case-by-case basis of course. In
this particular case I could imagine that we could catch that
ClassNotFoundException in the method and proceed on from there.
But what about Harmony->RI serialization incompatibilities ? That is,
what about Harmony applications serializing types to files and those
files being later read in by applications running on a RI JRE ? In some
cases we will probably "get away with it" as the differences in
implementation will not break compatibility. For instance, running your
test code so that Harmony produces the .ser file and the RI reads it in
seemed to work fine for me. But the risk of problems will always be
there. I am not certain that writing stubs of sun.* classes is a good
direction to set off in to counter those risks. It would be better to
try and work with the RI providers so that their classes can cope with
serialized Harmony types.
I wonder what lessons other class library development teams have learned
in this area ?
Best regards,
George
>
> Paulex Yang (JIRA) wrote:
>> java.util.TimeZone's default implementation may cause many classes'
>> serialization non-compatible with RI
>> --------------------------------------------------------------------------------------------------------
>>
>>
>> Key: HARMONY-184
>> URL: http://issues.apache.org/jira/browse/HARMONY-184
>> Project: Harmony
>> Type: Bug
>> Components: Classlib Reporter: Paulex Yang
>> Priority: Critical
>>
>>
>> Static factory methods, java.util.TimeZone.getInstance(String) and
>> getDefault(), are only ways to get a TimeZone instance, but Harmony
>> and RI uses different classes as default implementation, which cause
>> serialization non-compatible. Further, all classes whose
>> serialization form includes TimeZone won't compatible with RI, too,
>> for example, java.util.Calendar(with subclass),
>> java.text.DateFormat(with subclass), etc.
>>
>> But the incompatiblity is hard to be imputed to Harmony, because
>> Harmony use API class SimpleTimeZone as default implementation, but
>> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
>>
>> The reproduce procedure:
>> 1. To serialize TimeZone object to a file in RI, run codes below in RI
>> public void writeObject(){
>> TimeZone zone = TimeZone.getTimeZone("GMT");
>> ObjectOutputStream ooutput = null;
>> try {
>> ooutput = new ObjectOutputStream(new
>> FileOutputStream("TimeZone.ser"));
>> ooutput.writeObject(zone);
>> } finally {
>> try {
>> if (null != ooutput) {
>> ooutput.close();
>> }
>> } catch (Exception e) {
>> }
>> }
>> }
>>
>> 2. Trying to deserialize this object from file, run codes below
>> public void readObject(){
>> ObjectInputStream oinput = null;
>> try {
>> oinput = new ObjectInputStream(new
>> FileInputStream("TimeZone.ser"));
>> TimeZone newObj = (TimeZone)oinput.readObject();
>> } finally {
>> try {
>> if (null != oinput) {
>> oinput.close();
>> }
>> } catch (Exception e) {
>> }
>> }
>> }
>>
>> Run in RI, passes without any failure
>> Run in Harmony, exception throwed as below:
>> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
>> at java.lang.Class.forName(Class.java:154)
>> at
>> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
>> ... ...
>>
>>
>
>
How to deal with this kind of serialization compatibility issue?
Posted by Paulex Yang <pa...@gmail.com>.
This kind of serialization compatibility issue may be found again later,
if only RI use some non-API class as default implementation of
serializable abstract class. So I think we need some discussion on this
issue for a principle.
I propose two choice:
1. just let it be
2. mimic a class as RI, in this TimeZone case, create a
sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
works but risky and ugly, it is risky because RI may change the
implementation class later(which will also break RI's serialization
compatibility of course)
comments?
Paulex Yang (JIRA) wrote:
> java.util.TimeZone's default implementation may cause many classes' serialization non-compatible with RI
> --------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-184
> URL: http://issues.apache.org/jira/browse/HARMONY-184
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Paulex Yang
> Priority: Critical
>
>
> Static factory methods, java.util.TimeZone.getInstance(String) and getDefault(), are only ways to get a TimeZone instance, but Harmony and RI uses different classes as default implementation, which cause serialization non-compatible. Further, all classes whose serialization form includes TimeZone won't compatible with RI, too, for example, java.util.Calendar(with subclass), java.text.DateFormat(with subclass), etc.
>
> But the incompatiblity is hard to be imputed to Harmony, because Harmony use API class SimpleTimeZone as default implementation, but RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
>
> The reproduce procedure:
> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> public void writeObject(){
> TimeZone zone = TimeZone.getTimeZone("GMT");
> ObjectOutputStream ooutput = null;
> try {
> ooutput = new ObjectOutputStream(new FileOutputStream("TimeZone.ser"));
> ooutput.writeObject(zone);
> } finally {
> try {
> if (null != ooutput) {
> ooutput.close();
> }
> } catch (Exception e) {
> }
> }
> }
>
> 2. Trying to deserialize this object from file, run codes below
> public void readObject(){
> ObjectInputStream oinput = null;
> try {
> oinput = new ObjectInputStream(new FileInputStream("TimeZone.ser"));
> TimeZone newObj = (TimeZone)oinput.readObject();
> } finally {
> try {
> if (null != oinput) {
> oinput.close();
> }
> } catch (Exception e) {
> }
> }
> }
>
> Run in RI, passes without any failure
> Run in Harmony, exception throwed as below:
> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> at java.lang.Class.forName(Class.java:154)
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> ... ...
>
>
--
Paulex Yang
China Software Development Lab
IBM
[jira] Updated: (HARMONY-184) java.util.TimeZone's default
implementation may cause many classes' serialization non-compatible with RI
Posted by "Paulex Yang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-184?page=all ]
Paulex Yang updated HARMONY-184:
--------------------------------
Attachment: TimeZone.ser
the serialized file generated by RI is attached.
> java.util.TimeZone's default implementation may cause many classes' serialization non-compatible with RI
> --------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-184
> URL: http://issues.apache.org/jira/browse/HARMONY-184
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Paulex Yang
> Priority: Critical
> Attachments: TimeZone.ser
>
> Static factory methods, java.util.TimeZone.getInstance(String) and getDefault(), are only ways to get a TimeZone instance, but Harmony and RI uses different classes as default implementation, which cause serialization non-compatible. Further, all classes whose serialization form includes TimeZone won't compatible with RI, too, for example, java.util.Calendar(with subclass), java.text.DateFormat(with subclass), etc.
> But the incompatiblity is hard to be imputed to Harmony, because Harmony use API class SimpleTimeZone as default implementation, but RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
> The reproduce procedure:
> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> public void writeObject(){
> TimeZone zone = TimeZone.getTimeZone("GMT");
> ObjectOutputStream ooutput = null;
> try {
> ooutput = new ObjectOutputStream(new FileOutputStream("TimeZone.ser"));
> ooutput.writeObject(zone);
> } finally {
> try {
> if (null != ooutput) {
> ooutput.close();
> }
> } catch (Exception e) {
> }
> }
> }
> 2. Trying to deserialize this object from file, run codes below
> public void readObject(){
> ObjectInputStream oinput = null;
> try {
> oinput = new ObjectInputStream(new FileInputStream("TimeZone.ser"));
> TimeZone newObj = (TimeZone)oinput.readObject();
> } finally {
> try {
> if (null != oinput) {
> oinput.close();
> }
> } catch (Exception e) {
> }
> }
> }
> Run in RI, passes without any failure
> Run in Harmony, exception throwed as below:
> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> at java.lang.Class.forName(Class.java:154)
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> ... ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira