Sorry, let me rephrase, the 3.0.0 - 3.0.2 version exposed potential bugs. As our code is littered with FSArrays I wanted to fix the warnings to prevent future calamities like below:
Sentence sentence = ...; FSArray<Token> tokens = sentence.getTokens(); tokens.set(1, sentence); // <- compile error Case #1 FSArray unknown = tokens; // <- warning unknown.set(1, sentence); // <- nothing warnings, compiles - runtime error Case #2 FSArray<? extends FeatureStructure> generalize = (FSArray<? extends FeatureStructure>) tokens; generalize.set(1, sentence); // <- compile error Case #3 It is different for the Iterator which is not a modifiable interface, so one always thinks it should be allowed! Took me a while to research and remember why Java complains about that casting equivalent to Case #2. From the apache versioning guidelines, it looks like binary compatibility is there but patch version requires both perfect binary and source compatibility We could adjust the update to return FSArray<? extends FeatureStructure> instead to meet the source compatibility too. Hai-Son On 8/1/19, 12:46 PM, "Richard Eckart de Castilho" <[email protected]> wrote: Caution: This email came from outside Kaiser Permanente. Do not open attachments or click on links if you do not recognize the sender. ______________________________________________________________________ On 1. Aug 2019, at 21:41, Hai-son X Nguyen <[email protected]> wrote: > > for (FeatureStructure attrFS : (Iterable<? extends FeatureStructure>) aElement.getAttributes()) { > ... > } > > I don't think it is a runtime error but a bug on the DKPro side, the FSArray contract is FSArray<T extends FeatureStructure> implements Iterable<T> I also don't think it'd be a runtime error, but it is also not a bug in DKPro Core. UIMA 3.0.2 (before your change) generated a getter which returned only an FSArray *without* a generic type specification. For that case, the compiler did not create an error for the type cast that I used. But with UIMA 3.0.3, the getter is now generated *with* a generic type specification which makes the type cast invalid. Your proposed change to the type-cast might fix this, but the issue is that with 3.0.2 there was no problem and with 3.0.3 there is. Anyway, I'm happy to be able to entirely remove the type-cast with UIMA 3.0.3 - thank you very much for the contribution! IMHO it's just a matter of choosing the right version number and properly documenting this quirk. -- Richard NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
