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
I'm voting for keeping the generic but without a wildcard ... and increasing
the middle version number :)
-- Richard
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
Thanks for the reference Marshall,
Try this code:
public static void main(String[] args) {
List tokens = new ArrayList<>();
tokens.add(3);
tokens.set(0, 4);
ArrayList generalize = (ArrayList) tokens;
// Upcasts all to number
Number n = 5;
generalize.set(0, n); //
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 tokens = new ArrayList<>(1);
tokens.add(3); // add one
On 1. Aug 2019, at 23:24, Hai-son X Nguyen wrote:
>
> We could adjust the update to return FSArray
> 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
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 tokens = sentence.getTokens();
tokens.set(1, sentence); // <- compile error
On 1. Aug 2019, at 21:41, Hai-son X Nguyen wrote:
>
> for (FeatureStructure attrFS : (Iterable)
> aElement.getAttributes()) {
> ...
> }
>
> I don't think it is a runtime error but a bug on the DKPro side, the FSArray
> contract is FSArray implements Iterable
I also don't think it'd be a
This is a good catch; I think properly the loop needs a better castt:
for (FeatureStructure attrFS : (Iterable)
aElement.getAttributes()) {
...
}
I don't think it is a runtime error but a bug on the DKPro side, the FSArray
contract is FSArray implements Iterable
Thanks!
Hai-Son
On 8/1/19,
On 1. Aug 2019, at 20:44, Marshall Schor 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
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
On 1. Aug 2019, at 16:24, Marshall Schor 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
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
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
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
-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
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:
17 matches
Mail list logo
