[
https://issues.apache.org/jira/browse/UIMA-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-5566.
----------------------------------
Resolution: Won't Fix
> uv3 change way 0-length arrays are created, remove new (in v3) APIs for them
> ----------------------------------------------------------------------------
>
> Key: UIMA-5566
> URL: https://issues.apache.org/jira/browse/UIMA-5566
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 3.0.0SDK-alpha02
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 3.0.0SDK-beta
>
>
> I rediscovered that some of the deserialization code (e.g. xmi
> deserialization) has been deserializing empty lists by reusing a shared
> instance (for a particular CAS) of an empty list.
> This seems like Java's sharing of other immutable objects, such as Integer
> (when you say new Integer(4), it returns you a shared object; likewise,
> strings like "123" are merged and shared where possible).
> The 3.0.0-beta had previously introduced a bunch of methods on CAS and JCas
> to get shared 0-length arrays and lists.
> I'm think it would be good to remove all of these, and instead, just change
> the creation of these to automatically reuse shared (per CAS) instances of
> these.
> This has a small (tiny?) potential to "break" existing code, if code was
> written that depended on two different instances of, for example, an FSArray
> of length 0, were required to be !=.
> A recovery mechanism (workaround) for these probably very rare cases would be
> to enable the creation of non-equal instances, perhaps via the clone()
> method. Even this is probably not really needed, and deserialization would
> still be reusing shared values.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
