Am 09.09.2016 um 16:09 schrieb Joern Kottmann: > Well you are forced to use it when you have to use an AE using it.
Why? Well, yes, if you want change the implementation of that AE. However, you can combine generic CAS AEs with JCas AEs operating on the same annotations. > I think the problem with the JCas is that people think, because we are > offering it as part of UIMA, that is is acceptable to use it, but the truth > is it really isn't. I do not see the problem yet. Why is it not acceptable to use it? Peter > If it would be me deciding, the JCas would be the first > thing > I would throw away for UIMA 3 (and also many other things). > > Jörn > > On Fri, Sep 9, 2016 at 4:00 PM, Richard Eckart de Castilho <[email protected]> > wrote: > >> On 09.09.2016, at 15:49, Peter Klügl <[email protected]> wrote: >>> I get the point with code generation though. >>> >>> Am 09.09.2016 um 15:11 schrieb Joern Kottmann: >>>> I am personally think the convenience the JCas brings is outweighed many >>>> times by all the complexity >>>> and disadvantages which come with it, e.g. code generation step, having >>>> extra special classes and mostly impossible >>>> to reuse the written code. >> Again, nothing forces anybody to actually make use of the JCas. >> If it does not match your taste, then do not use it. >> >> If you find the CAS interface to be lacking some convenience, >> check out the getFeature() and setFeature() methods in uimaFIT FSUtil >> and also the CasUtil select* methods in uimaFIT. >> >> Cheers, >> >> -- Richard
