[
https://issues.apache.org/jira/browse/CONFIGURATION-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18077396#comment-18077396
]
Rob Spoor commented on CONFIGURATION-855:
-----------------------------------------
Technically this isn't necessary. Object.clone() explicitly mentions that it
isn't necessary that clones are equal to the original:
{quote}The general intent is that, for any object x, the expression:
{code}x.clone() != x{code}
will be true, and that the expression:
{code}x.clone().getClass() == x.getClass(){code}
will be true, but these are not absolute requirements. While it is typically
the case that:
{code}x.clone().equals(x){code}
will be true, this is not an absolute requirement.{quote}
> apache/commons-configuration — 7 Cloneable classes missing equals()/hashCode()
> ------------------------------------------------------------------------------
>
> Key: CONFIGURATION-855
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-855
> Project: Commons Configuration
> Issue Type: Bug
> Reporter: Shan Jiang
> Priority: Major
>
> Summary
> Seven classes implement `Cloneable` with correct `clone()` but do not override
> `equals()`/`hashCode()`. `x.clone().equals` always returns `false`.
>
> Affected classes
> - `BaseConfiguration`
> - `CombinedConfiguration`
> - `CompositeConfiguration`
> - `BasicBuilderParameters`
> - `FileBasedBuilderParametersImpl`
> - `CombinedBuilderParametersImpl`
> - `MultiFileBuilderParametersImpl`
>
> How this was found
> Detected by an automated JDK conformance oracle
> (`ObjectOracles.checkCloneEqualsConsistency`).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
