[
https://issues.apache.org/jira/browse/COLLECTIONS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687042#comment-13687042
]
Thomas Neidhart commented on COLLECTIONS-473:
---------------------------------------------
As decorated() is not final, sub-classes can alter the return type as in
AbstractBagDecorator, thus avoiding the necessity to cast. Changing this does
not make sense imho.
Hiding the collection field and creating a protected setter for
de-serialization support would be ok, but would require the effort to change of
course.
> AbstractCollectionDecorator.decorated() should not be used internally
> ---------------------------------------------------------------------
>
> Key: COLLECTIONS-473
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-473
> Project: Commons Collections
> Issue Type: Bug
> Reporter: Sebb
>
> AbstractCollectionDecorator.decorated() is used internally to access the
> collection.
> However, the method is not final, so subclasses could override it.
> Yet the field is also exposed (protected).
> This is inconsistent.
> Is there any use-case for overriding the collection to use a different one?
> If so, having direct access as well is likely to cause problems.
> I think it would be better to use the field directly internally.
> The class Javadoc says the calls are forwarded to the underlying collection,
> but that is not strictly true if decorated() is overridden.
> If it is intended to allow this to be overridden, then the field needs to be
> protected against arbitrary read/write access.
> The field should probably be made private with a setter for use by
> deserialization only.
--
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
