[
https://issues.apache.org/jira/browse/UIMA-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873373#comment-16873373
]
Marshall Schor commented on UIMA-6047:
--------------------------------------
I'm leaning towards keeping the deserialization fixing up the type to reflect
the type's element-type. Cas Compare code would be updated to allow for this.
The fixup would be skipped if the feature structure is shared, and all shared
instances are not of the same element type. This would be perhaps expensive to
compute in practice, so, some compromise/balance will be implemented.
> uv3 deserialization of typed arrays could be faulty in edge case
> ----------------------------------------------------------------
>
> Key: UIMA-6047
> URL: https://issues.apache.org/jira/browse/UIMA-6047
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 3.0.2SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Major
> Fix For: 3.0.3SDK
>
>
> UIMA has some limited support for typed arrays. These are declared in type
> system descriptors by including an elementType specification for a feature
> whose range is FSArray.
> See
> [http://uima.apache.org/d/uimaj-current/references.html#ugr.ref.xml.component_descriptor.type_system.features]
> The XCAS and the Xmi serialization forms serialize these as FSArray. The
> deserialization code, when deserializing these, looks at the feature
> declaration to see if it has an elementType, and if so, changes the type of
> the Feature Structure to that type.
> This is fine except for two cases:
> 1) backwards compatibility - this wasn't done in v2. This might be an
> ignorable difference (except for utilities that compare CASs, and don't
> accommodate this).
> 2) (more important) Sometimes feature structures are "shared" - that is,
> multiple different features might reference the same one. These features
> might not have the same element type. A not unusual use case is the one
> where the item being referenced is a 0-length Feature Structure, and the code
> is sharing one common (immutable) instance of this.
> For #2, one possible fix is to examine the "multipleReferencesAllowed"
> property of the feature, and only do this narrowing of the type if this is
> false, and the rest of the code hasn't accidentally shared this feature
> structure with other references.
> For #1, perhaps the right approach is to have a backwards compatibility -D
> flag that (if set) avoids doing this type update when deserializing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
