[
https://issues.apache.org/jira/browse/UIMA-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-3560:
---------------------------------------------
Description:
The AnnotationFactory provides a shortcut alternative to creating an annotation
and adding it to the indexes:
*JCas/UIMA:*
{noformat}
new Token(jcas, 1, 5).addToIndexes();
{noformat}
*AnnotationFactory*
{noformat}
createAnnotation(jcas, 1, 5, Token.class);
{noformat}
Internally, AnnotationFactory uses reflection on JCas classes to achieve that
and if there is a problem while reflectively creating the annotation, it throws
an UIMAException. It is very unlikely that a problem would occur. It could
happen if security restrictions are in place on certain JCas wrapper classes.
Yet, the UIMAException is not a RuntimeException, so it must be caught by
client code.
AnnotationFactory could use the CAS interface instead of reflection to avoid
the exception. We can be sure that any annotation created through the CAS
interface can safely be cast to a JCas wrapper type, because the JCas has
already been initialized when this method is calls (it receives a JCas as
argument).
But I also think that the space-saving provided this single method in
AnnotationFactory is simply not enough to warrant this factory. I plan to
change remove usage of this class within uimaFIT and to deprecate it in the
next release.
was:
The AnnotationFactory provides a shortcut alternative to creating an annotation
and adding it to the indexes:
*JCas/UIMA:*
{noformat}
new Token(jcas, 1, 5).addToIndexes();
{noformat}
*AnnotationFactory*
{noformat}
createAnnotation(jcas, 1, 5);
{noformat}
Internally, AnnotationFactory uses reflection on JCas classes to achieve that
and if there is a problem while reflectively creating the annotation, it throws
an UIMAException. It is very unlikely that a problem would occur. It could
happen if security restrictions are in place on certain JCas wrapper classes.
Yet, the UIMAException is not a RuntimeException, so it must be caught by
client code.
AnnotationFactory could use the CAS interface instead of reflection to avoid
the exception. We can be sure that any annotation created through the CAS
interface can safely be cast to a JCas wrapper type, because the JCas has
already been initialized when this method is calls (it receives a JCas as
argument).
But I also think that the space-saving provided this single method in
AnnotationFactory is simply not enough to warrant this factory. I plan to
change remove usage of this class within uimaFIT and to deprecate it in the
next release.
> Deprecate AnnotationFactory
> ---------------------------
>
> Key: UIMA-3560
> URL: https://issues.apache.org/jira/browse/UIMA-3560
> Project: UIMA
> Issue Type: Improvement
> Components: uimaFIT
> Reporter: Richard Eckart de Castilho
> Assignee: Richard Eckart de Castilho
> Priority: Minor
> Fix For: 2.0.1uimaFIT
>
>
> The AnnotationFactory provides a shortcut alternative to creating an
> annotation and adding it to the indexes:
> *JCas/UIMA:*
> {noformat}
> new Token(jcas, 1, 5).addToIndexes();
> {noformat}
> *AnnotationFactory*
> {noformat}
> createAnnotation(jcas, 1, 5, Token.class);
> {noformat}
> Internally, AnnotationFactory uses reflection on JCas classes to achieve that
> and if there is a problem while reflectively creating the annotation, it
> throws an UIMAException. It is very unlikely that a problem would occur. It
> could happen if security restrictions are in place on certain JCas wrapper
> classes. Yet, the UIMAException is not a RuntimeException, so it must be
> caught by client code.
> AnnotationFactory could use the CAS interface instead of reflection to avoid
> the exception. We can be sure that any annotation created through the CAS
> interface can safely be cast to a JCas wrapper type, because the JCas has
> already been initialized when this method is calls (it receives a JCas as
> argument).
> But I also think that the space-saving provided this single method in
> AnnotationFactory is simply not enough to warrant this factory. I plan to
> change remove usage of this class within uimaFIT and to deprecate it in the
> next release.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)