While I'm really glad to see Java (the language) slowly evolving in a positive direction, and it might bring me some joy at work if/when we switch to 7, I can't imagine starting new projects in Java anymore if I had my way. Once you've been exposed to the much nicer languages thriving on the JVM now, it's hard to get excited about Java anymore.

I mean, I can't see this sort of thing as being very enjoyable to write all the time.

  JComboBox combo = new JComboBox();
 
  MethodHandle handle = MethodHandles.lookup().findVirtual(JComboBox.class, "setModel", MethodType.make(void.class, ComboBoxModel.class));
 
  handle.invoke(combo, new CustomComboModel());

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.

I think they could also be useful in creating little DSLs, building parser combinators, etc.

> 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.

Any word on tail-call optimization? Clojure's recur macro is pretty clever but true compiler-level support for recursion would be nice.

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?

No recur won't help you: it's only for self tail recursion, not for mutual tail-recursive calls. You can use a trampoline or refactor your code.

For mutual recursion, you need to use trampoline.

http://groups.google.com/group/clojure/browse_frm/thread/625...

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...

    "There are three supported invocations modes :
    invokestatic, invokespecial, invokeinterface or 
    invokevirtual."

So ... Are there four, or is one very much like another?

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.

I'm guessing invokeinterface is a synonym for invokevirtual.