[PR] Fix equals in HSSFPalette.CustomColor, CustomProperty and TextPiece [poi]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning opened a new pull request, #1379:
URL: https://github.com/apache/poi/pull/1379

   These are the `equals` findings from SpotBugs that are actual problems.
   
   ### Fixed
   - **`HSSFPalette.CustomColor`** (a real bug): `HSSFColor.equals` compares the base class's index and RGB. `CustomColor` keeps its own index and colour bytes and never sets those base fields. So every colour returned by `HSSFPalette.getColor` for a custom palette entry equalled every other one. `CustomColor` now implements `equals`/`hashCode` from its index and RGB.
   - **`CustomProperty` vs `Property`** (asymmetric): `Property.equals` ignores the name, so `property.equals(customProperty)` could be true while `customProperty.equals(property)` was false. Sections hold both: a section read from a file has plain `Property` objects, while one built through `setCustomProperties` has `CustomProperty` objects. So the result of `Section.equals` depended on which section came first.
     - `CustomProperty.equals` now compares a plain `Property` the way `Property.equals` does. Two `CustomProperty` objects are still compared by name too.
     - `Property.equals` is unchanged, so no comparison that returned true before now returns false.
   - **`TextPiece` vs `OldTextPiece`** (asymmetric): `TextPiece.equals` accepted any subclass, while `OldTextPiece.equals` only accepted `OldTextPiece`. `TextPiece.equals` now requires the same class.
   
   ### Not changed
   - **`EscherArrayProperty`** doesn't override `equals`: the inherited `EscherComplexProperty.equals` already compares the complex data, and that holds the array.
   - **`ZipArchiveFakeEntry`** doesn't override `equals`: POI never compares these entries.
   - **`ZipPackage.EntryTriple` and `AbstractWordConverter.Structure`** have a `compareTo` that is inconsistent with `equals`. Both are private and only used to sort lists, so this has no effect.
   - **`Property.hashCode`** is not consistent with `Property.equals` for `byte[]` values: they are compared by content but hashed by identity. This is pre-existing and left as is.
   
   New tests cover each fix: `TestHSSFPalette.testCustomColorEquals`, `TestCustomProperty` and `TestTextPiece`. The hpsf package, `TestHSSFColor`, `TestHSSFPalette` and the hwpf model tests all pass.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: [PR] Fix equals in HSSFPalette.CustomColor, CustomProperty and TextPiece [poi]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning merged PR #1379:
URL: https://github.com/apache/poi/pull/1379


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org