You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Jim Challenger (JIRA)" <de...@uima.apache.org> on 2015/04/09 20:09:12 UTC

[jira] [Created] (UIMA-4336) DUCC CLI: Different results with different JRE

Jim Challenger created UIMA-4336:
------------------------------------

             Summary: DUCC CLI: Different results with different JRE
                 Key: UIMA-4336
                 URL: https://issues.apache.org/jira/browse/UIMA-4336
             Project: UIMA
          Issue Type: Bug
          Components: DUCC
    Affects Versions: 1.1.0-Ducc
            Reporter: Jim Challenger
            Assignee: Jim Challenger
             Fix For: 2.0.0-Ducc


So far this only affects the service API/CLI, perhaps because it is more complex than the others.

The net is the API produces ClassNotFound exceptions under Oracle 1.7 JREs and later, but work in all other (IBM and Apple-supplied JREs of all tested vintages).

Everything works under IBM JREs but the fields that are initialized by initializes in the declarations in the returned objects are initialized a bit differently; in particular, at least one string field is initialized to null despite being declared like this:
String foo = "N/A";  If the field is updated as part of executing the CLI in the SM it is returned correctly.

Only the query was working in the Oracle JREs.  Other SM APIs returned ClassNotFound for the base class returned by the query that works!

An older JRE produced by Sun works the same as the IBM JRE.

I believe this is a discrepancy and possibly a bug in the Oracle JREs.

The "solution" was not to change the DUCC classloader but instead to declare the returned API objects to look fully like Java Beans with no-parameter constructors and getter/setter methods.  It's unclear why this matters but any port in a storm ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)