[
https://issues.apache.org/jira/browse/UIMA-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873417#comment-16873417
]
Marshall Schor commented on UIMA-6047:
--------------------------------------
Here's what got implemented.
1) an extension to JCas's methods to create 0-length FSArrays, which allows
passing in the type of the array (in case it's a "typed" FSArray). These have
a unique shared instance of the 0-length array, lazily created as before, but
one per subtype.
2) the deserializing methods, when creating a 0-length array, use the new typed
0-length array creation.
3) the fixup is done if the array is not already a subtype.
4) the fixup is done, even for features marked as multiple-references-allowed,
because the user would need to declare these to be of the same subtype. Note:
this is not checked at this time.
5) there is a new -D flag to force deserialization to create plain fsarrays (no
subtypes), if needed for backwards compatibility with V2.
> 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)
