You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Adam Lally (JIRA)" <ui...@incubator.apache.org> on 2007/01/17 17:41:30 UTC
[jira] Resolved: (UIMA-10) Split JCas into interface and
implementation
[ https://issues.apache.org/jira/browse/UIMA-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Lally resolved UIMA-10.
----------------------------
Resolution: Fixed
Assignee: Marshall Schor (was: Adam Lally)
Refactoring complete. Assigning to Marshall to review.
> Split JCas into interface and implementation
> --------------------------------------------
>
> Key: UIMA-10
> URL: https://issues.apache.org/jira/browse/UIMA-10
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Adam Lally
> Assigned To: Marshall Schor
> Fix For: 2.1
>
>
> We should split the existing JCAS class into an interface org.apache.uima.jcas.JCas and its implementation org.apache.uima.jcas.impl.JCasImpl. This follows good design practices and also is consistent with the rest of uimaj-core. It is important to do this prior to our first release since it will be a non-compatible change for user code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (UIMA-10) Split JCas into interface and implementation
Posted by Adam Lally <al...@alum.rpi.edu>.
On 1/20/07, Marshall Schor <ms...@schor.com> wrote:
> There's a general "rule" in Java that you should not store a ref to a
> partially-initialized instance in another object, because it allows
> another thread to potentially access a Java Object that is not yet fully
> initialized.
>
> The use of JCasRegistry might be doing this. It stores into an
> externally-observable array (observable on other threads) a ref to the
> class Foo, before Foo is fully initialized.
><snip/>
Hmmm. This isn't actually a case of an Object (instance) being
referenced before it's finished initialized, but a Class being
referenced before its static initialization has finished. The same
issues may apply to this case, but I am not sure. I think for there
to be a problem, the code referencing the Class object would need to
use reflection to try to access a static field or method, perhaps
before some static field had been initialized. I wonder if Java does
anything to guard against that happening before static initialization
has completed.
> I don't think this is an actual issue in our case, because I think this
> value is only used to obtain a ref to the class for the purpose of
> getting the class "name" to use in an error message. Other opinions?
>
Right, we don't try to invoke a method or access a field so I think we're good.
-Adam
Re: [jira] Resolved: (UIMA-10) Split JCas into interface and implementation
Posted by Marshall Schor <ms...@schor.com>.
There's a general "rule" in Java that you should not store a ref to a
partially-initialized instance in another object, because it allows
another thread to potentially access a Java Object that is not yet fully
initialized.
The use of JCasRegistry might be doing this. It stores into an
externally-observable array (observable on other threads) a ref to the
class Foo, before Foo is fully initialized. It does this using the code:
/**
* Each cover class when loaded sets an index. Used in the JCas
typeArray to go from the cover
* class or class instance to the corresponding instance of the _Type
class
*/
public final static int typeIndexID = JCasRegistry.register(TOP.class);
I don't think this is an actual issue in our case, because I think this
value is only used to obtain a ref to the class for the purpose of
getting the class "name" to use in an error message. Other opinions?
-Marshall
Re: [jira] Resolved: (UIMA-10) Split JCas into interface and implementation
Posted by Adam Lally <al...@alum.rpi.edu>.
On 1/20/07, Marshall Schor <ms...@schor.com> wrote:
> The impl of JCas TOP has code in it to copy into the newly created
> feature structure in the CAS, the CAS's current sofa ref:
>
> if (casImpl.isAnnotationType(jcasType.casTypeCode)) {
> casImpl.setSofaFeat(addr, casImpl.getSofaRef());
>
> But this seems to not be general enough. I think it should be done if
> the type being created is a subtype of
> AnnotationBase, not just Annotation.
>
> Do others agree? Does other code (not using the JCas) have a similar issue?
>
+1. Looks like you've already fixed this, thanks.
-Adam
Re: [jira] Resolved: (UIMA-10) Split JCas into interface and implementation
Posted by Marshall Schor <ms...@schor.com>.
The impl of JCas TOP has code in it to copy into the newly created
feature structure in the CAS, the CAS's current sofa ref:
if (casImpl.isAnnotationType(jcasType.casTypeCode)) {
casImpl.setSofaFeat(addr, casImpl.getSofaRef());
But this seems to not be general enough. I think it should be done if
the type being created is a subtype of
AnnotationBase, not just Annotation.
Do others agree? Does other code (not using the JCas) have a similar issue?
-Marshall