Overview Description: The serialVersionUID for the original QName as used by JAX-RPC 1.0 was -9120448754896609940. The suid for the JAXP 1.3 version is 4418622981026545151. This means instances of the old class cannot be serialized into the new class. Steps to Reproduce: Use a J2SE 1.4 JVM (don't use J2SE 5 as this includes QName class in rt.jar - we're testing the QName in XmlCommons xml-apis.jar) Test case at: http://people.apache.org/~hughesj/bugs/QName/QNameReadObjectNull.zip cd into QNameReadObjectNull/bin directory. java -cp .;<path to xml-apis.jar shipped in xerces2_7_1>;<path to junit.jar> javax.xml.namespace.QNameTest results in: .E Time: 0.2 There was 1 error: 1) testGoodDeserializeQNameWithoutPrefix(javax.xml.namespace.QNameTest)java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = -9120448754896609940, local class serialVersionUID = 4418622981026545151 ... Expected Results: Test should pass Note this test case is a subset of a test case in Apache Woden: http://svn.apache.org/repos/asf/incubator/woden/java/test/javax/xml/namespace/ Thanks, Jeremy Hughes (hughesj at apache.org)
Can this really be changed now? I did some investigating and here's what I've found. The QName in JAX-RPC 1.0 [1] didn't have an explicitly declared serialVersionUID, nor did it have the prefix property. I'm guessing the value posted in the original comment is the runtime calculated value. The QName that's being packaged by Sun as part of the Java Web Services Developer Pack v1.6 [2] has the serialVersionUID of 4418622981026545151. The QName that's being packaged by Sun in the J2EE 1.4 SDK with the Sun Java Application Server [3] doesn't explicitly declare a serialVersionUID, but does have a prefix property. This should then change the generated ID, correct? The QName that's being packaged with Geronimo [4] is similar to this one; no ID, but has a prefix field. The QName that's being packaged in Sun's Java SE 5 SDK [5] and BEA's Java SE 5 SDK [6] have the serialVersionUID of 4418622981026545151. I would assume other Java SE 5 SDK distributions have the same values. I understand there's a need for passivity here, but I this point I'd say the cat is out of the bag and the ID of 4418622981026545151 has become the defacto "correct" version, especially since it's part of the Java SE 5 Javadoc [5]. [1] http://java.sun.com/xml/downloads/javaxmlpack.html [2] http://java.sun.com/webservices/downloads/webservicespack.html [3] http://java.sun.com/j2ee/1.4/download.html [4] http://svn.apache.org/viewcvs.cgi/geronimo/specs/trunk/geronimo-spec-qname/src/java/javax/xml/namespace/QName.java?view=markup [5] http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#javax.xml.namespace.QName [6] http://edocs.bea.com/wljrockit/docs50/index.html Besides the Java SE 5 Javadoc, I got the rest of the information by looking at the class files.
This is a real interoperability problem. Because the serialVersionUIDs do not match, currently QNames cannot be exchanged between J2SE 5.0 and J2EE 1.4. Sun has acknolwedged the problem and has addressed it [1] (see evaluation at the bottom of the bug report) by restoring -9120448754896609940 as the serialVersionUID. I believe the same should be done in the Apache version, preferably sooner than later to minimize the impact on users. If this isn't changed now I can see it becoming a bigger issue when Apache Harmony eventually picks up the XML APIs. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6355051
While looking through those bug evaluations, it looks like the the resolution wasn't just to replace the serialVersionUID with the original, but also to provide a compatibility property that could be used to swap the ID. I found this note about it [1] in Sun's JAXP 1.3.1 revision notes. Apparently a similar solution was used for some JMX classes. Should the same compatibility property be provided in xml-commons as well? Should there be a property, but of a different name? In any case, it seems that the default value is now the original value of "-9120448754896609940". [1] http://java.sun.com/webservices/docs/2.0/jaxp/ReleaseNotes.html#migrationFrom13
Created attachment 17422 [details] Patch for javax.xml.namespace.QName A proposal patch for fixing the QName serialVersionUID. This patch returns the default suid to what was packaged with J2EE 1.4 and provides a means of setting a System Property to switch the suid to a compatibility value to work with the QName packaged in Java 5 SE. The System Property is based on the Sun JAXP 1.3.1 RI release notes [1]. The property name may need to change, but the current key name allows for compatibility with Sun Java Web Services toolkit. Another item that may need to be added is looking up the property value via a privileged action, but I'm not completely familiar with the security model, if any, here. [1] http://java.sun.com/webservices/docs/2.0/jaxp/ReleaseNotes.html#migrationFrom13
Hi Nathan, from the Sun release notes for jaxp [1] I wasn't entirely clear which serialVersionUID was the compatible one and which was the default! In your patch you have the original (-9120448754896609940L suid) as the default which is great - this is what I want, however I'm just wondering whether this is what Sun meant. Have you by any chance tried Sun's jaxp 1.3.1 RI to see if their code does the same? Thanks, Jeremy [1] http://java.sun.com/webservices/docs/2.0/jaxp/ReleaseNotes.html#migrationFrom13
I determined which was the default and compatibility ID by downloading the JWSDP 2.0 and loading the jaxp-api.jar into Eclipse and looked at the class in the binary Class File Editor (viewer) and it showed the following static fields. private static final long defaultSerialVersionUID = -9120448754896609940L; private static final long compatibleSerialVersionUID = 4418622981026545151L; From this I assume the "default*" was the default setting. I can try to serialize an object from Sun's impl to a file and then try to deserialize it with the commons version. This is probably about the best we can do for a unit test.
Hi Nathan, Since this is the Apache implementation of QName (and also considering that Apache Harmony probably won't contain com.sun.* classes), my preference for the property name would be org.apache.xml.namespace.QName.useCompatibleSerialVersionUID. Regarding looking up system properties and Java's security model, there's a package private class called SecuritySupport which exists in all JAXP subpackages which need to execute privileged actions. A copy could be added to javax.xml.namespace.
Created attachment 17544 [details] QName.java Patch (apache) Replacement patch. Provides security support for the system property lookup. Instead of copying the entire SecuritySupport class, I just created an inline PrivilegedAction. The System property is named "org.apache.xml.namespace.QName.useCompatibleSerialVersionUID".
Created attachment 17545 [details] QName.java Patch (jaxp) This is an alternate version of the previous patch. The only difference is that this uses the QName's fully qualified class name as the System property prefix. The System property is named "javax.xml.namespace.QName.useCompatibleSerialVersionUID".
Thanks Nathan. I chose the the "org.apache.xml.namespace.QName.useCompatibleSerialVersionUID" patch and committed to SVN (with some minor clean-up).