Java 7 is adding dynamics

I think these dynamic features are actually intended for alternative JVM languages.

If they're exposed via the Java reflection API at all, it's incidental to their actual purpose.

> With that new bytecode keyword, we can call method only known at runtime.

I don't know much about Java, but it sounds like they're extending the bytecode to better support those alternate languages which currently are sort of hack-ish.

I have not played with Clojure since it was introduced, but I have a question about recur or tail recursion. Here is a trivial CL example (nontrivial might be approaches to parsing):

  (defun find-nth-match (test from n)
    (if (= n 0)
        from
        (martial-n test (1+ from) n)))
  
  (defun martial-n (test from n)
    (find-nth-match test
                    from
                    (if (funcall test from) (1- n) n)))
  
  (find-nth-match #'evenp 1 5)  => 10

The idea is that tail recursion is not just recursing into the exact same function you appear to be in. Is this available with current clojure? Can recur help me somehow?

One time Guy Steele was speaking at my school, and a professor asked him about why Java did not have tail recursion, and Steele said it was something he'd lobbied for but wasn't able to make it in the final spec.

Tail-call optimization is part of the Da Vinci project. I have no idea if it's on track for Java 7.

http://openjdk.java.net/projects/mlvm/subprojects.html#TailC...

I'm guessing invokeinterface is a synonym for invokevirtual.

There are four:

static for static methods

special for constructors I think

virtual for class methods

interface for interface methods (since its harder to find where an interface method is defined, its different to virtual)

invokestatic is used for invocation of static methods, where there's no "this" pointer on the stack. By definition those calls are also statically dispatched. invokespecial is to statically-dispatch a call to a virtual method, and is used both for constructor invocation (the construct is implicitly a method named "<init>") and also any time you call super.foo(), since you're explicitly specifying the target method and wouldn't want that call to dynamically dispatch back down to your subclass. invokevirtual and invokeinterface both dynamically dispatch instance method invocations; invokevirtual is used for method calls to a concrete type while invokeinterface is used for calls to interface methods. The primary difference is performance-related: invokevirtual can be more heavily optimized because it's a call to a known class or one of its subclasses, so the VM can do things like store the vtable offset for the method. invokeinterface is invoking the method on some unknown object every time, so it has to be looked up each time (though technically if it's always the same implementation, in practice invokeinterface should be about as fast, since you'll just end up with a guard clause and then a direct invocation of the actual target method). For purposes of a method handle invocation, I'd imagine that invokevirtual and invokeinterface should behave the same, i.e. they just dynamically dispatch.

Currently the Method object in Java always does dynamic dispatch for instance methods and static invocation for static methods, and there's no way to do mimic invokespecial via it.