[armedbear-devel] Question about calling Java

[dmiles@users.sourceforge.net]

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

> On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen
> <ville.voutilainen at gmail.com> wrote:
> > On 4 February 2010 16:39, Axel Rauschmayer <axel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20100204/c1bcb29f/attachment.html>