Opened 7 years ago

Closed 7 years ago

#347 closed defect (wontfix)

Java FFI conversion of arrays is inconsistent between call and return types

Reported by: Mark Evenson Owned by:
Priority: major Milestone: 1.3.0
Component: interpreter Version: 1.3.0-dev
Keywords: Cc:
Parent Tickets:

Description (last modified by Mark Evenson)

In, Cyrus notes that:

I am trying to connect ABCL up with some java code that uses multidimensional arrays of the form:

        int[][] theArray = new int[4][4];

The problem is that when I call this code I get something like this in return:

	#(#<jarray [I <at> 2d983837 {6492BA43}> #<jarray [I <at> 5d02b84a {5D9131FA}> #<jarray [I <at> 67684413
{6E4D706E}> #<jarray [I <at> 1e107e55 {4CD60DDE}>) 

that is a lisp array that contains 4 java arrays. I can’t pass this off to a method like this:

    static public int[][] arrayTest2(int[][] oldArray) {

Attachments (1)

jarray-convert.diff (1.0 KB) - added by Mark Evenson 7 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 7 years ago by Mark Evenson

Description: modified (diff)

comment:2 Changed 7 years ago by Mark Evenson

This behavior certainly seems wrong given that for class:

public class Array {
  public static int[][] getMultiDimensional() {
    return new int[4][4];
  public static int[][] returnRef(int[][] ref) {
    return ref;

Compiled with javac, (java:add-to-classpath “~/directory/“), then the following

CL-USER> (java:jnew-array "int" 4 4)
#<jarray [[I@2e9e32cc {141906FD}>
CL-USER> (jstatic "returnRef" "Array" *)
#(#<jarray [I@4147aa25 {47F3849E}> #<jarray [I@4487c5f9 {2DD68195}>
  #<jarray [I@5dd574b5 {68E14733}> #<jarray [I@1e099b10 {8A346D8}>)

shows that we are clearly getting a different sort of Lisp object than we pass into the Java FFI for what should be a symmetric reflection.

Changed 7 years ago by Mark Evenson

Attachment: jarray-convert.diff added

comment:3 Changed 7 years ago by Mark Evenson

Patch to test ramifications of not converting multi-dimensional arrays added.

comment:4 Changed 7 years ago by Mark Evenson

Resolution: wontfix
Status: newclosed

Closing as "wontfix" 'cuz it isn't broken.

Users who want the unadorned, non-translated result from a call info the Java Function Interface should use the JAVA:*-RAW or JSS's #0"*" methods.

Note: See TracTickets for help on using tickets.