ByteBuffer cannot be extended because constructors have default visibility

[Philippe Marschall]

Hello Luke

I was told this would lead to massive performance degradation due to
C2 deoptimization events.

Cheers
Philippe

On Thu, Apr 23, 2020 at 5:19 PM Luke Hutchison <luke.hutch at gmail.com> wrote:
>
> The ByteBuffer class cannot be extended, because its two constructors both have default visibility. This is problematic, since there are numerous situations where it would be useful to be able to extend ByteBuffer.
>
> For example, I needed to create a ByteBuffer that was backed by a RandomAccessFile (without actually mapping the file to a MappedByteBuffer), so that I could use a RandomAccessFile with a ByteBuffer API. As far as I can tell, there is no way to do this. This led to a huge amount of unnecessary work and duplicated code, since methods that accepted ByteBuffer now needed to have a duplicated alternative that accepted RandomAccessFile.
>
> I just came across another example of this -- Google's Jimfs (in-memory filesystem) has run into the same problem. Currently if you call FileChannel.open(path) on a Jimfs path, then call map() on the file channel to mmap it, Jimfs throws an UnsupportedOperationException. This is due to ByteBuffer not being extendable: https://github.com/google/jimfs/issues/54
>
> This seems like an unnecessary restriction, based on the source of ByteBuffer. Can the ByteBuffer constructors please be made public?
>