You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2017/09/13 12:14:00 UTC

[jira] [Created] (UIMA-5566) uv3 change way 0-length arrays are created, remove new (in v3) APIs for them

Marshall Schor created UIMA-5566:
------------------------------------

             Summary: 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)