You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2019/07/22 17:18:00 UTC
[VOTE] uimaj 3.0.3 rc2
Hi,
uimaj-3.0.3 rc2 is posted and ready for voting.
One more issue fixed: enabling running on the latest Eclipse 2019-06.
Also fixed a build issue with rat exclusions (no Jira).
This release fixes 16 issues.
The issues fixed are here:
https://issues.apache.org/jira/projects/UIMA/versions/12345407
The source and binary tars/zips are here:
https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.3-rc2/artifacts/
The eclipse update subsite is here:
https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.3-rc2/eclipse-update-site/
The maven staging repo is here:
https://repository.apache.org/content/repositories/orgapacheuima-1235/
The SVN tag: https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags/uimaj-3.0.3/
Please vote on release:
[ ] +1 OK to release
[ ] 0 Don't care
[ ] -1 Not OK to release, because ...
Thanks.
-Marshall
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Burn Lewis <bu...@gmail.com>.
checked signatures: OK - but the filename is missing
from uimaj-3.0.3-source-release.zip.sha512
installed binary & ran document analyzer: OK
checked docs: OK
build from sources: OK
checked signatures & docs: OK
extracted the build & ran document analyzer: OK
ran a simple annotator via DUCC: OK
x] +1 OK to release
On Mon, Jul 22, 2019 at 3:55 PM Marshall Schor <sc...@apache.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> signatures OK
> compare source-release with svn tag : OK
> installed plugins into Eclipse 2019-06 OK
> imported example project into Eclipse, it built OK, ran document analyzer:
> OK
> made new type system descriptor, ran JCasGen: OK
> used the Component Descriptor Editor to delete some features - works OK
> build from sources: OK
> issues-fixed jira report: OK
> api-change reports: OK
> ran document analyzer from bin package, viewed results- OK
> compare licenses with 3.0.2 - no change
> spot check license on staging repo: OK
>
> [x] +1 OK to release
>
> Marshall Schor
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEOn/mVSh3S1eNEDz+zHYv/c0Ez9YFAl02FJUACgkQzHYv/c0E
> z9Zt3g/+OWCvnxA5ZWuBhyEtidnhS1n/FmOqKLfl/WTn53+cuafxyOh9y8wZCVYS
> 1BbLkTNvlrq6fboYPW26fb545qduVtcHd2jSzbSly3RKtyXXA6hhv+a/vawFsxuF
> mFnDt/F2cyoG2XD2tSBh9TNqlZ2VmHHSDOy9ONlpK5c1i7qg0ntRvlu2xoxJ1Msz
> hmTQuW21meEknq4rdD+uMuNU9ZTnOpmIFgbxbfuG41lLnXO7f3m9xqV03eeonLbE
> bB2Dp8JEs8IBDGcQErG2+xOO1dBNJD0roWw8xULHwzPCB2cWyQ9vLdSop4NKX/3n
> nG9U6rYu0MI4MBNuDbJMOmZ9+CXWLYNEgfojd9XqYAdkuik1sEDPywGm2dco/y9H
> Pu2R/TKiw2gMK6PLXVlrlCRaaK/iU+T+Xzg2JRP6gmTKf5xUv8iqQJ/fb6PAoMgq
> mBNij1cIehFnBJmcolwegcRcgWDQViTK7NL1886XCqRxdR93k1AcY8DFGPH4YoFz
> 7PNkVktrb0bb4iy2fmVEKbF47A1yAyniYXRK3TK8TCTFNnt1dcKEPhyQwyGX1Sxr
> zb2yRLWum3cqinhMWqgCWW/kq+xlFvR2IRHJvgjD8OYkyAn+dGqH0dE3cEjjl7l5
> ms4rG91EnTTZEMNIEZwua5gK6ZBuHyTf6OcbGHtHqHAEDGEfmaQ=
> =48ve
> -----END PGP SIGNATURE-----
>
>
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Marshall Schor <sc...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
signatures OK
compare source-release with svn tag : OK
installed plugins into Eclipse 2019-06 OK
imported example project into Eclipse, it built OK, ran document analyzer: OK
made new type system descriptor, ran JCasGen: OK
used the Component Descriptor Editor to delete some features - works OK
build from sources: OK
issues-fixed jira report: OK
api-change reports: OK
ran document analyzer from bin package, viewed results- OK
compare licenses with 3.0.2 - no change
spot check license on staging repo: OK
[x] +1 OK to release
Marshall Schor
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEOn/mVSh3S1eNEDz+zHYv/c0Ez9YFAl02FJUACgkQzHYv/c0E
z9Zt3g/+OWCvnxA5ZWuBhyEtidnhS1n/FmOqKLfl/WTn53+cuafxyOh9y8wZCVYS
1BbLkTNvlrq6fboYPW26fb545qduVtcHd2jSzbSly3RKtyXXA6hhv+a/vawFsxuF
mFnDt/F2cyoG2XD2tSBh9TNqlZ2VmHHSDOy9ONlpK5c1i7qg0ntRvlu2xoxJ1Msz
hmTQuW21meEknq4rdD+uMuNU9ZTnOpmIFgbxbfuG41lLnXO7f3m9xqV03eeonLbE
bB2Dp8JEs8IBDGcQErG2+xOO1dBNJD0roWw8xULHwzPCB2cWyQ9vLdSop4NKX/3n
nG9U6rYu0MI4MBNuDbJMOmZ9+CXWLYNEgfojd9XqYAdkuik1sEDPywGm2dco/y9H
Pu2R/TKiw2gMK6PLXVlrlCRaaK/iU+T+Xzg2JRP6gmTKf5xUv8iqQJ/fb6PAoMgq
mBNij1cIehFnBJmcolwegcRcgWDQViTK7NL1886XCqRxdR93k1AcY8DFGPH4YoFz
7PNkVktrb0bb4iy2fmVEKbF47A1yAyniYXRK3TK8TCTFNnt1dcKEPhyQwyGX1Sxr
zb2yRLWum3cqinhMWqgCWW/kq+xlFvR2IRHJvgjD8OYkyAn+dGqH0dE3cEjjl7l5
ms4rG91EnTTZEMNIEZwua5gK6ZBuHyTf6OcbGHtHqHAEDGEfmaQ=
=48ve
-----END PGP SIGNATURE-----
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Marshall Schor <ms...@schor.com>.
I'm leaning that way too, unless I hear that many existing users say they're
code broke (like DkPro did), and they want a less painful upgrade...
-Marshall
On 8/2/2019 4:23 PM, Richard Eckart de Castilho wrote:
> I'm voting for keeping the generic but without a wildcard ... and increasing the middle version number :)
>
> -- Richard
>
>
>
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Richard Eckart de Castilho <re...@apache.org>.
I'm voting for keeping the generic but without a wildcard ... and increasing the middle version number :)
-- Richard
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Marshall Schor <ms...@schor.com>.
hi, I tried most of this. I see two lines with the same code, but one is marked
ok, the other throws ClassCastException?
n = tokens.get(0); // ok
n = tokens.get(0); // throws ClassCastException
When I ran this (in Java 8), it ran OK.
Any idea why your try behaved differently?
I did see that
n = generalize.get(0); // gives a compile error
which can be overcome with a cast, but that seems like a bad burden to put on users,
compared to not having the wildcard in the returned result.
-Marshall
On 8/2/2019 3:00 PM, Hai-son X Nguyen wrote:
> Thanks for the reference Marshall,
>
> Try this code:
> public static void main(String[] args) {
>
> List<Number> tokens = new ArrayList<>();
> tokens.add(3);
> tokens.set(0, 4);
>
> ArrayList<? super Number> generalize = (ArrayList<? super Number>) tokens; // Upcasts all to number
> Number n = 5;
> generalize.set(0, n); // ok
> var x = generalize.get(0); // ok
> // n = generalize.get(0); // compile error
> System.out.println(tokens.get(0)); // ok prints 5
> x = tokens.get(0); // ok
> n = tokens.get(0); // ok
>
> List unknown = tokens; // warning
> unknown.set(0, "foo"); // warning
>
> // String t = tokens.get(0); // compile error
> // String t = (String) tokens.get(0); // compile error
> System.out.println(tokens.get(0)); // ok prints "foo"
> n = tokens.get(0); // throws ClassCastException
>
> }
>
>> In fact, there's no cast I could figure out to make "generalize.set" work at
>> all, except by changing its definition to use ArrayList (bare with no generic
>> argument):
>>
>> ArrayList generalize = (ArrayList<? extends Number>) tokens; //compiles with
>> warnings,
>> generalize.set(0, 7); // works at runtime
> I thought we can do a upcast and use <? super FeatureStructure> which gets around the set problem you found but it looks like there are problems on the get side...
> The use of var is possible to get around the immediate errors but that is Java 10+
>
> Moved the example to get the runtime error at the end
>
> The run time exception comes in the get() call and setting it to the generic type. (
>
> Hai-Son
>
> 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.
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Hai-son X Nguyen <Ha...@kp.org>.
Thanks for the reference Marshall,
Try this code:
public static void main(String[] args) {
List<Number> tokens = new ArrayList<>();
tokens.add(3);
tokens.set(0, 4);
ArrayList<? super Number> generalize = (ArrayList<? super Number>) tokens; // Upcasts all to number
Number n = 5;
generalize.set(0, n); // ok
var x = generalize.get(0); // ok
// n = generalize.get(0); // compile error
System.out.println(tokens.get(0)); // ok prints 5
x = tokens.get(0); // ok
n = tokens.get(0); // ok
List unknown = tokens; // warning
unknown.set(0, "foo"); // warning
// String t = tokens.get(0); // compile error
// String t = (String) tokens.get(0); // compile error
System.out.println(tokens.get(0)); // ok prints "foo"
n = tokens.get(0); // throws ClassCastException
}
> In fact, there's no cast I could figure out to make "generalize.set" work at
> all, except by changing its definition to use ArrayList (bare with no generic
> argument):
>
> ArrayList generalize = (ArrayList<? extends Number>) tokens; //compiles with
> warnings,
> generalize.set(0, 7); // works at runtime
I thought we can do a upcast and use <? super FeatureStructure> which gets around the set problem you found but it looks like there are problems on the get side...
The use of var is possible to get around the immediate errors but that is Java 10+
Moved the example to get the runtime error at the end
The run time exception comes in the get() call and setting it to the generic type. (
Hai-Son
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.
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Marshall Schor <ms...@schor.com>.
Hi,
I did a small test setup - made a main routine in a test class, and ran it.
It too shows all the issues. Here's the routine - it only uses Java basic
things, no UIMA.
public static void main(String[] args) {
ArrayList<Number> tokens = new ArrayList<>(1);
tokens.add(3); // add one element to the list
tokens.set(0, 4); //ok - no compile or runtime error
ArrayList unknown = tokens; // compile time warning
unknown.set(0, 5); // compile time warning, runtime ok
ArrayList<? extends Number> generalize = (ArrayList<? extends Number>) tokens;
// generalize.set(0, 6); // compile time error
}
In fact, there's no cast I could figure out to make "generalize.set" work at
all, except by changing its definition to use ArrayList (bare with no generic
argument):
ArrayList generalize = (ArrayList<? extends Number>) tokens; //compiles with
warnings,
generalize.set(0, 7); // works at runtime
The book "Effective Java" by Josha Bloch says "Do not use bounded wildcard types
as return types". This is because it "forces users to use wildcard types in
client code", and
There is some discussion here:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ303
I'm pretty sure it would cause a lot of issues if this method were to "return" a
bounded wild card.
-Marshall
On 8/1/2019 5:24 PM, Hai-son X Nguyen wrote:
> 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" <re...@apache.org> 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 <Ha...@kp.org> 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.
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 1. Aug 2019, at 23:24, Hai-son X Nguyen <Ha...@kp.org> wrote:
>
> We could adjust the update to return FSArray<? extends FeatureStructure> instead to meet the source compatibility too.
The type system descriptor knows which kind of feature structure is returned, so we should use that information. It saves client code from explicitly down-casting to those subtypes of FeatureStructure.
Is there a problem with doing a minor feature release instead of a bugfix release?
-- Richard
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Hai-son X Nguyen <Ha...@kp.org>.
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" <re...@apache.org> 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 <Ha...@kp.org> 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.
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 1. Aug 2019, at 21:41, Hai-son X Nguyen <Ha...@kp.org> 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
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Hai-son X Nguyen <Ha...@kp.org>.
This is a good catch; I think properly the loop needs a better castt:
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>
Thanks!
Hai-Son
On 8/1/19, 3:09 AM, "Richard Eckart de Castilho" <re...@apache.org> wrote:
Caution: This email came from outside Kaiser Permanente. Do not open attachments or click on links if you do not recognize the sender.
______________________________________________________________________
dist artifact signature check: ok
README spot check: ok
RELEASE_NOTES spot check: ok
API report spot check: ok
Built from sources: ok
Building DKPro Core against the RC, I get a compiler error:
With v3.0.2, JCasGen generated this code:
```
public FSArray getAttributes() { return (FSArray)(_getFeatureValueNc(wrapGetIntCatchException(_FH_attributes)));}
```
and DKPro Core could/had to then cast the unspecific FSArray to Iterable<FeatureStructure>:
```
for (FeatureStructure attrFS : (Iterable<FeatureStructure>) aElement.getAttributes()) {
...
}
```
But with v3.0.3, JCasGen was changed to return specific types where possible instead of an unspecified generic:
```
public FSArray<XmlAttribute> getAttributes() {
return (FSArray<XmlAttribute>)(_getFeatureValueNc(wrapGetIntCatchException(_FH_attributes)));
}
```
This now causes the previously working type cast in DKPro Core to become a compiler error:
```
[ERROR] /Users/bluefire/git/dkpro-core/dkpro-core-api-xml-asl/src/main/java/org/dkpro/core/api/xml/https://urldefense.proofpoint.com/v2/url?u=http-3A__Cas2SaxEvents.java&d=DwIFAg&c=V-WiB07a9ZG9AUogGPqIYBXfVnjryhYX1W_SjITv1Oo&r=A33kge5NheqiOmZbXpb29M79KHMRFZoJygn2vT_Z8Ns&m=v39d2r5gsIsm2C22ZcwQ1ACmaU14gdexcFo1Heh4Txc&s=Zj9BDgFRlvWKW8q8CUqK_s2j4vOrcRL2b2ytf297qgk&e= :[67,95] incompatible types: org.apache.uima.jcas.cas.FSArray<org.dkpro.core.api.xml.type.XmlAttribute> cannot be converted to java.lang.Iterable<org.apache.uima.cas.FeatureStructure>
```
I'd tend to say that the change to JCasGen is not a source-compatible change and would warrant changing the version number to 3.1.0.
WDYT?
Cheers,
-- 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.
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 1. Aug 2019, at 20:44, Marshall Schor <ms...@schor.com> wrote:
>
> I'm wondering if other codes will also break, and if the benefit of this change
> is worth the trouble it will cause in being backwards compatible.
>
> Opinions?
I think the change is a good one and should be kept.
Getters and setters using generic containers should return/require the proper element type as defined in the type system. This removes the need for explicit type casting and allows for cleaner and more maintainable client code.
It should be advertised as a feature and the version number should reflect that by increasing the "feature" digit.
I am not sure if the change is actually binary-incompatible. Java's type-erasure for generics might make this only a source-incompatible change.
It might be a good idea at some point to create a Maven module in UIMAJ-Core which contains some generated JCas classes and applies the API report plugin to them so we can get some feedback when there are incompatible changes in the generated JCas wrappers.
-- Richard
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Marshall Schor <ms...@schor.com>.
I'm wondering if other codes will also break, and if the benefit of this change
is worth the trouble it will cause in being backwards compatible.
Opinions?
Mine tends to lean toward not doing this kind of thing, until we have a good
reason to cause the user community to do maintenance on their implementations to
make use of the new version.
-Marshall
On 8/1/2019 1:36 PM, Richard Eckart de Castilho wrote:
> On 1. Aug 2019, at 16:24, Marshall Schor <ms...@schor.com> wrote:
>> Is this easy to "fix" in DkPro ?
> Yep, easy to fix. Basically just remove the explicit type-cast.
> But still it's something I wouldn't expect in a bugfix release.
>
> -- Richard
>
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 1. Aug 2019, at 16:24, Marshall Schor <ms...@schor.com> wrote:
>
> Is this easy to "fix" in DkPro ?
Yep, easy to fix. Basically just remove the explicit type-cast.
But still it's something I wouldn't expect in a bugfix release.
-- Richard
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Marshall Schor <ms...@schor.com>.
ouch...
I tend to agree with you...
Is this easy to "fix" in DkPro ?
-Marshall
On 8/1/2019 6:09 AM, Richard Eckart de Castilho wrote:
> dist artifact signature check: ok
> README spot check: ok
> RELEASE_NOTES spot check: ok
> API report spot check: ok
> Built from sources: ok
>
> Building DKPro Core against the RC, I get a compiler error:
>
> With v3.0.2, JCasGen generated this code:
>
> ```
> public FSArray getAttributes() { return (FSArray)(_getFeatureValueNc(wrapGetIntCatchException(_FH_attributes)));}
> ```
>
> and DKPro Core could/had to then cast the unspecific FSArray to Iterable<FeatureStructure>:
>
> ```
> for (FeatureStructure attrFS : (Iterable<FeatureStructure>) aElement.getAttributes()) {
> ...
> }
> ```
>
> But with v3.0.3, JCasGen was changed to return specific types where possible instead of an unspecified generic:
>
> ```
> public FSArray<XmlAttribute> getAttributes() {
> return (FSArray<XmlAttribute>)(_getFeatureValueNc(wrapGetIntCatchException(_FH_attributes)));
> }
> ```
>
> This now causes the previously working type cast in DKPro Core to become a compiler error:
>
> ```
> [ERROR] /Users/bluefire/git/dkpro-core/dkpro-core-api-xml-asl/src/main/java/org/dkpro/core/api/xml/Cas2SaxEvents.java:[67,95] incompatible types: org.apache.uima.jcas.cas.FSArray<org.dkpro.core.api.xml.type.XmlAttribute> cannot be converted to java.lang.Iterable<org.apache.uima.cas.FeatureStructure>
> ```
>
> I'd tend to say that the change to JCasGen is not a source-compatible change and would warrant changing the version number to 3.1.0.
>
> WDYT?
>
> Cheers,
>
> -- Richard
>
>
Re: [VOTE] uimaj 3.0.3 rc2
Posted by Richard Eckart de Castilho <re...@apache.org>.
dist artifact signature check: ok
README spot check: ok
RELEASE_NOTES spot check: ok
API report spot check: ok
Built from sources: ok
Building DKPro Core against the RC, I get a compiler error:
With v3.0.2, JCasGen generated this code:
```
public FSArray getAttributes() { return (FSArray)(_getFeatureValueNc(wrapGetIntCatchException(_FH_attributes)));}
```
and DKPro Core could/had to then cast the unspecific FSArray to Iterable<FeatureStructure>:
```
for (FeatureStructure attrFS : (Iterable<FeatureStructure>) aElement.getAttributes()) {
...
}
```
But with v3.0.3, JCasGen was changed to return specific types where possible instead of an unspecified generic:
```
public FSArray<XmlAttribute> getAttributes() {
return (FSArray<XmlAttribute>)(_getFeatureValueNc(wrapGetIntCatchException(_FH_attributes)));
}
```
This now causes the previously working type cast in DKPro Core to become a compiler error:
```
[ERROR] /Users/bluefire/git/dkpro-core/dkpro-core-api-xml-asl/src/main/java/org/dkpro/core/api/xml/Cas2SaxEvents.java:[67,95] incompatible types: org.apache.uima.jcas.cas.FSArray<org.dkpro.core.api.xml.type.XmlAttribute> cannot be converted to java.lang.Iterable<org.apache.uima.cas.FeatureStructure>
```
I'd tend to say that the change to JCasGen is not a source-compatible change and would warrant changing the version number to 3.1.0.
WDYT?
Cheers,
-- Richard
Re: [VOTE] [CANCELLED] uimaj 3.0.3 rc2
Posted by Marshall Schor <ms...@schor.com>.
Cancelling the vote, to increase the middle version number (only), so the
re-vote should be quicker :-).
-Marshall