uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Juric <mario.ju...@cactusglobal.com>
Subject Re: JCasGen support for CAS-transported custom Java objects
Date Sun, 18 Oct 2020 09:49:33 GMT
I experimented with the CAS-transported custom Java objects feature, and I found that it’s
indirectly possible to use them with JCasGen by following the guidelines to wrap each custom
Java object in an UIMA type, which can be reused as an attribute or through inheritance in
the type system. The custom type will have to be handcrafted though, but that is a small thing,
and JCasGen can be used to generate the initial template, but this is all covered in the documentation.

There is a trade off in our case, it will break with the type system of a large number of
existing binaries that we saved, since we already use FSArray where we currently wanna replace
it with some custom Java object. I am not sure how big this issue is for others, but we have
some large data sets that we prefer not to reprocess from scratch too often, although it will
happen at some point. Nevertheless, this design trick brings us some of the way even though
it’s not "the full monty” as I imagine.

> On 17 Oct 2020, at 10.54, Mario Juric <mario.juric@cactusglobal.com> wrote:
>
> Hi,
>
> Are there any plans to support UIMA 3 CAS-transported custom Java objects in JCasGen?
The current TypeSystem description XML that it consumes doesn’t allow specifying these fields,
but could we imagine some way of encoding this into the XML, so that the JGasGen could make
use of it?
>
> We are using the Gradle build system and a third party JCasGen plugin for Gradle to generate
our types, and everything is automated through the build system. Additionally we use IDEA
instead of Eclipse in our development, so we can’t use any of the Eclipse plugins either.
>
> We have on several occasions considered to manually craft some of our types, but we have
so far been reluctant to go down that path, although it isn’t necessarily such a big deal,
especially since it seems to be simpler with UIMA 3. CAS-transported custom Java objects could
be a compelling reason for us to consider this again, since we have a number of cases where
this would yield some performance improvements and simplify our code. We also want to specify
shared interfaces that type system types implement, since that will allow us to make better
use of Java generics with them.
>
> Yet, I believe most of this could also be achieved using the JCasGen with a few extensions
to the type system description, but I don’t know how fixed that is. I can imagine that it
is easy to make changes that has wide implications on the API, which is not the intention
here, but I am thinking more of some extensions that otherwise would be ignored by all other
framework components. I don’t expect everything to be generated either, e.g. some elements
like serialisers and interfaces could be implemented externally and then referenced in the
type system description for use by JCasGen.
>
> Cheers
> Mario


________________________________
Disclaimer:
This email and any files transmitted with it are confidential and directed solely for the
use of the intended addressee or addressees and may contain information that is legally privileged,
confidential, and exempt from disclosure. If you have received this email in error, please
notify the sender by telephone, fax, or return email and immediately delete this email and
any files transmitted along with it. Unintended recipients are not authorized to disclose,
disseminate, distribute, copy or take any action in reliance on information contained in this
email and/or any files attached thereto, in any manner other than to notify the sender; any
unauthorized use is subject to legal prosecution.

Mime
View raw message