On Thu, Feb 4, 2010 at 7:19 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:

On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen

<ville.voutilainen@gmail.com> wrote:

> On 4 February 2010 16:39, Axel Rauschmayer <axel@rauschma.de> wrote:
>> Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required:
>> (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg)
>> (jcall "methodName" obj arg) for obj.methodName(arg)
>
> Does it allow both the "old" way and the stringified way?

Yes, it does. The stringified way is obviously slower, because it
looks up the method at runtime.

So you are saying in the current interpreted mode it has to resolve the stringified method each time?

So it would be fastest to:

(setq *myjmethod* (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") ))

Then use (jcall *myjmethod* obj arg). Is the most effecient?

instead of

(jcall (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") ) obj arg)

In the future, (JLinker says in their future to so no hurry) that these forms will eventualy be bytecode.

And ABCL will probably beat Allegro to it!

Since we can use Hickey's methodolgy he used in clojure for finality of the bytecode methods.

That the methods themselves wont ever need to use a java.lang.Method.invoke anymore unless the user left it too ambiguous.