Support typemap chasing for autoboxing jtype. #2061
Conversation
|
It would be great to have a test checking for this to ensure that this not only works now, but remains working in the future. TIA! |
|
As well as test coverage, this really needs documentation. |
|
I don't really understand the motivation for this change without documentation and motivating examples. We can re-open if the comments are addressed. |
|
This is part of a framework for being able to automatically handle container types, e.g. VECTOR(T) causes std::vector to convert to java.util.List<jstype(T)> if appropriate typemaps for T are defined. Obviously, special handling is needed for primitive T, and this pull request was part of that. This is all fully working on Google's internal fork, but I haven't finished upstreaming it. Fully upstreaming is complicated because it uses some internal helper libraries; this was one of the separable parts. |
|
Is this fork publicly available by chance? I'd be quite interested in using something like this in my own fork. |
|
Not presently. I would like to upstream it here when I have time. |
|
Please do provide the missing info. I've reopened as I think I understand the motivation for the typemap.c change now, that is, you having a And please do upstream any other improvements in your fork. |
Also define jniboxtype typemaps.
This allows expressions such as $typemap(jniboxtype, $typemap(jni, CppType)) to be resolved, which is necessary for properly handling autoboxing of jtype. In general this expression is castable to jtype but is always an object. This is part of the composing typemaps effort.
This is harder than the existing jboxtype, because while that corresponds to jstype and jstype will (mostly) be primitive if and only if the CppType is primitive, it's much more common for jtype to be primitive when the CppType is not.
Even though we want to autobox jtype, this logic is based on the jni typemap instead because typemaps want C++ types, not strings, as their keys.