Absolute index bulk put/get byte operations on ByteBuffer

[Martin Thompson]

On Fri, 7 Sep 2018 at 11:43, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 06/09/2018 20:42, Martin Thompson wrote:
> > There has been a long outstanding issue of ByteBuffer not having
> > methods to get or put a ByteBuffer or byte[] at an absolute index.
> >
> > https://bugs.openjdk.java.net/browse/JDK-5029431
> >
> > This seriously hampers the usefulness of ByteBuffer in a concurrent
> > environment due to contention on the position and limit fields.
> > Slicing or duplicating are not valid options are this are not
> > threadsafe and they allocate.
> >
> > Is there any reason why this bug has not been progressed?
> Many of the calls for absolute operations on ByteBuffers over the years
> have really been cases where someone wanted to operate on a region of
> memory and ended up using a direct buffer because they didn't have
> anything better. The buffer position/limit get in the way in many of
> these cases of course.
>
> As regards JDK-5029431 then I think these methods should have been added
> a long time ago but adding them now does beg the question as to how
> ByteBuffers will interact with memory regions or similar concept that
> Project Panama may introduce. There is also the question of addressing
> with large files (mapping regions > 2GB). Stuart might want to comment
> on this as I think he has concerns about adding further methods here
> until some of these other interactions are worked out.
>

I've tried to migrate a number of projects away from using Unsafe but
issues like this keep hampering progress. When is Panama likely to deliver?
Until then will Unsafe be available?

It would be really nice to have a better alternative but until then it
feels wrong to keep putting off fixing an immediate need for some solution
that might come in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180907/280e2943/attachment.html>