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 <[email protected]> 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.
