views:

175

answers:

2

For this example Java class:

package foo;
public class TestInterop
{   public String test(int i)
    { return "Test(int)"; }

    public String test(Object i)
    { return "Test(Object)"; }
}

When I start Clojure and try to call the test(int) method, the test(Object) method is called instead, because Clojure automatically boxes the integer into a java.lang.Integer object.

How do I force Clojure to call the test(int) method?

user=> (.test (new foo.TestInterop) 10)
"Test(Object)"

I want to call methods like Component.add(Component comp, int index) in AWT, but instead keep calling add(Component comp, Object constraints), so the buttons on my toolbar always appear in the wrong order.

+8  A: 
user=> (.test (foo.TestInterop.) 10)
"Test(Object)"
user=> (.test (foo.TestInterop.) (int 10))
"Test(int)"

Numbers in Clojure are generally boxed (int => Integer) unless you specifically ask for primitives.

Here is more information about primitives in Clojure.

Brian Carper
That's great. Thanks very much.
Pat Wallace
+5  A: 

A discussion is going on in the #clojure channel on Freenode just now on this very topic. Chris Houser (who was going to post an answer, but ultimately decided he was too busy to do it) has posted a Gist which demonstrates what happens with a boolean vs. Object overloaded method; it turns out that in some scenarios, in addition to a (boolean ...) cast, a type hint is required. The discussion was quite enlightening, with a few dark corners of Clojure compilation process becoming nicely illuminated. (See links to IRC log below.)

Basically, if an object is created right in the method-calling form -- (.foo (Foo.) ...), say -- that type hint is not necessary; it is likewise not necessary if the object has been constructed as a value for a local in an enclosing let form (see update 2 below and my version of the Gist). If the object is obtained by Var lookup, though, a type hint is required -- which can be provided either on the Var itself or, at the call site, on the symbol used to refer to the Var.

The Java code from the Gist:

package mypkg;

public class Ugly {
    public Ugly(){}
    public String foo(boolean i) { return "bool: " + i; }
    public String foo(Object o) { return "obj: " + o; }
}

And the Clojure code:

(.foo (mypkg.Ugly.) 5)
;=> "obj: 5"

(.foo (mypkg.Ugly.) true)
;=> "obj: true"

(.foo (mypkg.Ugly.) (boolean true))
;=> "bool: true"


(def u (mypkg.Ugly.))
(.foo u (boolean true))
;=> "obj: true"

(.foo #^mypkg.Ugly u (boolean true))
;=> "bool: true"

Note how the Clojure compiler needs a type hint on u to be able to compile a direct method call. Otherwise reflection-based code seems to be generated, which apparently loses track of the fact that the argument is meant to be a primitive along the way.

My additions follow (and here's my fork of the above Gist).

;; renamed mypkg.Ugly to foo.TestInterop2 when doing my tests
user> (let [t (foo.TestInterop2.)]
        (.foo t (boolean true)))
"bool: true"

;;; type-hinting the Var
user> (def #^foo.TestInterop2 x (foo.TestInterop2.))
#'user/x
user> (.foo x (boolean true))
"bool: true"

The topic was first brought up at this point. Chouser posted the Gist half an hour later, with the discussion becoming more and more interesting after that.

Michał Marczyk
That explains why it was always working in the test programs and not in the real program. I put in the type hint on the call, and it's now working fine. Thanks very much.I had a shot at making a macro for this, since you can get the class from the variable, but it looks like the type hints don't macro-ise.
Pat Wallace
Happy to hear that! Oh, and actually it is possible to handle type hints in macros -- and sometimes a well-designed macro can produce nicely hinted code with minimal extra typing. You could post a separate question on that if you'd like some help with writing one.
Michał Marczyk