4 ms·

Java 7 is adding dynamics

51 points by alrex021 17y ago

unwind 17y ago
"There are three supported invocations modes : invokestatic, invokespecial, invokeinterface or invokevirtual." So ... Are there four, or is one very much like another?
- sid0 17y ago
  I'm guessing invokeinterface is a synonym for invokevirtual.
- Robin_Message 17y ago
  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)
- akeefer 17y ago
  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.
ldh 17y ago
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());
- Periodic 17y ago
  > 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.
- lukev 17y ago
  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.
  - jimbokun 17y ago
    I think they could also be useful in creating little DSLs, building parser combinators, etc.
drunkpotato 17y ago
Any word on tail-call optimization? Clojure's recur macro is pretty clever but true compiler-level support for recursion would be nice.
- Xurinos 17y ago
  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?
  - rarrrrrr 17y ago
    For mutual recursion, you need to use trampoline. http://groups.google.com/group/clojure/browse_frm/thread/6257cbc4454bcb85/7d5fd827cd549080#7d5fd827cd549080 http://groups.google.com/group/clojure/browse_frm/thread/625...
  - cgrand-net 17y ago
    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.
- dangrover 17y ago
  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.
- papercrane 17y ago
  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#TailCall http://openjdk.java.net/projects/mlvm/subprojects.html#TailC...

51 points by alrex021 17y ago

"There are three supported invocations modes : invokestatic, invokespecial, invokeinterface or invokevirtual." So ... Are there four, or is one very much like another?

sid0 17y ago
I'm guessing invokeinterface is a synonym for invokevirtual.
Robin_Message 17y ago
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)
akeefer 17y ago
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.

ldh 17y ago

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());

Periodic 17y ago
> 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.
lukev 17y ago
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.
- jimbokun 17y ago
  I think they could also be useful in creating little DSLs, building parser combinators, etc.

drunkpotato 17y ago

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

Xurinos 17y ago
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?
- rarrrrrr 17y ago
  For mutual recursion, you need to use trampoline. http://groups.google.com/group/clojure/browse_frm/thread/6257cbc4454bcb85/7d5fd827cd549080#7d5fd827cd549080 http://groups.google.com/group/clojure/browse_frm/thread/625...
- cgrand-net 17y ago
  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.
dangrover 17y ago
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.
papercrane 17y ago
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#TailCall http://openjdk.java.net/projects/mlvm/subprojects.html#TailC...