[
https://issues.apache.org/jira/browse/UIMA-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-6047:
---------------------------------
Summary: uv3 deserialization of typed arrays could be faulty in edge case
(was: uv3 deserialization of type arrays could be faulty in edge case)
> 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)
