XStream
  1. XStream
  2. XSTR-769

Failure when unmarshaling non-static classes serialized with a different compiler

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.1
    • Fix Version/s: 1.4.x Maintenance
    • Component/s: None
    • Labels:
      None

      Description

      Switching from the eclipse compiler to oracle or vice versa leads to a failure when unmarshaling a non-static object. The compilers generate different indexes for the this$N fields which causes a field not found exception.

      I've attached a patch with a testcase which illustrates the problem and a stab at fixing it. The solution is to always put "defined-in" attribute for the this$N fields and at unmarshaling time completely ignore the name of the field in XML and find it by looking at the class fields.

        Activity

        Hide
        Jörg Schaible added a comment -

        Thanks for the interesting example. I took a little different approach in the mapper only, based on the fact that the declaration sequence of the fields will be the same independent of the used compiler.

        Show
        Jörg Schaible added a comment - Thanks for the interesting example. I took a little different approach in the mapper only, based on the fact that the declaration sequence of the fields will be the same independent of the used compiler.
        Jörg Schaible made changes -
        Field Original Value New Value
        Resolution Fixed [ 1 ]
        Fix Version/s 1.4.x Maintenance [ 19602 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Svetoslav Neykov added a comment -

        The change in the v-1.4.x branch will break compatibility with previous patch versions. I guess that's fine but wanted to point it out anyway.
        Thanks for the quick fix.

        Show
        Svetoslav Neykov added a comment - The change in the v-1.4.x branch will break compatibility with previous patch versions. I guess that's fine but wanted to point it out anyway. Thanks for the quick fix.
        Hide
        Jörg Schaible added a comment -

        What do you mean? There's no incompatibility with older versions. The version in trunk can still read the old format, but will write in a new one.

        Show
        Jörg Schaible added a comment - What do you mean? There's no incompatibility with older versions. The version in trunk can still read the old format, but will write in a new one.
        Hide
        Svetoslav Neykov added a comment -

        I meant that 1.4.2 won't be able to read 1.4.3 format.

        Show
        Svetoslav Neykov added a comment - I meant that 1.4.2 won't be able to read 1.4.3 format.
        Hide
        Jörg Schaible added a comment -

        Yes, XML compatibility has always been upwards, but not necessarily downwards.

        Show
        Jörg Schaible added a comment - Yes, XML compatibility has always been upwards, but not necessarily downwards.

          People

          • Assignee:
            Jörg Schaible
            Reporter:
            Svetoslav Neykov
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: