testcase SerialVersionUIDUnitTestCase fails on HPUX

[prakashbabu]

Hello All,

I am working on HPUX and using JBoss 4.0.2
The test org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase fails on HPUX but passes in Linux

Reason:
There is a mismatch with the version UID of the class javax.xml.namespace.QName

Linux
current value : -3852060120346905000
previous value : -3852060120346905000

HPUX
current value : 4418622981026545151
previous value : -3852060120346905000


Already an bug has been reported by Scott M Stark for the same issue and is closed.
http://jira.jboss.com/jira/browse/JBAS-2095


What is the reason for this mismatch ?
How can it be solved ?

Thanks,
Prakash

[clebert.suconic]

IMO or you are doing something wrong.
or
There is something wrong on HP-UX's JVM.


version UID are calculated or statically defined on the class. On this case:

public class QName implements Serializable
{
 /** @since 4.0.2, compatible with jdk5 by default */
 final static long serialVersionUID;
 static
 {
 if (SerialVersion.version == SerialVersion.LEGACY)
 serialVersionUID = 8217399441836960859L;
 else
 serialVersionUID = -3852060120346905000L;
 }

The ID you are getting is nor 8217399441836960859L, nor 3852060120346905000L, so you have something odd going on.


--clebert

[clebert.suconic]

To test this possibility:

There is something wrong on HP-UX's JVM.

You would probably have to debug java.io.ObjectOutputStream on the routine that gets the static field or caclulcates the ID.

[adrian.brock]

Could it be that the field is not declared final?

The eclipse3 compiler also complains that the class does not define a "serialVersionUID"
because it is not final.

[starksm64]

Meaning that the serialization layer won't honor the non-final serialVersionUID so it recalculates it?

[clebert.suconic]

Geez... you're right...

ObjectStreamClass checks for final fields only, and recalculates if it's not final:



public class ObjectStreamClass implements Serializable {


.....

private static Long getDeclaredSUID(Class cl) {
try {
Field f = cl.getDeclaredField("serialVersionUID");
int mask = Modifier.STATIC | Modifier.FINAL;
if ((f.getModifiers() & mask) == mask) {
f.setAccessible(true);
return new Long(f.getLong(null));
}
} catch (Exception ex) {
}
return null;
}

....

[clebert.suconic]

Scratch that please...
The field is static final...


so, I don't know!

[adrian.brock]

Correct. I was looking at the class in head
http://anoncvs.forge.jboss.com:8080/viewrep/~raw,r=1.4/JBoss/jboss-common/src/main/javax/xml/namespace/QName.java

[clebert.suconic]

My understanding is he was using Jboss 4.0.2

The field was "final static" already on 4.0-x... wasn't?


Clebert

[starksm64]

Yes, 4.0.x is final but head is not. I have corrected the head version.

[prakashbabu]

Hello all.

I tried the setting the value of serialVersionUID to -3852060120346905000L in the
common/src/main/javax/xml/namespace/QName.java file as below

final static long serialVersionUID= -3852060120346905000L;

But still I get the same mismatch error.
J2EE1.4 (4.0.1) :-3852060120346905000L
current (4.0.2) : 4418622981026545151

I feel the current value is getting calculated(4418622981026545151) inspite me setting serialVersionUID as a final static variable (-3852060120346905000L) .

I have another HPUX machine of the same flavor(11.11PA). Here the values are different

J2EE1.4 (4.0.1) :8217399441836960859
current (4.0.2) :-3852060120346905000

Both have the same JVM installed.

Can somebody tell me the process of how the compatibility is checked
and where exactly I am going wrong ?

Thanks,
Prakash

[starksm64]

You need to get into the SerialVersionUIDUnitTestCase source and follow the uid generation to see how its interacting with the jdk.

[prakashbabu]

Hi.

I have resolved the problem regarding mismatch of version UID of class javax.xml.namespace.QName

The problem was with jaxp-api.jar file which resided in my JAVA_HOME directory (/opt/java1.4/jre/lib/endorsed/jaxp-api.jar).

This jar file also has an class javax.xml.namespace.QName with version UID 4418622981026545151L.

Once I removed this jar file the issue is resolved.

Thanks for your valuable suggestions which helped me resolve this issue.

--Prakash