Foreign memory access with classes

[Red IO]

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.
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.
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.

Regards
RedIODev

On Tue, Nov 8, 2022, 11:44 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I believe adding Java syntax to model objects backed by memory segments
> might be pushing things a little too far. From a pedagogical perspective
> you would now have to explain to _every_ Java developers that there are
> two different kinds of objects, plain and native, and the rules which
> govern their access would be different (plain objects are
> garbage-collected, native objects are not).
>
> Seems like a nightmare, for a relatively little pay off. Note that, if
> you declare a record class with components X and Y, it is relatively
> easy to construct a function that can read a segment, with given struct
> layout into a record with matching components. I believe JPassport [1]
> does something in this direction. With something like this you get
> basically 90% of what you are aiming for, without the need to change the
> language by adding a new keyword, and making the programming model more
> complex for all the developers out there, including those who do not
> care about off-heap access.
>
> Cheers
> Maurizio
>
> [1] - https://github.com/boulder-on/JPassport/
>
>
> On 08/11/2022 06:52, Red IO wrote:
> > I just had a crazy idea on how to make foreign memory access work and
> > feel like java native class member access.
> > The idea is that you define special classes maybe with an interface or
> > a special class keyword. This class can then be "constructed" using a
> > MemorySegment being bound by its special and temporal bounds. The
> > object would be either null or every memory access throws an exception
> > when the bounds are breached. The class would be implicitly final and
> > would extend a class Native.
> > This could look something like this :
> >
> > //c struct
> > typedef struct {
> > int x;
> > int y;
> > } Point;
> >
> > //java native class
> > public native class Point {
> >
> > int x;
> > int y;
> >
> > //implicit and forced private constructor
> > //normal creation would make things difficult
> > }
> >
> > MemorySegment data =... //native memory
> > Point p = data.object(Point.class);
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221108/c0bb07f7/attachment.htm>