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

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

     [ https://issues.apache.org/jira/browse/UIMA-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor updated UIMA-5566:
---------------------------------
    Comment: was deleted

(was: This is the patch, copied from the original link, so it's permanently here.  I found I had to change the first 3 lines where it said uimaj-tools/src/main/... to just src/main/..., in order to get Eclipse to apply the patch.)

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