I just noticed that this change introduced several methods to JCas
version of things like FSArray, which look like stubs that do nothing.
For instance, there is a method in FSArray "toStringArray" which calls
an empty stub "copyToArray"
public void copyToArray(int srcOffset, String[] dest, int destOffset,
int length)
throws ArrayIndexOutOfBoundsException {
// TODO Auto-generated method stub
}
public String[] toStringArray() {
final int size = size();
String[] strArray = new String[size];
copyToArray(0, strArray, 0, size);
return strArray;
}
The corresponding methods in ArrayFSImpl are not stubs.
Shouldn't these stubs have real implementations?
-Marshall
Thilo Goetz (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Thilo Goetz closed UIMA-301.
> ----------------------------
>
> Resolution: Fixed
> Fix Version/s: 2.3
>
> All CAS array types now inherit from org.apache.uima.cas.CommonArrayFS.
>
> Marshall, I had to make some minor changes to JCAS types. Please check.
>
>
>
>> CAS APIs should make it easier to deal with arrays of unknown element type
>> --------------------------------------------------------------------------
>>
>> Key: UIMA-301
>> URL: https://issues.apache.org/jira/browse/UIMA-301
>> Project: UIMA
>> Issue Type: Wish
>> Components: Core Java Framework
>> Reporter: Adam Lally
>> Assignee: Thilo Goetz
>> Priority: Minor
>> Fix For: 2.3
>>
>>
>> There are several places in tools where we need to display the contents of
>> an FS, which could be an array. Currently we have to iterate over all
>> possible primivie-typed arrays in order to access and display their elements.
>> What would have been nice is a common superinterface of all the
>> primitive array types, which defines a toStringArray() method. The
>> toStringArray() methods are already there on the impls, but there's no
>> superinterface that I can use to get at them.
>> See UIMA-40 and UIMA-77.
>>
>
>
