Comments on Headius: InvokeDynamic: Actually Useful?

In reply to John (Catherino), As I see it, the ma...

2007-01-16T19:47:00.000-06:00

In reply to John (Catherino),

As I see it, the main advantage is that every language that wants to call a (Java) method given only an Object, method name, and Object[] of arguments doesn't have to implement thier own version of your "findBestMethod"

Of course, this could easily be solved by extending java.lang.Class or java.lang.Object with an appropriate getMethod

Well said, Nico. I think dynamic invoke needs (1)...

2007-01-10T20:00:00.000-06:00

Well said, Nico.

I think dynamic invoke needs (1) to look enough like other JVM invokes that the compiler can optimize it, (2) to be able to directly call Java methods when they are there to call, (3) to have a flexible MOP "hook" for cases where there's an API mismatch, (4) to support some sorts of per-call-site caching hacks, and (5) to avoid barriers to cross-language interoperability.

The following design aims at these goals:
http://blogs.sun.com/jrose/entry/autonomous_methods_for_the_jvm

It does this by partially decoupling methods from classes in the JVM.

"And that requires calling Java code from Ruby and...

2007-01-08T13:55:00.000-06:00

"And that requires calling Java code from Ruby and Ruby code from Java with as little complexity and overhead as possible."

That's the crux of it. You _can_ host Ruby, or Scheme, or what have you, in the JVM, but if you want to be able to freely refer to objects from Java or the hosted language in the other, then you need JVM support. For example: no closures? no problem, just treat functions/closures as instances of a class specific to the hosted language and provide your own calling conventions -- but then the Java compiler won't know those conventions and won't recognize those objects as funcallable. Similarly for continuations: implement closures, implement CPS conversion, lambda lifting, done -- but again, there will be some severe restrictions in interfacing with Java.

Now, invokedynamic with methods that return Object and take Object as arguments plus anonymous methods would be sufficient, I think, to implement method dispatch above the JVM and have something very close to open classes (add an unknown method call feature, as you noted, and you have pretty much all you need to implement open classes). And the resulting calling convention would be understood by Java compilers, so that would be very good. Of course, the trade-off is that you'd be implementing method dispatch in JVM bytecodes, so you'd be taking some sort of perf hit there; otoh perhaps you could take advantage of this to better optimize method dispatch at runtime, since you could potentially replace the method dispatch code at runtime.

Rick: Is it really? Yet Java platform exists over ...

2007-01-06T18:07:00.000-06:00

Rick: Is it really? Yet Java platform exists over 10 years, is successful like no platform before and it's been at least unfriendly (not to say hostile) to other languages. Not only wasn't it killed but is the first platform of choice, guess why?

Maybe Java doesn't satisfy you language purists and you find it's OO model broken and it's syntax bloated, but is not of any signoficance.

Some OO purity has been given up and primitives added, yes, but that allows to implement some protocols which are very fast now and can be worked with almost on the wire since they are machine word aligned. If they were boxed you'd have 31-bit integers or some other strange size and giving no real gain but making things more difficult.

Making syntax verbose by requiring all things be declared is also a positive thing because it makes more information available, not only to the compiler but to other developers and code maintenance guys as well - which is more important. (That's why I despise static type inference like e.g. D has - maybe the compiler has all the information it needs to know exactly the type to use but the human reading code a few months later surely does not.) That means more maintainable code and thus less pains and better programs.

In fact, on a project I currently work for we decided that no method invocations may be chained, so people are not allowed to write:

Type1 obj1 = obj2.method1().method2();

but instead they have to write:

Type3 obj3 = obj2.method1();
Type1 obj1 = obj3.method2();

and of course they have to name those types, methods and variables so it makes sense in reading, no just objX :) The only exception to that is BigInteger/BigDecimal arithmetic, we do it quite much and it would be impractical. We have also disallowed using expressions for arguments of method calls, and ordered using variables or constants instead, with the same exception.

Another thing forbidden is exception chaining, every exception is to be logged at the level it is caught and serviced, and if a new exception is thrown it cannot chain the original exception.

Comments (other than Javadocs and task marks like FIXME) are also strictly forbidden, the code has to be readable without comments. So the variable names and test names and bodies look like comments :)

(And we have tools to check for violations so it is not just an unobserved wish but really enforced coding policy.)

While it was disliked at the start, and many programmers have complained that it would make their development time longer, I just told them that the company will pay for that longer so they just don't complain anymore.

And something more was done - most complaining people were assigned some maintenance work on projects that didn't have those policies and then, after they have done it, they were assigned to do other work on other people's code in their main project. And this has convinced everyone that this verbosity is positive and really needed because just gaining a line here, a line there at cost of making people who will work with this code later suffer and cry cause they don't understand the code is no good and in fact will cost everyone more and more.

Marcen, we can debate the merits of dynamic langua...

2007-01-06T00:16:00.000-06:00

Marcen, we can debate the merits of dynamic languages on the JVM until we're blue in the face, but the fastest way to kill off the Java "platform" is to forbid other languages on it.

Java (the language) is a boiler-plate ridden, barely-OO mess.

I can't understand all that hype about java script...

2007-01-05T06:51:00.000-06:00

I can't understand all that hype about java scripting, JSR292 and so on.

What makes Java greatest is the safety it guarantees as a unique environment of the language, the class library, the virtual machine and the security model. In that order, I should think. That's why Java is the platform of choice - the language makes it easy to write more robust, maintainable code than any other language, the class library allows reusing great code written by other people which provides more "batteries" than any other platform has, the VM allows it to run on more hardware/os than any other thing can, and the security model where it's needed allows controlling what the code can do to some degree - it has been a unique feature for so long.

Now allowing Ruby, Python et al. will effectively kill Java - those languages are simply asking for bugs and problems due to their "duck type" systems and lack of checked exceptions among other issues. But once it is made possible, people will start writing class libraries in those excuses for a programming language and what will it mean? Less robust, less maintainable code leading to more less robust and less maintainable code. Soon even ignoring Ruby and using Java won't guarantee that foreign class you use isn't a duck in disguise. But worse still, those languages are mostly UNIX-oriented so it may also kill portability...

Now if I take a Java library I expect it to run everywhere or has a warning sign that it uses native code so I beware. But allowing lower standards' languages into Java island will make it also pollute and blur.

I think it should not be allowed but discouraged or even forbidden (by a license stating no code but written in Java can run on what may be called Java platform).

Hi Charles, it is possible to quite effectively m...

2007-01-04T16:17:00.000-06:00

Hi Charles,

it is possible to quite effectively mimic the functionality of invokedynamic; our project at java.net has been doing this for years.

Please, have a look at this very short example.

I think duck typing at its best uses more types th...

2007-01-03T22:32:00.000-06:00

I think duck typing at its best uses more types than just 'any' (= Object). Also, invokedynamic and incremental class extension can be viewed as low-level building blocks for dynamic calling sequences. See my post.

Also reconsidering Fixnum optimizations, the compi...

2007-01-03T21:52:00.000-06:00

Also reconsidering Fixnum optimizations, the compiler would have to emit guard code before all e.g. ... iload, iload, iadd ..., points to check whether specific Fixnum method has been changed. I'll try to check how YARV deals with that - the setting responsible for that is OPT_SPECIALISED_INSTRUCTION in vm_opts.h

I liked the kaboom part:)

2007-01-03T16:39:00.000-06:00

I liked the kaboom part:)