High-level interface

[dfdx]

Not that I expect this issue to be resolved anytime soon, but I thought it would be nice to write down ideas to have something to start with.

In a perfect world I'd like to use JavaCall something like this:

@java foo = new Foo()
@java foo.doStuff("hello").doAnotherStuff()
@java foo.bar

Or even like this:

@java begin
    foo = new Foo()
    foo.doStuff("hello").doAnotherStuff()
    foo.bar
end

A bit closer target may be to implement something like this (i.e. call only one method of one object):

@jcall foo.doStuff("hello")

The problem with such syntax is that it lacks several bits of required information:

jcall(foo, "doStuff", <what return type?>, (<what argument types?>,), "hello")

One way to fix issue with return type is to add them explicitly, similar to Java syntax:

@jcall JString result = foo.doStuff("hello")

Looks quite weird, but may work. However, it's still unclear how to pass argument types. Note, that jcall requires argument types from the method signature which may be parent types of actual arguments, e.g.:

jcall(foo, "doStuff", <what return type?>, (JObject,), "hello")

The best syntax that comes to mind is:

@jcall JString result = foo.doStuff("hello"::JObject)

Or a bit simpler:

@jcall JString obj.doStuff("hello"::JObject)

---

Another option is to use reflection to infer unknown parameters. Here we have 2 options:

1. Using macros, generate code that performs reflection during run-time. Easy to implement, but reflection will slow down every call.
2. Using generated functions, do all the reflection during compile-time and produce pure jcall.

Second option looks attractive, but I have a little experience with generated functions and I'm not sure this will work.

[aviks]

So when I had thought about this earlier, my idea was to use reflection (and some heuristics) to infer the argument types (and thus the exact method), but then cache the results of the reflection. In my experience, most java code that use reflection heavily always cache the results, given how slow it is. So that could be one option. I believe that is how the python-java interface works.

I'll have a think about the syntax. My criteria are somewhat contradictory, to reduce the cognitive overhead for both the java and the julia developer.

[dfdx]

Caching results from reflection API sounds promising! I also have some progress on a generated functions approach in high-level-macro branch, but still not sure this will work well in practice.

[kcajf]

Could the dot syntax / auto-completion be handled by the getfield and fieldnames methods added in Julia 1.0?

[aviks]

Yes, that's the idea. It's just that we've not had the time to implement this.

[mkitti]

I wanted to propose a roadmap for this since there are multiple proposals on the table.

My vision for the JavaCall package is to provide a solid foundation that takes care of most of the low level interface of the JNI and provides a Julian method of calling Java. We should be able to do a few things like inferring or automatically importing the return type.

For some of the examples above, I would like to point out that the below is not really Java. You could not compile that with javac.

@java begin
    foo = new Foo()
    foo.doStuff("hello").doAnotherStuff()
    foo.bar
end

It would be closer to something like Groovy. My proposal to support that would be a GroovyCall.jl package which would depend on JavaCall.jl. In that case, we let Groovy handle the syntax parsing.

What to expect:

1. Limited support in JavaCall.jl to make calling Java methods easier. It is reasonable to infer the return type given the argument types, for example.
2. A series of packages built upon JavaCall.jl that supports higher level syntax via Groovy, etc.