As part of feedback on the Foreign Memory API (when experimenting with its usage internally in the JDK), a small number of potential usability enhancements could be made to the API. This is the third such.
This change proposes to add a new method:
When dealing with unsigned native data types it is often convenient to model them as
To model this, I found myself reaching for
A single static adapter factory,
We don't necessarily need to, or can, support all combinations, but there seems to be a sweet spot where Java longs and ints can be used to model unsigned char, unsigned short, and unsigned int,  which covers the majority of the use-cases. This also seems to align nicely with the primitive wrapper unsigned widening methods, e.g.
I started this discussion as a PR so that hopefully the code changes can help convey the idea and inform readers.
I don't think the source code generation is really needed. It seems like it should be enough to have a set of TO/FROM MethodHandles for each adaptation, and then have the if/else in
Also, the whole implementation could be put in the MemoryHandles class. We do this for
I think the decisions in your document are sound. One point which is perhaps not stated clearly (but which we have discussed) was also the fact that
After looking at the code some more, I agree with Jorn that the templating is perhaps unnecessary. We can go from byte/short/int to wider type using the unsigned helpers on the wrapper types. And we can go reverse by using
So I think there's a way for the code to set up some kind of table, and then just pick the adapter MHs from there. I think this will simplify the code quite a bit and remove the
The templating was cute when I started, but as rows in the table were eliminated it no longer carries its own weight. This update removes the templating. I decided to keep the implementation in its own class for now, so that we can see if we really want to merge it into MemoryHandles. Most of the implementation is not really sharable with other parts of MemoryHandles.
The templating was cute when I started, but as rows in the table were eliminated it no longer carries its own weight.
This update removes the templating. I decided to keep the implementation in its own class for now, so that we can see if we really want to merge it into MemoryHandles. Most of the implementation is not really sharable with other parts of MemoryHandles.
@ChrisHegarty This change now passes all automated pre-integration checks, type
Since the source branch of this PR was last updated there have been 2 commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge
As you do not have Committer status in this project, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mcimadamore, @JornVernee) but any other Committer may sponsor as well.
Your commit was automatically rebased without conflicts.
Pushed as commit 3193db4.