[
https://issues.apache.org/jira/browse/COLLECTIONS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687124#comment-13687124
]
Sebb commented on COLLECTIONS-473:
----------------------------------
Yes, classes could override decorated() to change the return type; that's
exactly what the AbstractBagDecorator and AbstractSortedBagDecorator
sub-classes do; they don't access collection directly at all. I'm just
suggesting that the rest of the classes behave the same way, at least as far as
not accessing collections directly.
Since the overload decorated() method should make it easier for subclasses,
that seems like a good idea.
I'm happy to make the changes, but I don't want to do it if they will then need
to be reverted.
==
What about the main point of this JIRA, i.e. using collection internally rather
than decorated()?
Is that OK to change?
> 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
