JDK-8242477 : (bf) MappedByteBuffer should clarify copying between overlapping mappings
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2020-04-09
  • Updated: 2020-06-04
  • Resolved: 2020-06-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15Resolved
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Description
If two MappedByteBuffers are created by mapping overlapping ranges of the same file, then copying between these buffers may yield unexpected results. For example, in the attached class MappedOverlapCopy, the middle half of a file is mapped to one buffer which then puts its contents into another buffer which is mapped from the second half of the file. The third and fourth quarters of the file then end up each being equal to the second quarter of the original file contents. This is different for example from the behavior of System.arraycopy() which for overlapping contents behaves as if the source data were first copied into a separate, temporary location and then copied to the destination location. If such behavior were to obtain for MappedByteBuffer, then the result of the example would be that the upper half of the file contents would end up being equal to the middle half of the original file contents. The documentation of MappedByteBuffer should be updated to clarify that the outcome of such overlapped copying is unspecified.
Comments
The described behavior has been superseded by clearly specified behavior due to the fix of JDK-8246282. Therefore resolving this issue as Not an Issue.
04-06-2020