High-level interface about javacall.jl HOT 5 OPEN

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.

from javacall.jl.

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.

from javacall.jl.

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

from javacall.jl.

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

from javacall.jl.

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.

from javacall.jl.