[
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: [email protected]
For additional commands, e-mail: [email protected]
