[
https://issues.apache.org/jira/browse/PDFBOX-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016294#comment-16016294
]
ASF subversion and git services commented on PDFBOX-3794:
---------------------------------------------------------
Commit 1795553 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1795553 ]
PDFBOX-3794: remove field from hash calculation because it is rather a cached
value
> Problem in TextPosition implementation
> --------------------------------------
>
> Key: PDFBOX-3794
> URL: https://issues.apache.org/jira/browse/PDFBOX-3794
> Project: PDFBox
> Issue Type: Bug
> Reporter: Miro Mannino
> Labels: easyfix
>
> In 2.0.3 there wasn't hashCode implemented in TextPosition, and for me that
> was fine. Same instance, same hashCode.
> In 2.0.6 the hashCode is now checking the fields values, which is reasonable.
> But, the hashCode in the same instance can have different results.
> The problem is in the `direction` field, which is -1.0 and initialised only
> when getDir is called the first time.
> For now as workaround, anytime (or just the first time) I need the
> textPosition's hashCode I call getDir before that.
> Quick example:
> {code}
> Object getObjectFromTextPos(TextPosition textPos) {
> textPos.getDir();
> return someHashMap.get(textPos);
> }
> {code}
> I don't know the reason of the late assignment to direction, but if that is
> necessary, I would say that the hashCode should call getDir() instead of
> using the field.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
