[
https://issues.apache.org/jira/browse/VFS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716775#action_12716775
]
Vince Bonfanti commented on VFS-245:
------------------------------------
Here's what I've discovered about this problem:
1) The AbstractFileName equals() and hashcode() methods rely on its
getRootUri() and getPath() methods.
2) The getRootUri() method invokes appendRootUri(), which is an abstract
method. Since we can't know what the subclass might do within appendRootUri(),
it's probably not a good idea for getRootUri() to be used by equals() or
hashcode().
3) The getPath() method might invoke getUriTrailer() based on the setting of
VFS.isUriStyle(). The getUriTrailer() method is the one that invokes getType()
to determine whether to add a "/" to the path. Therefore, it's probably not a
good idea for getPath() to be used by equals() or hashcode().
I recommend that equals() and hashcode() be modified to rely only on the
"scheme" and "absPath" properties, both of which are Strings and both of which
are immutable. A patch file with the proposed change is attached.
> FileName interface says that it is immutable, however
> AbstractFileName.setType(FileType type) flouts this rule
> --------------------------------------------------------------------------------------------------------------
>
> Key: VFS-245
> URL: https://issues.apache.org/jira/browse/VFS-245
> Project: Commons VFS
> Issue Type: Bug
> Reporter: Sebb
> Attachments: AbstractFileName.java.patch
>
>
> FileName interface says that it is immutable, however
> AbstractFileName.setType(FileType type) flouts this rule.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
