Reading binary data

[Samuel Audet]

Hi, Maurizio,

We do need /something/ to replace sun.misc.Unsafe, so that's welcome, 
but I'm concerned about it not actually being able to do the job. If I 
understand correctly, it is not possible to create a MemorySegment 
directly from an arbitrary long integer: We need to work around that 
with Pointer. (Or did I miss a piece of the API somewhere?) However, if 
I understand correctly, MemorySegment is scheduled to be released before 
Pointer, which again, if I understand correctly, might not be for a few 
more years. If that's the case, what are users meant to do in meantime?

Samuel

On 10/31/19 8:55 AM, Maurizio Cimadamore wrote:
> 
> On 30/10/2019 20:29, Ty Young wrote:
>> As an API user I would much rather have the APIs being integrated with 
>> one another rather than completely separate APIs. Spending hours 
>> trying to figure out how to read the data -only to use the incorrect 
>> way that seems to return a valid value but in actuality isn't- isn't 
>> going to be fun. 
> 
> I think there is a misunderstanding here on what these API are meant to be.
> 
> The memory access API is a low level API, it sits in the 
> foreign-memaccess branch; that's what my talk (which you might have seen 
> on youtube) speak about. It's meant to be a general off-heap API, with 
> focus on safety and performances - kind of a replacement for 
> Unsafe::get/putInt and friends.
> 
> The Pointer API is what's available in the 'foreign' branch - and does 
> what it says on the tin: it provides a Java abstraction which models a C 
> source pointer type. The Pointer API is for language interop; the memory 
> access API is lower level (in fact you can build the Pointer API on top 
> of the memory access API).
> 
> I'm sorry to hear your frustration in using the API (I assume the 
> Pointer API?) but w/o understanding more of what you are trying to do, 
> it's gonna be hard for us to offer any help or guidance.
> 
> Cheers
> Maurizio
>