uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: "Standard" UIMA typesystem
Date Fri, 09 Sep 2016 14:23:09 GMT
If an AE uses it, you are not forced to use it as well. Other code
can still operate via the CAS interface. The JCas wrappers don't even
need to be visible to the rest of the code if you use PEARs or OSGi
or some alternative classloader management.

For my part, I consider JCas to be a great utility to build UIMA wrappers
that provides type safety and facilitates refactoring. If JCas would not
be there as a generic mechanism, the first think I'd do would be to
manually implement Java wrapper classes for specific types of FSes.

The UIMA framework comes in layers of APIs and if you don't like some
of these layers, then don't use them. An API that you may find horrible
may well be the exact thing that others link about the framework.

Btw. I think the title of this subthread should be changed. It doesn't seem
anymore to be about promoting interoperability through convergence on a
specific type system, but rather about promoting flexibility by removing
constraints (which IMHO will likely end up in even less interoperability).


-- Richard

> On 09.09.2016, at 16:09, Joern Kottmann <kottmann@gmail.com> wrote:
> Well you are forced to use it when you have to use an AE using it.
> 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. 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 <rec@apache.org>
> wrote:
>> On 09.09.2016, at 15:49, Peter Klügl <peter.kluegl@averbis.com> 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

View raw message