ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Grahn (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AXIOM-445) Ambiguously typed field & methods associated with OMText
Date Wed, 09 Jan 2013 21:40:12 GMT

     [ https://issues.apache.org/jira/browse/AXIOM-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Grahn updated AXIOM-445:
------------------------------

    Description: 
OMText has an ambiguously typed field "datahandler", which leads to ambiguously typed getters,
setters, constructors, and factory methods (elsewhere).

OMTextImpl's behavior (as of 1.2.10) requires that the "Object" argument be either a DataHandler
or DataHandlerProvider.   Any other object type will potentially result in a class cast exception
within this class's own use.   Moreover, this requirement is undocumented in the API Javadocs.

Using properly typed field/constructor/getter/setter/factory methods would not only increase
clarity to users and remove a potential ClassCastException, but also remove switch statements
based upon instanceof.

The field does have a comment which states the intent is "removing the dependency on javax.activation.DataHandler",
but to what end?   The import statement is included in the most recent versions of the OMTextImpl
and there's a good chance the class would have to be present at runtime anyway.   Furthermore,
other classes within Axiom do require DataHandler as part of their interface.

As this would be a change to the API, I assume any action on this would probably require waiting
until a major version.

  was:
OMText has an ambiguously typed field "datahandler", which leads to ambiguously typed getters,
setters, constructors, and factory methods (elsewhere).

The class's behavior (as of 1.2.10) requires that the "Object" argument be either a DataHandler
or DataHandlerProvider.   Any other object type will potentially result in a class cast exception
within this class's own use.   Moreover, this requirement is undocumented in the API Javadocs.

Using properly typed field/constructor/getter/setter/factory methods would not only increase
clarity to users and remove a potential ClassCastException, but also remove switch statements
based upon instanceof.

The field does have a comment which states the intent is "removing the dependency on javax.activation.DataHandler",
but to what end?   The import statement is included in the most recent versions of the file
and there's a good chance the class would have to be present at runtime anyway.   Furthermore,
other classes within Axiom do require DataHandler as part of their interface.

As this would be a change to the API, I assume any action on this would probably require waiting
until a major version.

    
> Ambiguously typed field & methods associated with OMText
> --------------------------------------------------------
>
>                 Key: AXIOM-445
>                 URL: https://issues.apache.org/jira/browse/AXIOM-445
>             Project: Axiom
>          Issue Type: Improvement
>            Reporter: James Grahn
>            Priority: Minor
>
> OMText has an ambiguously typed field "datahandler", which leads to ambiguously typed
getters, setters, constructors, and factory methods (elsewhere).
> OMTextImpl's behavior (as of 1.2.10) requires that the "Object" argument be either a
DataHandler or DataHandlerProvider.   Any other object type will potentially result in a class
cast exception within this class's own use.   Moreover, this requirement is undocumented in
the API Javadocs.
> Using properly typed field/constructor/getter/setter/factory methods would not only increase
clarity to users and remove a potential ClassCastException, but also remove switch statements
based upon instanceof.
> The field does have a comment which states the intent is "removing the dependency on
javax.activation.DataHandler", but to what end?   The import statement is included in the
most recent versions of the OMTextImpl and there's a good chance the class would have to be
present at runtime anyway.   Furthermore, other classes within Axiom do require DataHandler
as part of their interface.
> As this would be a change to the API, I assume any action on this would probably require
waiting until a major version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message