commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COLLECTIONS-473) AbstractCollectionDecorator.decorated() should not be used internally
Date Tue, 18 Jun 2013 10:05:20 GMT

    [ https://issues.apache.org/jira/browse/COLLECTIONS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686544#comment-13686544
] 

Sebb commented on COLLECTIONS-473:
----------------------------------

Replacing "collection" with "decorated()" in sub-classes does not affect the casting issue
as they are both of type Collection<E>.

The problem with allowing direct access is that a grand-child sub-class can accidentally subvert
a child sub-class.

For example, if one wanted to create a logging layer, it could not guarantee that all sub-class
accesses were logged.

It would also potentially allow the field to be made final later, by suitable changes to the
deserialisation.

Exposing the field now means it *cannot later be hidden* whilst maintaining compatibility.

Hiding the field provides several benefits; any down-sides seem to me to be very minor in
comparison.

It will still be possible to deliberately subvert the class via reflection, but at least casual
misuse is avoided.
                
> 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

Mime
View raw message