Re: Generification of FSIndex
Adam Lally wrote: On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schorm...@schor.com wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmannkottm...@gmail.com wrote: Marshall Schor wrote: The generification of FSIndex currently specifies one type, T extends FeatureStructure that is the type of item being returned. The contains and find methods have arguments of type FeatureStructure. These could be changed to take type T. No I do not think that they could be changed to take type T. Lets take the case of the contains method. The javadoc says: Check if the index contains an element equal to the given feature structure according to the ordering of the index. Note that this is in general not the same as feature structure identity. and it for the param fs it says The FS we're looking for.. There is no place where it says that contains can only be called for FSes which have the type of the index. The change of the parameter from FeatureStructure to T would also change the contract of the method a little, because then it would not be possible anymore to pass a FeatureStructure which has not type T. I agree. It's sometimes useful to call FSIterator.moveTo method and pass an FS of a Type other than the one that the index was defined over, as part of implementing something like a subiterator. I agree with the case where it's the bag index being used, because that uses a test which works on all feature structures. However, for Set and Sorted, the implication of passing a FS which is not in the type hierarchy is, according to the JavaDocs, undefined. This is because the code assumes the layout of the features and their values is appropriate for the type. In other words, if the type of some key was a string, it might take a value from the main int heap and use it as an index into the string array - and if the int heap object was not the right type, it could pull an arbitrary value from that slot, and end up throwing an array index out of bounds exception. When I looked, it didn't appear to me that the code checked for any kind of type subsumption before proceeding... (but I may have missed it...) It could turn out that the data (whatever is being pulled) would just happen to match, even though the types are different. Because this is an undefined operation that could throw various kinds of runtime errors, or return an equal match where none really exists, I think it should not be allowed, for set and sorted indexes. In the case of the AnnotationIndex, the object that you pass to FSIterator.moveTo must be a subtype of Annotation (else you would get all the weird effects that you describe). But it is still valid for a user to do: FSIndexAnnotType1 index = cas.getAnnotationIndex(annotType1); index.moveTo(annotType2); where annotType1 and annotType2 are both subtypes of uima.tcas.Annotation. In general, the object that you pass to moveTo() must be a subtype of the type that was in the index definition (in the user's descriptor, or for the case of the built-in AnnotationIndex, uima.tcas.Annotation). -Adam One concrete example of Adam's point: suppose you have a sentenceFS and a tokenIterator. Then tokenIterator.moveTo(sentenceFS) will position the token iterator at the first word in the sentence (modulo some subtleties that are beside the point here). Very useful. --Thilo
Re: Generification of FSIndex
Thilo Goetz wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schorm...@schor.com wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmannkottm...@gmail.com wrote: Marshall Schor wrote: The generification of FSIndex currently specifies one type, T extends FeatureStructure that is the type of item being returned. The contains and find methods have arguments of type FeatureStructure. These could be changed to take type T. No I do not think that they could be changed to take type T. Lets take the case of the contains method. The javadoc says: Check if the index contains an element equal to the given feature structure according to the ordering of the index. Note that this is in general not the same as feature structure identity. and it for the param fs it says The FS we're looking for.. There is no place where it says that contains can only be called for FSes which have the type of the index. The change of the parameter from FeatureStructure to T would also change the contract of the method a little, because then it would not be possible anymore to pass a FeatureStructure which has not type T. I agree. It's sometimes useful to call FSIterator.moveTo method and pass an FS of a Type other than the one that the index was defined over, as part of implementing something like a subiterator. I agree with the case where it's the bag index being used, because that uses a test which works on all feature structures. However, for Set and Sorted, the implication of passing a FS which is not in the type hierarchy is, according to the JavaDocs, undefined. This is because the code assumes the layout of the features and their values is appropriate for the type. In other words, if the type of some key was a string, it might take a value from the main int heap and use it as an index into the string array - and if the int heap object was not the right type, it could pull an arbitrary value from that slot, and end up throwing an array index out of bounds exception. When I looked, it didn't appear to me that the code checked for any kind of type subsumption before proceeding... (but I may have missed it...) It could turn out that the data (whatever is being pulled) would just happen to match, even though the types are different. Because this is an undefined operation that could throw various kinds of runtime errors, or return an equal match where none really exists, I think it should not be allowed, for set and sorted indexes. In the case of the AnnotationIndex, the object that you pass to FSIterator.moveTo must be a subtype of Annotation (else you would get all the weird effects that you describe). But it is still valid for a user to do: FSIndexAnnotType1 index = cas.getAnnotationIndex(annotType1); index.moveTo(annotType2); where annotType1 and annotType2 are both subtypes of uima.tcas.Annotation. In general, the object that you pass to moveTo() must be a subtype of the type that was in the index definition (in the user's descriptor, or for the case of the built-in AnnotationIndex, uima.tcas.Annotation). -Adam One concrete example of Adam's point: suppose you have a sentenceFS and a tokenIterator. Then tokenIterator.moveTo(sentenceFS) will position the token iterator at the first word in the sentence (modulo some subtleties that are beside the point here). Very useful. Yes. This works because the index being iterated over is the general annotation index (the one that's built-it) - and the presumeption is that token and sentenceFS are both subtypes of AnnotationFS. Is there any reason *not* to add a check to the various methods in indexing that take one or more Feature Structures, to see if they are being passed a subtype of the type being indexed (except for bag indexes)? -Marshall --Thilo
Re: Generification of FSIndex
Marshall Schor wrote: Thilo Goetz wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schorm...@schor.com wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmannkottm...@gmail.com wrote: Marshall Schor wrote: The generification of FSIndex currently specifies one type, T extends FeatureStructure that is the type of item being returned. The contains and find methods have arguments of type FeatureStructure. These could be changed to take type T. No I do not think that they could be changed to take type T. Lets take the case of the contains method. The javadoc says: Check if the index contains an element equal to the given feature structure according to the ordering of the index. Note that this is in general not the same as feature structure identity. and it for the param fs it says The FS we're looking for.. There is no place where it says that contains can only be called for FSes which have the type of the index. The change of the parameter from FeatureStructure to T would also change the contract of the method a little, because then it would not be possible anymore to pass a FeatureStructure which has not type T. I agree. It's sometimes useful to call FSIterator.moveTo method and pass an FS of a Type other than the one that the index was defined over, as part of implementing something like a subiterator. I agree with the case where it's the bag index being used, because that uses a test which works on all feature structures. However, for Set and Sorted, the implication of passing a FS which is not in the type hierarchy is, according to the JavaDocs, undefined. This is because the code assumes the layout of the features and their values is appropriate for the type. In other words, if the type of some key was a string, it might take a value from the main int heap and use it as an index into the string array - and if the int heap object was not the right type, it could pull an arbitrary value from that slot, and end up throwing an array index out of bounds exception. When I looked, it didn't appear to me that the code checked for any kind of type subsumption before proceeding... (but I may have missed it...) It could turn out that the data (whatever is being pulled) would just happen to match, even though the types are different. Because this is an undefined operation that could throw various kinds of runtime errors, or return an equal match where none really exists, I think it should not be allowed, for set and sorted indexes. In the case of the AnnotationIndex, the object that you pass to FSIterator.moveTo must be a subtype of Annotation (else you would get all the weird effects that you describe). But it is still valid for a user to do: FSIndexAnnotType1 index = cas.getAnnotationIndex(annotType1); index.moveTo(annotType2); where annotType1 and annotType2 are both subtypes of uima.tcas.Annotation. In general, the object that you pass to moveTo() must be a subtype of the type that was in the index definition (in the user's descriptor, or for the case of the built-in AnnotationIndex, uima.tcas.Annotation). -Adam One concrete example of Adam's point: suppose you have a sentenceFS and a tokenIterator. Then tokenIterator.moveTo(sentenceFS) will position the token iterator at the first word in the sentence (modulo some subtleties that are beside the point here). Very useful. Yes. This works because the index being iterated over is the general annotation index (the one that's built-it) - and the presumeption is that token and sentenceFS are both subtypes of AnnotationFS. Is there any reason *not* to add a check to the various methods in indexing that take one or more Feature Structures, to see if they are being passed a subtype of the type being indexed (except for bag indexes)? Sure. Suppose B A, and we have an index on B, but the ordering relation is defined in terms of features that B inherits from A. Then I can use an A to position iterators on the B index. This works now, and I don't see why we should prohibit it. -Marshall --Thilo
[jira] Created: (UIMA-1485) UIMA Tutorial and Developers guide in sub title 1.3.2 should be AAE and not AE
UIMA Tutorial and Developers guide in sub title 1.3.2 should be AAE and not AE -- Key: UIMA-1485 URL: https://issues.apache.org/jira/browse/UIMA-1485 Project: UIMA Issue Type: Bug Components: Documentation Affects Versions: 2.2.2 Reporter: Jörn Kottmann Priority: Trivial Fix For: 2.3 1.3.2. AEs can also contain CAS Consumers should be 1.3.2. AAEs can also contain CAS Consumers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: clarifying a generics issue
A small correction: allowing downcasting doesn't generate a warning
about unchecked casting.
Here's a small test case in case you want to play with this:
package generics;
import java.util.List;
public class TestG {
class BoxT { // version returning down-castable thing
U extends T U get() {return null;}
U extends T ListU getL() {return null;}
}
class StrictBoxT { // version returning just type T
T get() {return null;}
ListT getL() {return null;}
}
BoxNumber box = new BoxNumber();
StrictBoxNumber sbox = new StrictBoxNumber();
void test() {
// returning elements
Number n = box.get(); // OK
Integer n2 = box.get(); // OK
Number sn = sbox.get(); // OK
Integer sn2 = sbox.get(); // fails
Integer sn3 = (Integer) sbox.get(); // OK
// returning lists
ListNumber ln = box.getL(); // OK
ListInteger ln2 = box.getL(); // OK
ListNumber sln = sbox.getL(); // OK
ListInteger sln2 = sbox.getL(): // fails, no fix available
}
}
-Marshall
Marshall Schor wrote:
Here's a new thread to discuss just one particular issue - a generics
tradeoff.
In other posts, people have expressed misgivings about letting users
downcast ListsomeType to ListsomeSubType, if it cannot be
*guaranteed* at compile time that this is valid.
Here's a simple example, for instance, using two built-in Java classes:
Number
Integer (a subtype of Number)
If we have a method which returns a ListNumber, and you happen to know
it only contains Integers, and you want to use a for-each on it with a
method that only exists in the Integer class, you have to do manual
casting within the loop.
An alternative might have been to do:
ListNumber numbers = ...;
ListInteger int_version = numbers; // not allowed, gives compile error
So once we're given the numbers object, as far as I can see, we're
stuck with its typing. (Please tell me if I'm wrong here).
I see that there is a trade-off between specifying return types as
specific types, and specifying them as T extends X, and letting the user
specify a possibly incorrect downcast. The tradeoff on the plus side is
that the user gets to write the new style for-each loops, and have code
without casts inside loops, etc., and on the minus side, the user when
doing this gets that warning about the possibility that at runtime a
casting error could be thrown. But of course, that same casting error
could be thrown in restricted style, too, at the point of the explicit
user cast.
I'll probably stop trying to convince others if they continue to feel
that the tradeoffs here should be in the direction of returning only
specific types (disallowing users from specifying downcasting in that
manner), versus using types of the form T extends X,
which allows users to specify downcasting.
I'd be interested in any literature pointers discussing this trade-off
issue, if anyone has good ones :-)
-Marshall
Re: clarifying a generics issue
Marshall Schor wrote:
I'll probably stop trying to convince others if they continue to feel
that the tradeoffs here should be in the direction of returning only
specific types (disallowing users from specifying downcasting in that
manner), versus using types of the form T extends X,
which allows users to specify downcasting.
The case of FSIndexRepository is maybe more clear
then the other cases in our API.
With down casting it could be changed to
interface FSIndexRepository {
T extends FeatureStructure FSIndexT getIndex(String label);
T extends FeatureStructure FSIteratorT getAllIndexedFS(Type aType);
...
}
and then a user could write
FSIndexAnnotationFS index = repo.getIndex(...);
FSIteratorAnnotationFS it = repo.getAllIndexedFS(...);
Jörn
Re: Generification of FSIndex
Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schorm...@schor.com wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmannkottm...@gmail.com wrote: Marshall Schor wrote: The generification of FSIndex currently specifies one type, T extends FeatureStructure that is the type of item being returned. The contains and find methods have arguments of type FeatureStructure. These could be changed to take type T. No I do not think that they could be changed to take type T. Lets take the case of the contains method. The javadoc says: Check if the index contains an element equal to the given feature structure according to the ordering of the index. Note that this is in general not the same as feature structure identity. and it for the param fs it says The FS we're looking for.. There is no place where it says that contains can only be called for FSes which have the type of the index. The change of the parameter from FeatureStructure to T would also change the contract of the method a little, because then it would not be possible anymore to pass a FeatureStructure which has not type T. I agree. It's sometimes useful to call FSIterator.moveTo method and pass an FS of a Type other than the one that the index was defined over, as part of implementing something like a subiterator. I agree with the case where it's the bag index being used, because that uses a test which works on all feature structures. However, for Set and Sorted, the implication of passing a FS which is not in the type hierarchy is, according to the JavaDocs, undefined. This is because the code assumes the layout of the features and their values is appropriate for the type. In other words, if the type of some key was a string, it might take a value from the main int heap and use it as an index into the string array - and if the int heap object was not the right type, it could pull an arbitrary value from that slot, and end up throwing an array index out of bounds exception. When I looked, it didn't appear to me that the code checked for any kind of type subsumption before proceeding... (but I may have missed it...) It could turn out that the data (whatever is being pulled) would just happen to match, even though the types are different. Because this is an undefined operation that could throw various kinds of runtime errors, or return an equal match where none really exists, I think it should not be allowed, for set and sorted indexes. In the case of the AnnotationIndex, the object that you pass to FSIterator.moveTo must be a subtype of Annotation (else you would get all the weird effects that you describe). But it is still valid for a user to do: FSIndexAnnotType1 index = cas.getAnnotationIndex(annotType1); index.moveTo(annotType2); where annotType1 and annotType2 are both subtypes of uima.tcas.Annotation. In general, the object that you pass to moveTo() must be a subtype of the type that was in the index definition (in the user's descriptor, or for the case of the built-in AnnotationIndex, uima.tcas.Annotation). -Adam One concrete example of Adam's point: suppose you have a sentenceFS and a tokenIterator. Then tokenIterator.moveTo(sentenceFS) will position the token iterator at the first word in the sentence (modulo some subtleties that are beside the point here). Very useful. Yes. This works because the index being iterated over is the general annotation index (the one that's built-it) - and the presumeption is that token and sentenceFS are both subtypes of AnnotationFS. Is there any reason *not* to add a check to the various methods in indexing that take one or more Feature Structures, to see if they are being passed a subtype of the type being indexed (except for bag indexes)? Sure. Suppose B A, and we have an index on B, but the ordering relation is defined in terms of features that B inherits from A. Then I can use an A to position iterators on the B index. This works now, and I don't see why we should prohibit it. Right, I knew I was missing some detail. So the test for validity is not a simple subsumes test, but rather a check to see if the feature structure slots used in the keys used for testing by the index are in the same position in the feature structure layout as the type being passed in. Correct? Essentially, yes. If so, is there any reason not to add this as a check? No reason other than that the relevant information is thrown away after the index has been generated, and it would be a medium size effort to implement. I haven't looked
[jira] Created: (UIMA-1486) Lucas should not depend on google collections snapshot version
Lucas should not depend on google collections snapshot version -- Key: UIMA-1486 URL: https://issues.apache.org/jira/browse/UIMA-1486 Project: UIMA Issue Type: Improvement Components: Sandbox-Lucas Reporter: Jörn Kottmann Assignee: Rico Landefeld Fix For: 2.3S Lucas should not depend on google collections snapshot version. It should either be replaced by a release version of google collections or the dependency should be removed. In most places through the code its only used to get an empty iterator which could be done in a util method to avoid this extra dependency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Generification of FSIndex
Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schorm...@schor.com wrote: Adam Lally wrote: On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmannkottm...@gmail.com wrote: Marshall Schor wrote: The generification of FSIndex currently specifies one type, T extends FeatureStructure that is the type of item being returned. The contains and find methods have arguments of type FeatureStructure. These could be changed to take type T. No I do not think that they could be changed to take type T. Lets take the case of the contains method. The javadoc says: Check if the index contains an element equal to the given feature structure according to the ordering of the index. Note that this is in general not the same as feature structure identity. and it for the param fs it says The FS we're looking for.. There is no place where it says that contains can only be called for FSes which have the type of the index. The change of the parameter from FeatureStructure to T would also change the contract of the method a little, because then it would not be possible anymore to pass a FeatureStructure which has not type T. I agree. It's sometimes useful to call FSIterator.moveTo method and pass an FS of a Type other than the one that the index was defined over, as part of implementing something like a subiterator. I agree with the case where it's the bag index being used, because that uses a test which works on all feature structures. However, for Set and Sorted, the implication of passing a FS which is not in the type hierarchy is, according to the JavaDocs, undefined. This is because the code assumes the layout of the features and their values is appropriate for the type. In other words, if the type of some key was a string, it might take a value from the main int heap and use it as an index into the string array - and if the int heap object was not the right type, it could pull an arbitrary value from that slot, and end up throwing an array index out of bounds exception. When I looked, it didn't appear to me that the code checked for any kind of type subsumption before proceeding... (but I may have missed it...) It could turn out that the data (whatever is being pulled) would just happen to match, even though the types are different. Because this is an undefined operation that could throw various kinds of runtime errors, or return an equal match where none really exists, I think it should not be allowed, for set and sorted indexes. In the case of the AnnotationIndex, the object that you pass to FSIterator.moveTo must be a subtype of Annotation (else you would get all the weird effects that you describe). But it is still valid for a user to do: FSIndexAnnotType1 index = cas.getAnnotationIndex(annotType1); index.moveTo(annotType2); where annotType1 and annotType2 are both subtypes of uima.tcas.Annotation. In general, the object that you pass to moveTo() must be a subtype of the type that was in the index definition (in the user's descriptor, or for the case of the built-in AnnotationIndex, uima.tcas.Annotation). -Adam One concrete example of Adam's point: suppose you have a sentenceFS and a tokenIterator. Then tokenIterator.moveTo(sentenceFS) will position the token iterator at the first word in the sentence (modulo some subtleties that are beside the point here). Very useful. Yes. This works because the index being iterated over is the general annotation index (the one that's built-it) - and the presumeption is that token and sentenceFS are both subtypes of AnnotationFS. Is there any reason *not* to add a check to the various methods in indexing that take one or more Feature Structures, to see if they are being passed a subtype of the type being indexed (except for bag indexes)? Sure. Suppose B A, and we have an index on B, but the ordering relation is defined in terms of features that B inherits from A. Then I can use an A to position iterators on the B index. This works now, and I don't see why we should prohibit it. Right, I knew I was missing some detail. So the test for validity is not a simple subsumes test, but rather a check to see if the feature structure slots used in the keys used for testing by the index are in the same position in the feature structure layout as the type being passed in. Correct?
[jira] Updated: (UIMA-1482) Implement PEAR support for UIMA AS
[ https://issues.apache.org/jira/browse/UIMA-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1482: - Affects Version/s: 2.3 defer to after 2.3.0 release Implement PEAR support for UIMA AS -- Key: UIMA-1482 URL: https://issues.apache.org/jira/browse/UIMA-1482 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.3 Reporter: Jörn Kottmann UIMA AS should support the deployment pears. The great advantage of pears is that a user does not have to set up the classpath manually and that the pear can be tested prior deployment with standard uima tooling. One way to implement it would be to extend the AS deployment descriptor to point to a pear file or pear specifier. In the case it points to a pear file uima as must take care of installing the pear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1484) Update UIMA-AS Documentation
[ https://issues.apache.org/jira/browse/UIMA-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1484: - Fix Version/s: 2.3AS Update UIMA-AS Documentation Key: UIMA-1484 URL: https://issues.apache.org/jira/browse/UIMA-1484 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Fix For: 2.3AS Update UIMA-AS documentation to describe new features and changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1480) Add version compatibility verification to UIMA-AS for base UIMA level
[ https://issues.apache.org/jira/browse/UIMA-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1480: Assignee: Jerry Cwiklik Suggest following version info design in base: see UIMAFramework_impl methods _getMajorVersion, _getMinorVersion, and _getBuildRevision, and putting the check somewhere in the uima-as overall startup where it could be done only once, if possible. Add version compatibility verification to UIMA-AS for base UIMA level - Key: UIMA-1480 URL: https://issues.apache.org/jira/browse/UIMA-1480 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Marshall Schor Assignee: Jerry Cwiklik As part of the repackaging of UIMA-AS, it won't necessarily be packaged with a version of base UIMA - so it should verify that the version of base UIMA it is running with is OK. For now, require that it be at the corresponding level that is released - e.g., 2.3.0 for the Base and 2.3.0 for UIMA-AS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1480) Add version compatibility verification to UIMA-AS for base UIMA level
[ https://issues.apache.org/jira/browse/UIMA-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1480: - Fix Version/s: 2.3AS Add version compatibility verification to UIMA-AS for base UIMA level - Key: UIMA-1480 URL: https://issues.apache.org/jira/browse/UIMA-1480 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Marshall Schor Assignee: Jerry Cwiklik Fix For: 2.3AS As part of the repackaging of UIMA-AS, it won't necessarily be packaged with a version of base UIMA - so it should verify that the version of base UIMA it is running with is OK. For now, require that it be at the corresponding level that is released - e.g., 2.3.0 for the Base and 2.3.0 for UIMA-AS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: clarifying a generics issue
On Mon, Aug 10, 2009 at 9:00 PM, Marshall Schorm...@schor.com wrote: Here's a new thread to discuss just one particular issue - a generics tradeoff. In other posts, people have expressed misgivings about letting users downcast ListsomeType to ListsomeSubType, if it cannot be *guaranteed* at compile time that this is valid. Here's a simple example, for instance, using two built-in Java classes: Number Integer (a subtype of Number) If we have a method which returns a ListNumber, and you happen to know it only contains Integers, and you want to use a for-each on it with a method that only exists in the Integer class, you have to do manual casting within the loop. An alternative might have been to do: ListNumber numbers = ...; ListInteger int_version = numbers; // not allowed, gives compile error So once we're given the numbers object, as far as I can see, we're stuck with its typing. (Please tell me if I'm wrong here). I see that there is a trade-off between specifying return types as specific types, and specifying them as T extends X, and letting the user specify a possibly incorrect downcast. The tradeoff on the plus side is that the user gets to write the new style for-each loops, and have code without casts inside loops, etc., and on the minus side, the user when doing this gets that warning about the possibility that at runtime a casting error could be thrown. But of course, that same casting error could be thrown in restricted style, too, at the point of the explicit user cast. I'll probably stop trying to convince others if they continue to feel that the tradeoffs here should be in the direction of returning only specific types (disallowing users from specifying downcasting in that manner), versus using types of the form T extends X, which allows users to specify downcasting. I'd be interested in any literature pointers discussing this trade-off issue, if anyone has good ones :-) One other way to look at this - why are Collections any different than methods that return single elements? If I have a method Number getNumber() and I know in some situation that the Number is really an Integer, should I be able to call: Integer x = getNumber()? Normally such a thing is not allowed without an explicit cast. And for me at least I just take that for granted as part of what a strongly-typed language does, so it's very bizarre to think of it not doing that. -Adam
Re: clarifying a generics issue
On Tue, Aug 11, 2009 at 7:50 AM, Marshall Schorm...@schor.com wrote:
A small correction: allowing downcasting doesn't generate a warning
about unchecked casting.
Here's a small test case in case you want to play with this:
package generics;
import java.util.List;
public class TestG {
class BoxT { // version returning down-castable thing
U extends T U get() {return null;}
U extends T ListU getL() {return null;}
}
class StrictBoxT { // version returning just type T
T get() {return null;}
ListT getL() {return null;}
}
BoxNumber box = new BoxNumber();
StrictBoxNumber sbox = new StrictBoxNumber();
void test() {
// returning elements
Number n = box.get(); // OK
Integer n2 = box.get(); // OK
Number sn = sbox.get(); // OK
Integer sn2 = sbox.get(); // fails
Integer sn3 = (Integer) sbox.get(); // OK
// returning lists
ListNumber ln = box.getL(); // OK
ListInteger ln2 = box.getL(); // OK
ListNumber sln = sbox.getL(); // OK
ListInteger sln2 = sbox.getL(): // fails, no fix available
}
}
For a complete picture you should also try to implement the methods to
return something other that null. For example how to you implement
U extends T U get() such that it returns an instance of U regardless
of what U is? You could only do this with a typecast. And you'd have
to expectation that the typecast would actually succeed.
-Adam
[jira] Updated: (UIMA-1459) Fix UIMA AS bugs reported by Findbugs
[ https://issues.apache.org/jira/browse/UIMA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1459: - Fix Version/s: 2.3AS Fix UIMA AS bugs reported by Findbugs - Key: UIMA-1459 URL: https://issues.apache.org/jira/browse/UIMA-1459 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Bhavani Iyer Fix For: 2.3AS There are many bugs found by Findbugs in the UIMA As code. Some are minor like a deadstore in a var that is never used. Others are more severe like dereferencing a var that is not checked for NULL. Clean up the code to eliminate reported bugs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1447) Tabulations are annotated as tokens after a space
[ https://issues.apache.org/jira/browse/UIMA-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1447: Assignee: Marshall Schor Tabulations are annotated as tokens after a space - Key: UIMA-1447 URL: https://issues.apache.org/jira/browse/UIMA-1447 Project: UIMA Issue Type: Bug Components: Sandbox-WhitespaceTokenizer Affects Versions: 2.3S Environment: Unix (ubuntu 8.04), Eclipse Galileo 3.5 Reporter: Jérôme Rocheteau Assignee: Marshall Schor Attachments: patch-an-wst.txt This is a test-text for the Whitespace Tokenizer in the UIMA Sandbox. It behaves as follows:i.e. a '\t' character after a space is annotated as a token and its covered text is set to the empty string ! I suppose it shoudn't be the case, am I wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: clarifying a generics issue
On Tue, Aug 11, 2009 at 10:44 AM, Jörn Kottmannkottm...@gmail.com wrote:
Adam Lally wrote:
Lets say we have an interface Box{Number getNumber()}
then we could have a class BoxImpl implements Box{Integer getNumber(){...}}.
Now I only would have to cast once
Box box = ...;
BoxImpl boxImpl = (BoxImpl) box;
now
Integer number = boxImpl.getNumber()
would work. Sure if you do the same for CAS and CASImpl
you safe lots of casts.
The same does not work for a getNumbers which
returns a ListNumber or IteratorNumber
without also allowing down casting.
Well, true, but it does not really create an analogous solution if you do:
interface Box{ListT extends Number getNumberList()}
class BoxImpl{ListInteger numberList()}
Because a client could call
ListInteger x = box.getNumberList()
whether or not box was actually a BoxImpl.
-Adam
Re: clarifying a generics issue
Adam Lally wrote:
On Mon, Aug 10, 2009 at 9:00 PM, Marshall Schorm...@schor.com wrote:
Here's a new thread to discuss just one particular issue - a generics
tradeoff.
In other posts, people have expressed misgivings about letting users
downcast ListsomeType to ListsomeSubType, if it cannot be
*guaranteed* at compile time that this is valid.
Here's a simple example, for instance, using two built-in Java classes:
Number
Integer (a subtype of Number)
If we have a method which returns a ListNumber, and you happen to know
it only contains Integers, and you want to use a for-each on it with a
method that only exists in the Integer class, you have to do manual
casting within the loop.
An alternative might have been to do:
ListNumber numbers = ...;
ListInteger int_version = numbers; // not allowed, gives compile error
So once we're given the numbers object, as far as I can see, we're
stuck with its typing. (Please tell me if I'm wrong here).
I see that there is a trade-off between specifying return types as
specific types, and specifying them as T extends X, and letting the user
specify a possibly incorrect downcast. The tradeoff on the plus side is
that the user gets to write the new style for-each loops, and have code
without casts inside loops, etc., and on the minus side, the user when
doing this gets that warning about the possibility that at runtime a
casting error could be thrown. But of course, that same casting error
could be thrown in restricted style, too, at the point of the explicit
user cast.
I'll probably stop trying to convince others if they continue to feel
that the tradeoffs here should be in the direction of returning only
specific types (disallowing users from specifying downcasting in that
manner), versus using types of the form T extends X,
which allows users to specify downcasting.
I'd be interested in any literature pointers discussing this trade-off
issue, if anyone has good ones :-)
One other way to look at this - why are Collections any different than
methods that return single elements? If I have a method
Number getNumber()
and I know in some situation that the Number is really an Integer,
should I be able to call:
Integer x = getNumber()?
Normally such a thing is not allowed without an explicit cast. And
for me at least I just take that for granted as part of what a
strongly-typed language does, so it's very bizarre to think of it not
doing that.
Lets say we have an interface Box{Number getNumber()}
then we could have a class BoxImpl implements Box{Integer getNumber(){...}}.
Now I only would have to cast once
Box box = ...;
BoxImpl boxImpl = (BoxImpl) box;
now
Integer number = boxImpl.getNumber()
would work. Sure if you do the same for CAS and CASImpl
you safe lots of casts.
The same does not work for a getNumbers which
returns a ListNumber or IteratorNumber
without also allowing down casting.
Jörn
[jira] Reopened: (UIMA-1477) UIMA AS client hangs while handling CPC request
[ https://issues.apache.org/jira/browse/UIMA-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1477: - The hang is still happening in the UIMA AS client when calling collectionProcessComplete() UIMA AS client hangs while handling CPC request Key: UIMA-1477 URL: https://issues.apache.org/jira/browse/UIMA-1477 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik When UIMA AS client is initialized it acquires a CPC semaphore to control when to send a CPC request. The semaphore is released when a number of CASes sent equals a number of CASes received. Only when equal the semaphore is released and the CPC request is allowed to be sent. In a case when a client is initialized but never sends any CASes this logic fails. The semaphore is never released causing a hang while trying to acquire a semaphore in collectionProcessComplete(). Add a new test case to replicate the problem. Fix the code to handle sending CPC from a client that doesnt send CASes to a service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] generics: have methods returning objects infer the type from the receiving variable type (was: clarifying a generics issue)
I can see Adam's point.
If there was some way to do an explicit cast that worked for
collections, then I would be happy with that.
In other words, if we had something of type ListNumber and I knew the
list really contained only Integers, if there was a way to cast this:
ListIntegers i_know_what_i_m_doing = (
(Magic_doesn't_really_exist_cast) something_returning_a_ListNumber))
then I would be happy.
It just seems to me to be too much to give up in the trade off - to lose
the ability to have a ListIntegers when I know that's what I have.
That's the point I'm trying to make.
One way around this, for instance of CASImpl and CAS etc., is to have
alternative forms of the affected methods, such as
IteratorCAS getViewIterator() // the public, normal one, and
IteratorCASImpl getInternalViewIterator() // one that might be
public but not part of the public API
The bad/sad part of this is this violates the write-it-once philosophy
:-( ...
Of course, now that we have Java5 as a base, and given that
getViewIterator actually constructs a real list object, and returns an
iterator over it, it would make more sense in this case to have an
internal method that returned the List, which implements Iterable,
which would make it work in for-each loops :-)
So - can we close up this discussion with a vote on the following:
On the normal scale of -1, 0, +1, to the proposition -
have the generic form of many methods that are in the public API for
UIMA that return UIMA objects, return a type which is inferred from the
receiving typed variable, versus having it return just one fixed type
not inferred from the receiving typed variable,
Marshall: + .5 (somewhat in favor, but can live with not doing
inference, perhaps implementing internal versions)
Adam Lally wrote:
On Tue, Aug 11, 2009 at 10:44 AM, Jörn Kottmannkottm...@gmail.com wrote:
Adam Lally wrote:
Lets say we have an interface Box{Number getNumber()}
then we could have a class BoxImpl implements Box{Integer getNumber(){...}}.
Now I only would have to cast once
Box box = ...;
BoxImpl boxImpl = (BoxImpl) box;
now
Integer number = boxImpl.getNumber()
would work. Sure if you do the same for CAS and CASImpl
you safe lots of casts.
The same does not work for a getNumbers which
returns a ListNumber or IteratorNumber
without also allowing down casting.
Well, true, but it does not really create an analogous solution if you do:
interface Box{ListT extends Number getNumberList()}
class BoxImpl{ListInteger numberList()}
Because a client could call
ListInteger x = box.getNumberList()
whether or not box was actually a BoxImpl.
-Adam
Re: release 2.3.0 plan
+1 for an update to uimacpp On Fri, Aug 7, 2009 at 4:49 PM, Marshall Schorm...@schor.com wrote: I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
Re: [VOTE] generics: have methods returning objects infer the type from the receiving variable type (was: clarifying a generics issue)
On Tue, Aug 11, 2009 at 3:16 PM, Marshall Schorm...@schor.com wrote: snip/ So - can we close up this discussion with a vote on the following: On the normal scale of -1, 0, +1, to the proposition - have the generic form of many methods that are in the public API for UIMA that return UIMA objects, return a type which is inferred from the receiving typed variable, versus having it return just one fixed type not inferred from the receiving typed variable, -1 Adam
[jira] Closed: (UIMA-1479) Move UIMA-AS out of sandbox, change to an add-on packaging style to the core
[ https://issues.apache.org/jira/browse/UIMA-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1479. Resolution: Fixed Fix Version/s: (was: 2.3) 2.3AS switch your checked out version to https://svn.apache.org/repos/asf/incubator/uima/uima-as/trunk Move UIMA-AS out of sandbox, change to an add-on packaging style to the core -- Key: UIMA-1479 URL: https://issues.apache.org/jira/browse/UIMA-1479 Project: UIMA Issue Type: Task Components: Async Scaleout Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 2.3AS UIMA-AS was voted to graduate from the sandbox. Make the needed changes to effect this, including: 1) moving it to uimaj node in SVN (eclipse plugins I think are already there) 2) changing the build so that its assembler builds an add-on-to-uima-base bin/src distribution. (It used to include most of base UIMA -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] generics: have methods returning objects infer the type from the receiving variable type
Marshall Schor wrote: I can see Adam's point. If there was some way to do an explicit cast that worked for collections, then I would be happy with that. In other words, if we had something of type ListNumber and I knew the list really contained only Integers, if there was a way to cast this: ListIntegers i_know_what_i_m_doing = ( (Magic_doesn't_really_exist_cast) something_returning_a_ListNumber)) then I would be happy. It just seems to me to be too much to give up in the trade off - to lose the ability to have a ListIntegers when I know that's what I have. That's the point I'm trying to make. One way around this, for instance of CASImpl and CAS etc., is to have alternative forms of the affected methods, such as IteratorCAS getViewIterator() // the public, normal one, and IteratorCASImpl getInternalViewIterator() // one that might be public but not part of the public API The bad/sad part of this is this violates the write-it-once philosophy :-( ... Of course, now that we have Java5 as a base, and given that getViewIterator actually constructs a real list object, and returns an iterator over it, it would make more sense in this case to have an internal method that returned the List, which implements Iterable, which would make it work in for-each loops :-) So - can we close up this discussion with a vote on the following: On the normal scale of -1, 0, +1, to the proposition - have the generic form of many methods that are in the public API for UIMA that return UIMA objects, return a type which is inferred from the receiving typed variable, versus having it return just one fixed type not inferred from the receiving typed variable, Marshall: + .5 (somewhat in favor, but can live with not doing inference, perhaps implementing internal versions) -1 --Thilo
[jira] Closed: (UIMA-1367) UIMA-AS docs JavaDocs don't fully describe the UimaASStatusCallbackListener interface
[ https://issues.apache.org/jira/browse/UIMA-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1367. --- Resolution: Fixed Addressed under UIMA-1484 UIMA-AS docs JavaDocs don't fully describe the UimaASStatusCallbackListener interface --- Key: UIMA-1367 URL: https://issues.apache.org/jira/browse/UIMA-1367 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Burn Lewis Priority: Minor Fix For: 2.3S They claim the callbacks provide an org.apache.uima.collection.EntityProcessStatus but it's actually an extension (org.apache.uima.aae.client.UimaASProcessStatus) with 2 extra methods. Also need a correction as says that On success aStatus will be null Also need to state when (or if) entityProcessComplete provides a null CAS, and that the input CAS is provided when an exception has occurred. Note: When running the tests I do see replies with a null CAS, with without IDs in the status, but some are to be expected until 1358 is fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ACTION NEEDED: uima-as moved in SVN - switch to new location if you have projects in uima-as checked out
The affected projects are: uima-as-distr uima-as-docbooks uimaj-as uimaj-as-activemq uimaj-as-camel uimaj-as-core uimaj-as-jms uimaj-as-osgi-runtime uimaj-eclipse-feature-deployeditor uimaj-ep-deployeditor uimaj-ep-runtime-deployeditor -Marshall
[jira] Reopened: (UIMA-1437) Fix UIMA AS testcase code to address intermittent hangs
[ https://issues.apache.org/jira/browse/UIMA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1437: - Remove msgs that show on the console a list of active threads when the service is stopping Fix UIMA AS testcase code to address intermittent hangs --- Key: UIMA-1437 URL: https://issues.apache.org/jira/browse/UIMA-1437 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik A recent fix that introduced a SharedConnection object exposed a threading problem in the testcase code. Testcases in the extended suite were not being completely cleaned up between runs. Some of the threads from a previous testcase were still running in a new testcase. Modify the testcase code to make sure that all threads are finished before starting another testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1437) Fix UIMA AS testcase code to address intermittent hangs
[ https://issues.apache.org/jira/browse/UIMA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1437. --- Resolution: Fixed Removed dumping active threads to stdout Fix UIMA AS testcase code to address intermittent hangs --- Key: UIMA-1437 URL: https://issues.apache.org/jira/browse/UIMA-1437 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik A recent fix that introduced a SharedConnection object exposed a threading problem in the testcase code. Testcases in the extended suite were not being completely cleaned up between runs. Some of the threads from a previous testcase were still running in a new testcase. Modify the testcase code to make sure that all threads are finished before starting another testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1447) Tabulations are annotated as tokens after a space
[ https://issues.apache.org/jira/browse/UIMA-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1447. Resolution: Fixed Fix Version/s: 2.3S Tabulations are annotated as tokens after a space - Key: UIMA-1447 URL: https://issues.apache.org/jira/browse/UIMA-1447 Project: UIMA Issue Type: Bug Components: Sandbox-WhitespaceTokenizer Affects Versions: 2.3S Environment: Unix (ubuntu 8.04), Eclipse Galileo 3.5 Reporter: Jérôme Rocheteau Assignee: Marshall Schor Fix For: 2.3S Attachments: patch-an-wst.txt This is a test-text for the Whitespace Tokenizer in the UIMA Sandbox. It behaves as follows:i.e. a '\t' character after a space is annotated as a token and its covered text is set to the empty string ! I suppose it shoudn't be the case, am I wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1427) AE as Eclipse plugin + resource definitions = ResourceAccessException
[ https://issues.apache.org/jira/browse/UIMA-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1427. Resolution: Invalid Hi Kai - The problem was solved by changing your code slightly. The form: Some_Class_name.class.getResourceAsStream(name) is defined to fetch the resource *in the same package* as the class. To fix this, use the form: Some_Class_name.class.getClassLoader().getResrouceAsStream(name). Also, you probably don't need the UIMA buddy loading mechanism for this if you use as the Some_Class_name the name of your annotator class, because the class loader used for that will be used, and it should be the one for the plugin - having addressability per the plugin-in's manifest. AE as Eclipse plugin + resource definitions = ResourceAccessException - Key: UIMA-1427 URL: https://issues.apache.org/jira/browse/UIMA-1427 Project: UIMA Issue Type: Question Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Kai Schlamp Attachments: testUimaResources.zip Please see http://article.gmane.org/gmane.comp.apache.uima.general/2147 This issue provides the sample plugins to demonstrate the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1426) More control for apps against OOMs from UIMA core: Add configuration option to set the maximum heap size the CAS will grow to
[ https://issues.apache.org/jira/browse/UIMA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742177#action_12742177 ] Marshall Schor commented on UIMA-1426: -- Thilo - were you going to be working on this? Is it something that you could do in time for the 2.3.0 release? More control for apps against OOMs from UIMA core: Add configuration option to set the maximum heap size the CAS will grow to - Key: UIMA-1426 URL: https://issues.apache.org/jira/browse/UIMA-1426 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Thomas Hampp Applications need to protect themselves against out of memory exceptions (OOMs). UIMA should help with that by making sure a growth in the CAS heap size will not cause an OOM. One way to do this is to add a config param that controls the maximum heap size for a CAS and throw a runtime exception if that threshold is exceeded. Since apps often use multiple CASes in pools in multihreaded fashion they would still need to exercise some app specific math (and guesswork) to determine the right value for this param. But at least they would be able to have some control. (There could still be OOMs during UIMA processing from other sources) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1410) The uimaj-as-camel producer should report and log all error/exceptions
[ https://issues.apache.org/jira/browse/UIMA-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742183#action_12742183 ] Marshall Schor commented on UIMA-1410: -- Joern - is this something that you think will be ready for the 2.3.0 release, or is it something for the next release? The uimaj-as-camel producer should report and log all error/exceptions -- Key: UIMA-1410 URL: https://issues.apache.org/jira/browse/UIMA-1410 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.3AS Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3AS There are several TODOs in the implementation which must be replaced with proper error handling and logging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1337) overhaul CAS Processing filters
[ https://issues.apache.org/jira/browse/UIMA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1337: - Priority: Minor (was: Major) Affects Version/s: 2.3 Summary: overhaul CAS Processing filters (was: overhul CAS Processing filters) Background: see http://markmail.org/thread/otcjjsjofscs7lsk. Deferring beyond 2.3.0 release. overhaul CAS Processing filters --- Key: UIMA-1337 URL: https://issues.apache.org/jira/browse/UIMA-1337 Project: UIMA Issue Type: Improvement Components: Collection Processing Affects Versions: 2.3 Reporter: Maksim Likharev Priority: Minor Original Estimate: 1008h Remaining Estimate: 1008h In order to improve performance and produce custom routing rules, current implementation of the CAS filters should be overhauled. goals: 1. Filters on CasConsumer, avoid passing unsuitable artifacts and annotations, somewhat implemented right now , lots of issues 2. Filters on CasProcessor, avoid unnecessary processing if suitable annotations already present, like read from cache by a CollectionReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742187#action_12742187
]
Marshall Schor commented on UIMA-1352:
--
Thilo - can you close this issue now?
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-1352.
-
Resolution: Fixed
Did not fix the issue with bag index find() that was discussed as a follow-up
to this issue. Should open separate issue.
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1426) More control for apps against OOMs from UIMA core: Add configuration option to set the maximum heap size the CAS will grow to
[ https://issues.apache.org/jira/browse/UIMA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742225#action_12742225 ] Thilo Goetz commented on UIMA-1426: --- No, let's leave open (unless somebody else wants a go). More control for apps against OOMs from UIMA core: Add configuration option to set the maximum heap size the CAS will grow to - Key: UIMA-1426 URL: https://issues.apache.org/jira/browse/UIMA-1426 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Thomas Hampp Applications need to protect themselves against out of memory exceptions (OOMs). UIMA should help with that by making sure a growth in the CAS heap size will not cause an OOM. One way to do this is to add a config param that controls the maximum heap size for a CAS and throw a runtime exception if that threshold is exceeded. Since apps often use multiple CASes in pools in multihreaded fashion they would still need to exercise some app specific math (and guesswork) to determine the right value for this param. But at least they would be able to have some control. (There could still be OOMs during UIMA processing from other sources) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
