Thanks!
Created JIRA ticket is PDFBOX-5151
<https://issues.apache.org/jira/browse/PDFBOX-5151>.
Am 05.04.21 um 14:29 schrieb Andreas Lehmkuehler:
Hi,
Am 05.04.21 um 10:21 schrieb Roland Meub:
Hi All,
I think, I've just found a little bug within
COSParser::validateXrefOffsets, which occures when a xref generation is
corrected using COSObjectKey::fixGeneration.
The issue is, that COSObjectKey is used as a hash-key and this instance
is modified with fixGeneration.
Because of this modification, the hasCode of the COSObjectKey is changed
and the associated hashmap entry cannot longer be found in the
xrefTable.
Hashmap key objects should better be immutabel (see
https://howtodoinjava.com/java/collections/hashmap/design-good-key-for-hashmap/)
According to the change history, this issue was introduced with a commit
for PDFBOX-4153, but PDFBOX-4490 seems also be related.
Yes, that's correct
If you wish, I can provide a fix for this.
I've a possible fix in mind but maybe yours is better. Please create a
JIRA ticket and attach a patch for the trunk if possible
The original intent was, to save few bytes in the COSObjectKey.
Saving 4 bytes within an object seems a bit useless, but since there may
be many instances, it might be an improvement. Beside this, hashCode()
and equals() can be improved a little bit ;-).
Are you interested in this micro-improvement ?
We are interested in any improvement, especially if it affects objects
which are used a lot within a pdf. Those micro-improvements might have
a bigger impact
Thanks in advance
Andreas
I'm referencing the current git repository
https://github.com/apache/pdfbox/tree/trunk
Regards, Roland.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
