+1. New methods on CAS and JCas: getEmptyList(FloatList.class)
getEmptyFloatList() etc. for the other 3 lists (integer, string, fs) getEmptyArray(FloatArray.class) getEmptyFloatArray() etc. for the other 8 types (boolean, byte, short, integer, long, double, string, fs) -Marshall On 9/15/2017 3:47 AM, Richard Eckart de Castilho wrote: > The CAS could have a convenience method to fetch a zero-length instance, like > e.g. Collections.emptyList() which could return a shared instance. Users > caring > to optimize could use that without having to implement their own code for > managing > a shared instance. Users relying on object identity could just manually > create an > instance. > > WDYT? > > -- Richard > >> On 14.09.2017, at 16:36, Marshall Schor <m...@schor.com> wrote: >> >> I was mistaken about Java in one detail: for things like Integer(17), there >> are >> two ways to create it: new Integer(17), or Integer.valueOf(17). The first >> call >> does create a fresh, not == to any other Integer object, while the 2nd call >> will >> reuse an existing Integer object for 17 (if it exists). Users are >> encouraged to >> switch to Integer.valueOf(xxx) for efficiency in the Javadocs. >> >> I'm now slightly leaning against doing this change for UIMA, because of the >> edge >> cases where the user could have depended on object un-equality for 0-length >> arrays and lists. >> >> Users could "manually" achieve the same result using the shared instance >> values, >> and (for xmi serialization) marking any features that contain these values as >> "multi-references-allowed" so the deserialization would share them. This >> could >> become a suggested "best practice" for those who use 0-length arrays and >> empty >> lists. >> >> Not doing this would make two Jiras a "won't fix": >> https://issues.apache.org/jira/browse/UIMA-5564 >> https://issues.apache.org/jira/browse/UIMA-5566 >> >> What do others think? >> >> -Marshall >