[
https://issues.apache.org/jira/browse/OAK-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5301:
-------------------------------
Attachment: OAK_5301.patch
Proposed patch: [^OAK_5301.patch].
After a mind boggling analysis I came to the conclusion that when
{{MapEntry.compareTo()}} actually is called neither {{this.name}} nor
{{that.name}} could be {{null}}. The {{compareTo()}} method is called from the
{{sort()}} call in {{MapLeafWriter.writeRecordContent()}}. When we are at that
place it is guaranteed that the array of {{MapEntry}} instances being sorted
does not contain any with a {{null}} value. This is the case as earlier
{{SegmentWriteOperation.writeMapBucket()}} takes care of removing those entries
from the base map that have {{null}} values of the passed in entries.
Still I find the current contract of {{MapEntry.compareTo()}} only working on
non null {{value}} fields very brittle. This might start breaking depending on
how the code evolves. I therefore suggest to extend the {{comparaTo()}} method
accordingly and sort the {{null}} values to the end. At the same time I made
the two concerns (reading/writing) encoded in {{MapEntry}} more explicit by
replacing its constructor by respective factory methods.
[~alex.parvulescu], [~dulceanu], [~frm], could any of you have a look at this?
> Possible null dereference in MapRecord
> --------------------------------------
>
> Key: OAK-5301
> URL: https://issues.apache.org/jira/browse/OAK-5301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK_5301.patch
>
>
> {{MapEntry.compareTo()}} passes possibly {{null}} {{MapEntry.value}} to
> {{ComparisonChain.compare(Comparable, Comparable)}}, which does not accept
> {{null}} values.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
