You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Jörn Kottmann <ko...@gmail.com> on 2009/05/05 14:12:58 UTC
Generics for UIMA interfaces
Hallo,
I would love to start an initiative to add generics to the
interfaces in the uima core APIs. Since UIMA now depends
on java 5 all code which is written against our APIs is full
with warnings.
I will create a jira issue and attach a patch which should
be reviewed by someone else to make sure nothing is broken.
Jörn
Re: Generics for UIMA interfaces
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
>
>> It should be strings, actually. So the javadoc is wrong.
>> The constraint API is string based, so that a textual
>> representation (which used to exist but we lost sometime)
>> can be directly mapped to the API. I guess there is no
>> test case, else we would have noticed that sooner.
>>
> Ok, I changed it and updated the javadoc. The generics are
> only a hint for the compiler, if we declare incorrect generics
> in our interfaces it can cause a compiler error, but the test code we
> have right now does not use generics so the compiler cannot check for
> correctness. To find problems with the new declared generics
> we have to add generics to our test code and the rest of the uima
> core code. I can work on that after we are done with the interfaces.
Sounds good.
>
> There are a few more places which should be discussed:
>
> 1. The AnalysisEngine interface takes in the initialize method a
> Map for additional parameters, this kind of Map is also used
> in various other places of UIMA.
>
> Can the additional parameter Map be specified as Map<String, Object> ?
>
> This change will cause a compile error for all users who pass a
> Properties object,
> because since java 1.5 that is a Map<Object, Object>. Is it ok to break
> the code for
> these users ? For example, the infamous GrowingTheCasTest uses a
> Property object to call
> the CasCreationUtils.
I'm not worried about our internal code, we can easily fix that.
However, that API I think is also used by user code, and I'm a
bit reluctant to break user code, even if it's just a fringe case.
>
> 2. We have interfaces which are as fair as I know only implemented by
> UIMA itself,
> is it ok to break these implementations ?
IMO, absolutely.
>
> Here are the cases in question:
>
> FSIterator extends the Iterator If FeatureStructure is specified
> as type parameter the signature of the next() method changes and breaks
> all implementations.
+1, let's do it.
>
> Feature extends Comparable. If Feature is specified as type parameter
> the signature of
> compareTo must compareTo(Feature) instead of compareTo(Object)
+1
I don't know about the others offhand.
--Thilo
>
>
> TypeOrFeature also extends Comparable, can it be changed ?
>
> 3.
> ResourceFactory.produceResource, is the parameter Class aResourceClass a
> Class which
> must be subtype of Resource ? If thats true it could be changed to
> Class<? extends Resource>.
>
> 4. ResourceManager.getResourceClass and getResource(String, ...). Does
> getResourceClass always
> return a Class which is subclass of Resource ? If thats true getResource
> could be changed to return
> a Resource object instead of Object.
>
> Jörn
Re: Generics for UIMA interfaces
Posted by Jörn Kottmann <ko...@gmail.com>.
> It should be strings, actually. So the javadoc is wrong.
> The constraint API is string based, so that a textual
> representation (which used to exist but we lost sometime)
> can be directly mapped to the API. I guess there is no
> test case, else we would have noticed that sooner.
>
Ok, I changed it and updated the javadoc. The generics are
only a hint for the compiler, if we declare incorrect generics
in our interfaces it can cause a compiler error, but the test code we
have right now does not use generics so the compiler cannot check for
correctness. To find problems with the new declared generics
we have to add generics to our test code and the rest of the uima
core code. I can work on that after we are done with the interfaces.
There are a few more places which should be discussed:
1. The AnalysisEngine interface takes in the initialize method a
Map for additional parameters, this kind of Map is also used
in various other places of UIMA.
Can the additional parameter Map be specified as Map<String, Object> ?
This change will cause a compile error for all users who pass a
Properties object,
because since java 1.5 that is a Map<Object, Object>. Is it ok to break
the code for
these users ? For example, the infamous GrowingTheCasTest uses a
Property object to call
the CasCreationUtils.
2. We have interfaces which are as fair as I know only implemented by
UIMA itself,
is it ok to break these implementations ?
Here are the cases in question:
FSIterator extends the Iterator If FeatureStructure is specified
as type parameter the signature of the next() method changes and breaks
all implementations.
Feature extends Comparable. If Feature is specified as type parameter
the signature of
compareTo must compareTo(Feature) instead of compareTo(Object)
TypeOrFeature also extends Comparable, can it be changed ?
3.
ResourceFactory.produceResource, is the parameter Class aResourceClass a
Class which
must be subtype of Resource ? If thats true it could be changed to
Class<? extends Resource>.
4. ResourceManager.getResourceClass and getResource(String, ...). Does
getResourceClass always
return a Class which is subclass of Resource ? If thats true getResource
could be changed to return
a Resource object instead of Object.
Jörn
Re: Generics for UIMA interfaces
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>> Jörn Kottmann wrote:
>>
>>> Can I commit my changes ? The patch can be reviewed in UIMA1341.
>>>
>>
>> +1. I have reviewed the patch, applied it to my
>> workspace and run some tests. I think this is a
>> big usability improvement. The change to FS iterators
>> alone is worth it :-)
>>
>
> Thanks for the review. Maybe I made a mistake in
> the ConstraintFactory.embedConstraint. What is
> the intended generic type for the list ? I assumed
> from the javadoc that it is Feature but in the implementation
> it is used as String. What is correct ?
>
> Jörn
It should be strings, actually. So the javadoc is wrong.
The constraint API is string based, so that a textual
representation (which used to exist but we lost sometime)
can be directly mapped to the API. I guess there is no
test case, else we would have noticed that sooner.
--Thilo
Re: Generics for UIMA interfaces
Posted by Jörn Kottmann <ko...@gmail.com>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Can I commit my changes ? The patch can be reviewed in UIMA1341.
>>
>
> +1. I have reviewed the patch, applied it to my
> workspace and run some tests. I think this is a
> big usability improvement. The change to FS iterators
> alone is worth it :-)
>
Thanks for the review. Maybe I made a mistake in
the ConstraintFactory.embedConstraint. What is
the intended generic type for the list ? I assumed
from the javadoc that it is Feature but in the implementation
it is used as String. What is correct ?
Jörn
Re: Generics for UIMA interfaces
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Can I commit my changes ? The patch can be reviewed in UIMA1341.
+1. I have reviewed the patch, applied it to my
workspace and run some tests. I think this is a
big usability improvement. The change to FS iterators
alone is worth it :-)
--Thilo
>
> All changes seem safe to me, after I committed it we may can start a
> discussion
> about changes which break backward compatibility. In some cases this may
> not
> hurt our users, e.g. if it breaks the implementation of interfaces which
> are only implemented
> by UIMA itself.
>
> Jörn
>
> On May 6, 2009, at 12:59 AM, Marshall Schor wrote:
>
>> +1, this would be very nice... -Marshall
>>
>> Michael Baessler wrote:
>>> +1, sounds good to me
>>>
>>> -- Michael
>>>
>>> Jörn Kottmann wrote:
>>>
>>>> Hallo,
>>>>
>>>> I would love to start an initiative to add generics to the
>>>> interfaces in the uima core APIs. Since UIMA now depends
>>>> on java 5 all code which is written against our APIs is full
>>>> with warnings.
>>>>
>>>> I will create a jira issue and attach a patch which should
>>>> be reviewed by someone else to make sure nothing is broken.
>>>>
>>>> Jörn
>>>>
>>>
>>>
>>>
>>>
Re: Generics for UIMA interfaces
Posted by Jörn Kottmann <ko...@gmail.com>.
Can I commit my changes ? The patch can be reviewed in UIMA1341.
All changes seem safe to me, after I committed it we may can start a
discussion
about changes which break backward compatibility. In some cases this
may not
hurt our users, e.g. if it breaks the implementation of interfaces
which are only implemented
by UIMA itself.
Jörn
On May 6, 2009, at 12:59 AM, Marshall Schor wrote:
> +1, this would be very nice... -Marshall
>
> Michael Baessler wrote:
>> +1, sounds good to me
>>
>> -- Michael
>>
>> Jörn Kottmann wrote:
>>
>>> Hallo,
>>>
>>> I would love to start an initiative to add generics to the
>>> interfaces in the uima core APIs. Since UIMA now depends
>>> on java 5 all code which is written against our APIs is full
>>> with warnings.
>>>
>>> I will create a jira issue and attach a patch which should
>>> be reviewed by someone else to make sure nothing is broken.
>>>
>>> Jörn
>>>
>>
>>
>>
>>
Re: Generics for UIMA interfaces
Posted by Marshall Schor <ms...@schor.com>.
+1, this would be very nice... -Marshall
Michael Baessler wrote:
> +1, sounds good to me
>
> -- Michael
>
> Jörn Kottmann wrote:
>
>> Hallo,
>>
>> I would love to start an initiative to add generics to the
>> interfaces in the uima core APIs. Since UIMA now depends
>> on java 5 all code which is written against our APIs is full
>> with warnings.
>>
>> I will create a jira issue and attach a patch which should
>> be reviewed by someone else to make sure nothing is broken.
>>
>> Jörn
>>
>
>
>
>
Re: Generics for UIMA interfaces
Posted by Michael Baessler <mb...@michael-baessler.de>.
+1, sounds good to me
-- Michael
Jörn Kottmann wrote:
> Hallo,
>
> I would love to start an initiative to add generics to the
> interfaces in the uima core APIs. Since UIMA now depends
> on java 5 all code which is written against our APIs is full
> with warnings.
>
> I will create a jira issue and attach a patch which should
> be reviewed by someone else to make sure nothing is broken.
>
> Jörn