Issues in making org.apache.uima.jcas.impl.JCas into an interface / impl pair

[Marshall Schor <ms...@schor.com>]

I'm starting to look at converting JCas to an interface, with an impl.  
First issue found: 
this class contains static methods used by JCasGen-erated code, for 
factored-out,
common methods to report errors, etc.
(e.g. when getting a feature, there's code like:

 if (featOkTst && casFeat_xxxx == null)
            JCas.throwFeatMissing("xxxx, "cas-type-name-for-xxxx");

These calls are in pre-existing JCas cover classes.  I guess we're 
planning to have new JCas cover classes generated
(unless we put in a layer to make the old ones work - they would be 
tying into classes named "com.ibm.etc.").

So I can change JCasGen to generate a ref to JCasImpl.etc.  instead of 
JCas.etc.

 if( featOkTst && casFeat_xxxx == null)
            JCasImpl.throwFeatMissing("xxxx, "cas-type-name-for-xxxx");

Does this sound like the right idea?

-Marshall

Re: Issues in making org.apache.uima.jcas.impl.JCas into an interface / impl pair

[Marshall Schor <ms...@schor.com>]

I completed a "refactoring" of JCas into interface + impl.  It was done 
with the refactoring tools of Eclipse - so it's "mechanical" - no real 
"thought" :-)

As described below, I had to rename the old JCas to JCasImpl; I moved 
the new interface to
org.apache.uima.jcas.JCas.

I still have to fix JCasGen to generate the right kinds of cover 
classes.  The refactoring went thru all the existing generated classes 
and "fixed them up".

Some further issues to consider / think about:
1) having the generated JCas classes use a different class, JCasUtils 
(?) for their static methods.
2) factoring out the common interface definitions for CAS interface and 
JCas interface - a lot of them should be the same.  It would be nice to 
have this clearly partitioned, logically :-)

-Marshall


Marshall Schor wrote:
> I'm starting to look at converting JCas to an interface, with an 
> impl.  First issue found: this class contains static methods used by 
> JCasGen-erated code, for factored-out,
> common methods to report errors, etc.
> (e.g. when getting a feature, there's code like:
>
> if (featOkTst && casFeat_xxxx == null)
>            JCas.throwFeatMissing("xxxx, "cas-type-name-for-xxxx");
>
> These calls are in pre-existing JCas cover classes.  I guess we're 
> planning to have new JCas cover classes generated
> (unless we put in a layer to make the old ones work - they would be 
> tying into classes named "com.ibm.etc.").
>
> So I can change JCasGen to generate a ref to JCasImpl.etc.  instead of 
> JCas.etc.
>
> if( featOkTst && casFeat_xxxx == null)
>            JCasImpl.throwFeatMissing("xxxx, "cas-type-name-for-xxxx");
>
> Does this sound like the right idea?
>
> -Marshall
>
>

Re: Issues in making org.apache.uima.jcas.impl.JCas into an interface / impl pair

[Marshall Schor <ms...@schor.com>]

Next issue with fixing JCasGen -
The pre-Apache code base had a tool, called uimaj_jet_expander - which 
ran against templates and included templates that were part of the 
uimaj_jcasgen_gen code.

I can't see the jet_expander tool in the apache source - did it not come 
over?  If not, any reason not to bring it over now?

I can't see the templates used for jcasgen either.  Any reason not to 
bring those over too?

-Marshall

Re: Issues in making org.apache.uima.jcas.impl.JCas into an interface / impl pair

[Adam Lally <al...@alum.rpi.edu>]

>  if (featOkTst && casFeat_xxxx == null)
>            JCas.throwFeatMissing("xxxx, "cas-type-name-for-xxxx");
>
> These calls are in pre-existing JCas cover classes.  I guess we're
> planning to have new JCas cover classes generated
> (unless we put in a layer to make the old ones work - they would be
> tying into classes named "com.ibm.etc.").

I already have a utility that does the appropriate search-and-replace
operations on user code to migrate it from IBM UIMA to Apache UIMA.
I'd like that to also work on JCas cover classes.  It takes care of
the com.ibm -> org.apache change, for sure.  If other changes can be
handled by simple search and replace, we can easily add those as ell.


> So I can change JCasGen to generate a ref to JCasImpl.etc.  instead of
> JCas.etc.
>
>  if( featOkTst && casFeat_xxxx == null)
>            JCasImpl.throwFeatMissing("xxxx, "cas-type-name-for-xxxx");
>
> Does this sound like the right idea?
>

I like using JCasUtil rather than JCasImpl for this, as you suggested
in your other email.  This change is easy enough to make with search
and replace.

-Adam