JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Attila Szegedi]

I can think of several differences. For one, you can’t presume the availability of a filesystem (Java doesn’t require that the host system give it access to a filesystem), nor the ability of the filesystem to expose all desired kinds of memory as files. Next, every such solution is OS specific and we love having OS independent APIs in Java. An aspect of OS-specific functionality would also be access controls to these files, while with a Java API such controls can (if needed) be managed by Java security policy (again, in OS independent fashion). Finally, even if all of this is present in the system, exposing memory as files can be a security issue if an external process can also gain access to them.

So a simple in-process, OS-independent API is definitely better suited for the task.

Just my opinion,
  Attila.

On 01 Apr 2016, at 09:49, Andrew Haley <aph at redhat.com> wrote:
> 
> On 31/03/16 22:14, Dohrmann, Steve wrote:
> 
>> This is a JDK 9 proposal to support allocation of direct
>> java.nio.ByteBuffer instances backed by memory other than off-heap
>> RAM.
> 
> I must be missing something.  How is this different from exposing
> special memory via the filesystem and mapping a file?
> 
> Andrew.
>