Don't convert Arrays and Strings automatically about javacall.jl HOT 10 CLOSED

Funny, I was thinking about this last night.

I think for many uses, it is really really convenient to automatically convert the type. It will be really messy to litter your code with convert calls. However, as you say, in some cases, you really don't want to copy/convert.

The way PyCall handles this is to say (effectively) :methodName will convert, but "methodName" will return a wrapped handle. Maybe that will work here as well? Open to other ideas as well.

Wrapping array's is not that big a deal, I feel. We can easily do a JavaArray object to wrap a raw java array. That and a couple of convert method should be all we need. But its this design question of when to convert and when not that is the difficult bit.

Paging @stevengj for any thoughts on designing this kind of functionality.

from javacall.jl.

What if we decide to convert or not to convert based on provided type? E.g.:

# Julia type in jcall specification - do autoconversion
arr = jcall(my_obj, "createVeryBigArray", Array{Int, 1}, ())
jcall(my_other_obj, "doStuffWithBigArray", Void, (Array{Int, 1},), arr)

# JavaObject{T} type in jcall specification - don't convert, work via pointers instead
@jimport JArray org.javacall.JavaArray
arr = jcall(my_obj, "createVeryBigArray", JArray, ())
jcall(my_other_obj, "doStuffWithBigArray", Void, (JArray,), arr)

In this case user will be able to select conversion rules with no additional code and get exactly what requested (Array or JArray in this code).

from javacall.jl.

Can arrays be shared without copying?

from javacall.jl.

Can arrays be shared without copying?

I assume you mean Java. Though arrays don't have their class name, they are objects, so you can have 2 references to exactly the same location in memory. If you mean subarrays (reference to the part of an array), then I don't know any standard API to get it (though custom classes can do it, of course).

from javacall.jl.

@dfdx I need the expected Java return type, so that I can read the return value correctly. So the provided type has to be the Java type. Unless I keep a mapping of which Julia types can go with what Java type. That sounds like a very error prone API to me.

@stevengj Do you mean between Julia and Java? Yes, I suppose that is theoretically possible. I'll have to look into it to confirm, but i expect the difficulty will be in ensuring the element types get converted correctly.

from javacall.jl.

@aviks, presumably 1d arrays of basic types like Int64 or Float64 are stored identically in Julia and Java; there is only one sensible binary format for something like this. Multidimensional arrays seem more problematic since Java does not seem to have multidimensional arrays (as opposed to arrays of arrays).

from javacall.jl.

I need the expected Java return type, so that I can read the return value correctly. So the provided type has to be the Java type. Unless I keep a mapping of which Julia types can go with what Java type. That sounds like a very error prone API to me.

Currently API is inconsistent. Take an example:

...
# for strings we pass Java type alias - JString
julia> jcall(JString("test"), "toString", JString, ())
"test"

# Julia's String is not recognizable currently
julia> jcall(JString("test"), "toString", String, ())
ERROR: `write` has no method matching write(::IOBuffer, ::Nothing)
 in write at io.jl:32
 in method_signature at /home/<username>/.julia/v0.3/JavaCall/src/JavaCall.jl:447
 in jcall at /home/<username>/.julia/v0.3/JavaCall/src/JavaCall.jl:271

# but for arrays we pass Julia type, not Java one
julia> jcall(JString("test"), "getBytes", Array{jbyte, 1}, ())
4-element Array{Int8,1}:
 116
 101
 115
 116

So if we provide array wrapper, how should it behave? For me it sounds intuitive, that when return type is Java one, jcall should return pointer to Java object, but when passed Julia type, result should be automatically converted to corresponding Julia object. At least for strings and arrays.

Probably there's even better and/or more intuitive way to do it, but provided that we will have String, JString, Array and a kind of JArray, it will be really nice to have them all behave consistently.

from javacall.jl.

Just found interesting use case. In Spark's RDD class there's a method collect() defined as follows in Scala:

def collect(): Array[T]

Scala's Array[T] is a wrapper for Java's T[], and when called from Java or through JNI, this method returns normal Java array. However, because of some Scala's compilation magic or whatover, JNI's signature for this method is:

Object collect()

That is, it returns JObject, not array. Accordingly, the way to call this method via JavaCall is:

jcall(rdd, "collect", JObject, ())

Thus result is not automatically converted into Julia's Array{T,1} and we need to do this conversion manually after getting the result.

I'll try to submit appropriate convert() function soon, but I expect more corner cases like this in the future.

from javacall.jl.

Is there anything left to do here or is the issue resolved?

from javacall.jl.

It's hard to get back into the context of this issue, but since it hasn't been updated for 5 years I believe we can close it as inactive.

from javacall.jl.