[ 
http://jira.jboss.com/jira/browse/JBAS-1579?page=comments#action_12316401 ]
     
Scott M Stark commented on JBAS-1579:
-------------------------------------

The diffs in terms of obtaining the serialVersionUID should be encapsulated in 
the java.io.ObjectStreamClass.getSerialVersionUID used by the 
org.jboss.tools.SerialVersionUID utility class so there is no need to reproduce 
this behavior. We should be using the exact same algorithm as the vm so that 
the serialVersionUID can be calculated by tools such as serialver of the jdk.

In terms the comparison of the jbossall-client.jar vs the classes in /lib and 
/server/all as calculated by the SerialVersionUID there are two problems.

1. The size of the serialVersionUID databases are more than 10x larger. For 
example, the 4.0.1 jbossall-client.jar vs the 
testsuite/src/etc/serialVersionUID/401.ser is:

342882 401.ser
4148296 jbossall-client.jar

If this is going to be part of the intrinsic testsuite archiving the 
jbossall-client.jar is too much.

2. All server classes need to be validated for serialVersionUID changes. There 
are many paths that do not involve clients which still serialize objects that 
need validation.

I would just merge your test result into the existing 
SerialVersionUIDUnitTestCase.


> Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
> -----------------------------------------------------------------------------
>
>          Key: JBAS-1579
>          URL: http://jira.jboss.com/jira/browse/JBAS-1579
>      Project: JBoss Application Server
>         Type: Bug
>     Versions:  JBossAS-4.0.2RC1,  JBossAS-4.0.1 SP1
>     Reporter: Scott M Stark
>     Assignee: Clebert Suconic
>     Priority: Blocker
>      Fix For: JBossAS-4.0.2 Final
>  Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip, 
> compatibilityCheckProposedSourceCde.zip
>
>
> I'm seeing incomptibilities between versions that are simply due to the fact 
> that Serializable/Externalizable classes are letting their serialVersionUIDs 
> float instead of explicitly defining them. We need to get this cleaned up. 
> There should not be a single Serializable/Externalizable class that does not 
> fix its serialVersionUID and then take responsibility for maintaining 
> compatibility with the indicated version.
> The attached SerializableHasSerialVersionUIDField.zip unzips to create a 
> SerializableHasSerialVersionUIDField-index.html and 
> SerializableHasSerialVersionUIDField directory which is a report of all 
> classes in the 4.0 codebase that are not defining a serialVersionUID as they 
> should. 
> The JDK object serialization spec defines all you need to know about the apis 
> and contracts for object serialization:
> http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html
> In particular, Versioning of Serializable Objects:
> http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419
> talks about binary compatibility and what is available to manage this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to