On Dec 13, 2019, at 20:14, somewhat-functional-programmer somewhat-functional-programmer@protonmail.com wrote:
I've looked into this issue at length now and I think I have something worth discussing and potentially trying[0] . The root issue here lies in how ABCL converts its CL representation of integers to Java, as well as its conversion of Java primitives to other Java primitives.
[…]
What are your thoughts? I dislike backwards incompatible changes like this, but I think the impact is probably low due to the fact that method resolution used rules to only find widening conversions, and the fact that short and byte are not as commonly used in method calls.
After much study, reflection and experimentation, I have decided that I didn't like the incompatible change introduced by this patch in requiring Lisp code to explictly JCOERCE arguments to find Java call sites.
Instead, I [managed to solve the original poster's problems of not being able to call Java methods whose parameters where short or byte][1] by modifying the Java.findMethod() machinery to use the actual arguments that will be used in the call for a decision whether to narrow types for calling a given function makes sense for short or int types. I was unable to find other problems with converting primitive types.
[With a little additional elbow grease][2] , I was able to also code a [fix for finding call-sites][3] that take a varargs parameter such as
java.util.Arrays.asList(T... arg)
[1]: https://github.com/armedbear/abcl/pull/144/commits/bfa6e9e44f854ca0c175e73e358d307a7507eeda [2]: https://github.com/armedbear/abcl/pull/144/commits/9fb39d2c0e445bf45739a4f7bb25938ea23f8b5a [3]: https://abcl.org/trac/ticket/259
Given the major holes pointed out by the someone-functional-programmers examination of of the narrowing/widening convention, I am surprised that there are not more Java calls that can't be made with our current FFI machinery, but after scouring our bug reports and trying various methods I can't find any examples. If anyone knows of a case of the Java FFI not finding call sites with these patches, please pipe up.
--
While reviewing this patch, I noticed that since one can't use CL:COERCE to perform a conversion that loses information, as
(coerce 256 '(unsigned-byte 8))
signals some sort of error for all existing Lisp implementations (SBCL, CCL, ECL, CLISP, Allegro, LispWorks), therefore I would argue that something like
(jcoerce 256 "byte")
should also signal an error. Therefore, JCOERCE should be reworked to signal some sort of error if the conversion would lose information. I continue to work through what we would be needed to both incoporate somewhat-functional-programmer's patch, which allows things like
(jcoerce 2.4 "float")
to work, but that would signal TYPE-ERROR conditions when JCOERCE call that lose information are attempted.
My current inclination would be to release the current state as abcl-1.6.1 without incorporating this patch, as I think the need to [patch ABCL-ASDF's inablity to download Maven artifacts][4] is much more pressing than untangling the incomplete inconsistencies in JCOERCE.
[4]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-February/0040...