Re: v3 and "alternate" JCas cover classes: I don't think anything will change. The way alternate JCas cover classes are supported in V3 is similar. If you don't use this capability, things run without some extra overhead / machinery (for instance, there's no JCasHashMap). When you start using this capability, then each FS which has an alternate JCas cover class gets an extra Java object - essentially, the alternate JCas implementation of that UIMA type. The alternate implementation, however, shares the internal Java int[] and Object[] used to store the fields, with the base JCas implementation object. JCasHashMaps are activated to do the mapping between these objects (this could change if we reserved 4-8 bytes in every FS for this purpose, but that seems a bit expensive for an infrequently-used feature, perhaps).
Re: whether or not it's a good idea: I've seen it used in quite a few places. But I think it's still a reasonable limitation for sharing read-only CASes. -Marshall On 8/21/2016 4:48 PM, Richard Eckart de Castilho wrote: > That's an interesting scenario you are describing. If somebody had asked me > whether > adding additional fields or lookup APIs into JCas cover classes, I'd probably > have > said that would not be a good idea. > > I don't think that with the current CAS implementation much is lost if the > scenario > you are describing is remains unsupported. > > Will anything change regarding that scenario with v3? > > Cheers, > > -- Richard > >> On 19.08.2016, at 21:13, Marshall Schor <[email protected]> wrote: >> >> The switch doesn't modify any CAS - stored Feature Structure content. >> >> It does modify what JCas cover class is used when, for instance, iterating >> over >> some type in the CAS. >> >> Say, for example, you have implemented a JCas cover class for Token, which >> just >> has some standard getters and setters. >> >> Now, suppose, one of the pipelines implements a Pear which has an "enhanced" >> version of the Token JCas class. For example, it might look up the "stem" >> word >> in some dictionary, and have a list of synonyms available, not stored in the >> CAS, but via an extra API "fancysynonyms()". >> >> Now, suppose this CAS is read only, and there are two thread operating on it; >> both with this Pear, where the code isn't going to modify the CAS, but within >> the Pear, will iterate over the Tokens, and will call "fancysynonyms()". >> >> Now imagine the time-linear flow for two threads that looks like this: >> >> Thread 1: start -----------> enter Pear -----> access fancysynonyms >> ---------> >> exit Pear ------> etc. >> >> Thread 2: start -----------> enter Pear >> --------------------------------------------------> access fancysynonyms >> ---------> exit Pear ------> etc. >> >> Thread 1's "exit Pear" will have switched the CAS's jcas loaders back to the >> "plain" one., so thread 2's iterator over Token would be returning the plain >> version of the Token JCas class which would get a class-cast-exception when >> the >> code tried to cast it to the fancy version of the Token JCas class. >> >> At this point, I'm in favor of saying that you cannot use any classpath >> switching with read-only shared CASs. This includes Pears, and the edge >> case in >> UIMA-5054 where the switching was to an "outer" class loading context. >> -Marshall >
