[
https://issues.apache.org/jira/browse/UIMA-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773474#comment-15773474
]
Marshall Schor edited comment on UIMA-5233 at 12/23/16 8:48 PM:
----------------------------------------------------------------
Here's what was done, in an effort to avoid duplication, and insure v2 uses of
classes and interfaces continue to work for built-in non-JCas cover classes.
In v2, there were two Java cover classes for the built-ins - a JCas one, and a
non-JCas one. The hierarchy was:
* FeatureStructureImpl -- common Java class at the top of all
** TOP - common JCas top-most class
** FeatureStructureImplC - common non-JCas top-most class
Classes under TOP / FeatureStructureImplC, for example "Annotation":
* Annotation - the JCas Class
* AnnotationImpl - the non JCas Class
Each pair implemented a common interface, for example, in this case AnnotationFS
The V3 implementation only has one class that represents each built-in type -
it's using the JCas class. To support v2 backwards compatibility, the
following was done:
* The non-JCas class was implemented as an interface, -with some default
methods (Java 8 feature)-
* -The common interface was populated with default methods-
* The JCas class was made to implement, instead of the xxxFS interface, the
xxxImpl (now an interface), which, in turn, implements the xxxFS interface.
-The default methods are ones that "downcast" "this" to the JCas class class,
so no duplication of actual implementation is done.- No downcasts are needed,
since this happens automatically in Java.
The common implementation class in v2, CommonArrayFSImpl, is kept but changed
to an interface, and uses CommonArrayFS as its super interface.
There are no callers in v3 of this class, but it's kept for backwards
compatibility reasons.
The CommonArrayFS interface was provided with default methods to take over its
implementations.
-The clone method was empirically discovered to behave strangely with respect
to interface default mechanism. It only works if it is re-implemented in the
immediate super-interface (it doesn't inherit down from higher up in the
tree).-
was (Author: schor):
Here's what was done, in an effort to avoid duplication, and insure v2 uses of
classes and interfaces continue to work for built-in non-JCas cover classes.
In v2, there were two Java cover classes for the built-ins - a JCas one, and a
non-JCas one. The hierarchy was:
* FeatureStructureImpl -- common Java class at the top of all
** TOP - common JCas top-most class
** FeatureStructureImplC - common non-JCas top-most class
Classes under TOP / FeatureStructureImplC, for example "Annotation":
* Annotation - the JCas Class
* AnnotationImpl - the non JCas Class
Each pair implemented a common interface, for example, in this case AnnotationFS
The V3 implementation only has one class that represents each built-in type -
it's using the JCas class. To support v2 backwards compatibility, the
following was done:
* The non-JCas class was implemented as an interface, with some default methods
(Java 8 feature)
* The common interface was populated with default methods
* The JCas class was made to implement, instead of the xxxFS interfac, the
xxxImpl (now an interface), which, in turn, implements the xxxFS interface.
The default methods are ones that "downcast" "this" to the JCas class class, so
no duplication of actual implementation is done.
The common implementation class in v2, CommonArrayFSImpl, is kept but changed
to an interface, and defaults any implementations to the CommonArrayFS
interface.
There are no callers in v3 of this class, but it's kept for backwards
compatibility reasons.
The CommonArrayFS interface was provided with default methods to take over its
implementations.
The clone method was empirically discovered to behave strangely with respect to
interface default mechanism. It only works if it is re-implemented in the
immediate super-interface (it doesn't inherit down from higher up in the tree).
> uv3 backwards compatibility - add nonJCas built-in cover classes back
> ---------------------------------------------------------------------
>
> Key: UIMA-5233
> URL: https://issues.apache.org/jira/browse/UIMA-5233
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> UIMA v2 implemented for built-ins, 2 kinds of Java cover classes. One was
> "JCas" the other not. Users not using the JCas could make use of the other
> style. V3 has only one style, and uses JCas versions for the actual Feature
> Structure Implementation.
> Create interfaces for the non-JCas style, and supply them with default
> methods that cast "this" to the JCas style actually being used.
> Arrange the hierarchy to follow v2 where possible. Take out new v3 upper
> hierarchy common classes where a v2 class already exists; use that class
> instead (with appropriate casting as above) - so that V2 code that uses these
> continues to work.
> Update the docs: remove the part which says users have to rename the non-JCas
> class uses to the JCas ones (will no longer be required).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
