jaxb
  1. jaxb
  2. JAXB-887

Serializable Bindings Should Auto-Generate serialVersionUID values

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: schemagen, xjc
    • Labels:
      None

      Description

      The bindings allow for auto-generation of serializable beans. However, the UID for global settings sets all of the auto-generated beans to use the same default serialVersionUID. The use of a uid tag should allow for auto-generation of serialVersionUID values.

      Perhaps this would be accomplished with something like this.

      <jaxb:serializable uid="auto"/>

        Activity

        Hide
        Iaroslav Savytskyi added a comment -

        We have discussed this idea within our team.

        And appropriate solution for you is to create xjc plugin which will implement required functionality.

        Show
        Iaroslav Savytskyi added a comment - We have discussed this idea within our team. And appropriate solution for you is to create xjc plugin which will implement required functionality.
        Hide
        jyeary added a comment -

        The xjc program should generate Java classes which meet the requirements/expectations of the JLS Chapter 13 for binary compatibility [1], Java Object Serialization Specification Section 1.10 Serializable Interface [2], and Serializable Interface [3] which includes the following quote:

        "...it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members. [sic]"

        Since there is a global variable which allows for serialization, it should be compliant with the intent of providing the API user, classes which meet the expectations of the interface definition.

        Please reconsider having end users create a piece-meal solutions which should really be a part of the xjc application itself. As an API user, I should not need to concern myself with low level details that should be a part of the auto-generation mechanism.

        [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html
        [2] http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#4539
        [3] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html

        Show
        jyeary added a comment - The xjc program should generate Java classes which meet the requirements/expectations of the JLS Chapter 13 for binary compatibility [1] , Java Object Serialization Specification Section 1.10 Serializable Interface [2] , and Serializable Interface [3] which includes the following quote: "...it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members. [sic] " Since there is a global variable which allows for serialization, it should be compliant with the intent of providing the API user, classes which meet the expectations of the interface definition. Please reconsider having end users create a piece-meal solutions which should really be a part of the xjc application itself. As an API user, I should not need to concern myself with low level details that should be a part of the auto-generation mechanism. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html [2] http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#4539 [3] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
        Hide
        Iaroslav Savytskyi added a comment - - edited

        Hi, jyeary,

        Thanks a lot for your argumentation. We'll need to re-discuss this improvement once again.

        As I see from jaxb spec:

        7.5.6.
        ...
        The JAXB user is required to identify when schema-derived classes do not
        follow Java serialization class evolution rules and change the generated
        serialVersionUID field by changing the [serializable] element’s attribute
        @uid value.

        Show
        Iaroslav Savytskyi added a comment - - edited Hi, jyeary, Thanks a lot for your argumentation. We'll need to re-discuss this improvement once again. As I see from jaxb spec: 7.5.6. ... The JAXB user is required to identify when schema-derived classes do not follow Java serialization class evolution rules and change the generated serialVersionUID field by changing the [serializable] element’s attribute @uid value.

          People

          • Assignee:
            Iaroslav Savytskyi
            Reporter:
            jyeary
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: