Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5072004

Better support for schema evolution in CompositeData and CompositeType

    Details

    • Subcomponent:
    • Resolved In Build:
      b81
    • CPU:
      generic
    • OS:
      generic

      Description

      -1-

      CompositeType.isValue, following the inherited contract for OpenType.isValue, tests whether its argument is a CompositeData whose CompositeType is equal to this one. In other words, the CompositeData must have exactly the same item names and types as described in this CompositeType. This is needlessly restrictive, and harms schema evolution. Instead, CompositeType.isValue should return true provided that its argument is a CompositeData whose CompositeType is an improper superset of this one. In other words, the CompositeData argument can contain extra items and they will be ignored by isValue.

      This allows new items to be added to the information model. A peer (client or server) that does not know about those new items will never see them, and if takes the trouble to call isValue it will accept the newer CompositeData.

      -2-

      When a newer client or server receives a CompositeData from a possibly older peer, the added items may be missing. The newer peer of course knows that the items are new, and should add default values to the CompositeData when they are missing. It would be convenient if CompositeDataSupport had a constructor to simplify this:

          public CompositeDataSupport(CompositeType type,
                                      CompositeData cd,
                                      String[] defaultNames,
                                      Object[] defaultValues)

      and/or

          public CompositeDataSupport(CompositeType type,
                                      CompositeData cd,
                                      Map<String,?> defaults)

      If an item is in the CompositeType argument, but is in neither the CompositeData nor the defaults, then that should generate an exception. Trying to fabricate a default value as a convenience (e.g. 0 for a SimpleType.INTEGER) seems tricky, particularly in the more complicated cases (e.g. when the missing item is itself a CompositeData or TabularData). This is not much of a convenience and loses error-checking.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                emcmanus Eamonn McManus
                Reporter:
                emcmanus Eamonn McManus
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: