[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).
Maurizio
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