[foreign] Improve error reporting when Java signature and native function layout don't match.

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Sep 26 19:54:46 UTC 2018

Looks very good, thanks for fixing the javadoc too.

I will prepare an RFR for this too (probably tomorrow).


On 26/09/18 18:31, Jorn Vernee wrote:
> Maurizio Cimadamore schreef op 2018-09-26 17:49:
>>> I also made it so that `nullPointer()` takes a LayoutType, so that a 
>>> method returning e.g. `Pointer<Integer>` doesn't suddenly have a 
>>> LayoutType with a Void carrier. Seeing the References.ofVoid 
>>> anonymous class in the stack trace was also a source of confusion 
>>> for me.
>> Not sure you need to add a parameter to nullPointer for that. I think
>> there should be only one null pointer, and we should use unchecked
>> conversion internally to cast it to the type the user wants -
>> dynamically the carrier will not be used - since the Reference
>> attached to that will prevent dereference ops.
> Yeah, you're right, it wasn't needed in the end [1]. I did create a 
> BoundedPointer.nullPointer() as well so I wouldn't have to make the 
> LayoutTypeImpl constructor public. That also allowed me to simplify 
> the type variable declaration, since the one place that needed a null 
> BoundedPointer can now just call BoundedPointer.nullPointer().
> I also removed the type parameter from the carrier field in 
> LayoutTypeImpl, since it didn't really seem to be used, as 
> LayoutTypeImpl.carrier() just returned a Class<?>. That allowed me to 
> avoid doing an unchecked cast in BoundedPointer.nullPointer().
> Jorn
> [1] : https://gist.github.com/JornVernee/7727db9b8ebdbb5c88205e3bbe97227c

More information about the panama-dev mailing list