<div dir="auto">JPassport looks like a great take based on the raw Panama way of doing this. But it's still a pain to do and requires a precompiler. But both feel uncomfortable using strings to point to mark things.<div dir="auto">Also my idea would still bahave like a normal class being on the heap (could be declared as primitive or value class but let's not focus on Valhalla). The only difference would be their fields, as they would technically not be part of the class. The only field part of the object would be the hidden MemorySegment managing the access of the fields.</div><div dir="auto">My biggest problem with the current solution is that they try to simulate a simple struct with a complex factory. I understand your concerns but there is no split in the type system like you feared. Native objects are simply different, that their fields are stored somewhere else. Other than that they are plain objects. If projecting method calls from fields is too complicated to implement we could go for a record like syntax and only exposing the fake fields through methods. Most java developers would probably never create their own native classes but use those declared in libraries and returned by library methods. In this scenario they would be indistinguishable from normal objects.</div><div dir="auto"><br></div><div dir="auto">Regards </div><div dir="auto">RedIODev</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 8, 2022, 11:44 Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe adding Java syntax to model objects backed by memory segments <br>
might be pushing things a little too far. From a pedagogical perspective <br>
you would now have to explain to _every_ Java developers that there are <br>
two different kinds of objects, plain and native, and the rules which <br>
govern their access would be different (plain objects are <br>
garbage-collected, native objects are not).<br>
<br>
Seems like a nightmare, for a relatively little pay off. Note that, if <br>
you declare a record class with components X and Y, it is relatively <br>
easy to construct a function that can read a segment, with given struct <br>
layout into a record with matching components. I believe JPassport [1] <br>
does something in this direction. With something like this you get <br>
basically 90% of what you are aiming for, without the need to change the <br>
language by adding a new keyword, and making the programming model more <br>
complex for all the developers out there, including those who do not <br>
care about off-heap access.<br>
<br>
Cheers<br>
Maurizio<br>
<br>
[1] - <a href="https://github.com/boulder-on/JPassport/" rel="noreferrer noreferrer" target="_blank">https://github.com/boulder-on/JPassport/</a><br>
<br>
<br>
On 08/11/2022 06:52, Red IO wrote:<br>
> I just had a crazy idea on how to make foreign memory access work and <br>
> feel like java native class member access.<br>
> The idea is that you define special classes maybe with an interface or <br>
> a special class keyword. This class can then be "constructed" using a <br>
> MemorySegment being bound by its special and temporal bounds. The <br>
> object would be either null or every memory access throws an exception <br>
> when the bounds are breached. The class would be implicitly final and <br>
> would extend a class Native.<br>
> This could look something like this :<br>
><br>
> //c struct<br>
> typedef struct {<br>
> int x;<br>
> int y;<br>
> } Point;<br>
><br>
> //java native class<br>
> public native class Point {<br>
><br>
> int x;<br>
> int y;<br>
><br>
> //implicit and forced private constructor<br>
> //normal creation would make things difficult<br>
> }<br>
><br>
> MemorySegment data =... //native memory<br>
> Point p = data.object(Point.class);<br>
><br>
</blockquote></div>