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

Reply via email to