JDK-5029431 : (bf) Add absolute bulk put and get methods
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-04-09
  • Updated: 2024-04-29
  • Resolved: 2019-02-20
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 13
13 b09Fixed
Related Reports
CSR :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8226802 :  
Description

Name: rmT116609			Date: 04/08/2004


A DESCRIPTION OF THE REQUEST :
The ByteBuffer class does not support the writing of byte arrays at to an absolute position within a ByteBuffer.

JUSTIFICATION :
- Completeness
- Allows multiple threads to do efficient bulk updates to the same ByteBuffer.
- Using slice() and duplicate() to get the same functionality will create a large amount of unwanted references to the oringial buffer.  This makes it difficult to be certain that all references are set null to allow the MappedByteBuffer to be Garbage Collected.  My application requires unmap functionality, which I have implemented using the Garbage Collector and Phantom References (due to no unmap method).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
4 new methods added to the ByteBuffer class:

public ByteBuffer get(int index, byte[] dst);
public ByteBuffer get(int index, byte[] dst, int offset, int length);
public ByteBuffer put(int index, byte[] src);
public ByteBuffer put(int index, byte[] src, int offset, int length);
ACTUAL -
The bulk get and put methods should behave like the absolute primitive get/put methods, but efficently updating the Buffer.

CUSTOMER SUBMITTED WORKAROUND :
Using slice() and duplicate(), but this is not appropriate for my application.
(Incident Review ID: 239468) 
======================================================================

Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2685 Date: 2024-04-26 18:28:34 +0000
26-04-2024

commit https://github.com/openjdk/jdk/commit/315b7d03999e420d496a5bc269c4c779adf8417c Author: Brian Burkhalter <bpb@openjdk.org> Date: Wed Feb 20 10:57:22 2019 -0800
26-04-2024

URL: http://hg.openjdk.java.net/jdk/jdk/rev/7c362992527a User: bpb Date: 2019-02-20 18:57:59 +0000
20-02-2019

JDK-6174965 might be a duplicate of this one. Consider a use case where multiple threads are to operate on a large region of memory by dividing it up into segments, and having each thread operate on its own segment. Each thread should be able to read and write its segment independently. This is fairly difficult using the current API. This RFE, and the related absolute slicing RFE (JDK-5071718), are essential for this. The existing bulk get/put methods are relative, using the buffer's current position as an implicit parameter, and so cannot be used from multiple threads simultaneously. One way to work around this is to slice the buffer into multiple buffers, which in effect creates independent positions in the same buffer. Unfortunately slice() itself relies on the current position, so this too cannot be done from multiple threads.
24-02-2014

EVALUATION A reasonable idea, but not critical for Tiger. -- ###@###.### 2004/4/28
04-12-0194