Multi-Language VM proposal from OpenJDK mailing list

Discussions

News: Multi-Language VM proposal from OpenJDK mailing list

  1. John Rose, from Sun, has proposed a "multi-language JVM" as part of the OpenJDK project. The "mlvm," as he terms it, would support features like tail recursion, continuations, closures, tuples and value-oriented types, and more, in order to support alternative languages on the JVM... all while not compromising existing VM compatibility. From the post:
    This project will be open for prototyping JVM features aimed at efficiently supporting languages other than Java. The emphasis will be on completing the existing bytecode and execution architecture with general purpose extensions, as opposed to a new feature for just one language, or adjoining an unrelated new execution model. The emphasis will also be on work which removes "pain points" already observed by implementors of successful or influential languages, as opposed to more speculative work on unproven features or niche languages. Virtual machines produced by this project will be standards-conforming, in that they will not change the meaning or behavior of existing Java classes and classfile formats. They may define variations or extensions of the class format, or new kinds of objects, whose meaning and behavior are beyond the scope of current Java and JVM specifications. However, these extended codes and data structures will interoperate as much as possible with Java objects.
    What do you think of this proposal? Certainly languages like JRuby, et al, already support some of these features, and continuations are available for Java as well, but having a VM that supports them directly would certainly be helpful. What happens if implementations like JRuby start requiring the new bytecode?

    Threaded Messages (20)

  2. If JVM supports multiple languages then what the advantage the programming community gets out of that. Programmers are less interested at VM level. Sorry but I am really trying to understand how we can get benefited Thanks, Shabbir
  3. going by instinct[ Go to top ]

    .. id have to say that its a .net copycat, so likewise we could do a copydog of a the .net billboard touting how brilliant this concept is. Actually i think its a good idea. Very good idea. We shall stand together, all true languages, we go forward to defend freedom and all that is good and just in our world(what song?). cut out the irony and im dead serious.
  4. Will it incorporate Parrot?[ Go to top ]

    Will the proposed Open VM incorporate the work of the Parrot Project - Python , Perl etc in a common VM? Paul , People and Technology Blog
  5. Slippery Slope[ Go to top ]

    I think the idea is sound, but don't expect it to be simple - politically or technically. How do "we" (me not being involved) decide what's in and what's out? Tail recursion? Sure. So why not SIMD, or orthogonal persistence, or new concurrency primitives (a la ada or SR or CSP), or constrained types? Who decides? Again, I think it's a great idea. But it'll need something like a JCP to keep it on the rails.
  6. If JVM supports multiple languages then what the advantage the programming community gets out of that. Programmers are less interested at VM level.

    Sorry but I am really trying to understand how we can get benefited

    Thanks,
    Shabbir


    What about closer integration and interoperability... Im a programmer(not a code monkey) and Im very interested in the VM level. Wouldnt it be great to have a vm that natively supported a bunch of laguages and kinda hence a bunch of platforms. What if I could grab a really great library/package written in python and use it in a jvm in an app server? I think integration like that(while a long way of for technical tho mainly business reasons) would be something to pursue. What the hell is the point of having a virtual machine that just supports one language... that is a hack.
  7. This is a good idea. Hey, DotNet took Java and improved upon it, so why not equal up on that. Superpackages are a great example (trying to mimick DotNet assemblies) or DotNet's version-aware classloaders. The JVM is robust and very mature, even more so than the DotNet VM, so it would be unwise not to use that as a basis and extend it. Whether Java syntax follows suite is indeed less relevant (although I certainly hope it will, because I like it).
  8. No, please DO NOT change VM[ Go to top ]

    Unfortunately, SUN has a very bad track record in imitating .NET. Just compare generics in .NET and Java. I also don't understand the need for 'superpackages'. Package system already works fine (more or less), I've never seen versioned assemblies used in _real_ .NET projects, for example.
  9. Re: No, please DO NOT change VM[ Go to top ]

    Unfortunately, SUN has a very bad track record in imitating .NET. Just compare generics in .NET and Java.

    I also don't understand the need for 'superpackages'. Package system already works fine (more or less), I've never seen versioned assemblies used in _real_ .NET projects, for example.
    The point of a superpackage would be to allow two or more packages to access each others' package level members (or perhaps a new access level.) I don't think it has anything to do with versioning.
  10. Re: No, please DO NOT change VM[ Go to top ]

    I also don't understand the need for 'superpackages'. Package system already works fine (more or less), I've never seen versioned assemblies used in _real_ .NET projects, for example.
    Superpackages AFAIK are a way to deploy a package-of-jars, so to speak (among other things). Right now I have a big hassle in deploying my fat client thingy. I now resort to unpacking all required jars and repack them into one. However, not all jars allow this and have to deployed separately, so this is a makeshift setup. The EXE builders do something similar as superpackages are suppose to do. Versioned jars should allow a project to use libraries that simultaniously that have a conflict in their version. Say a library A uses log4j 1.1 and B uses 1.2. You cannot use that within one project at the moment. I'm indeed curious if it will work "as advertised".
  11. Superpackages[ Go to top ]

    Here's a link that represents the basic idea of a superpackage as I understand it but it does seem that the term is being used differently in some circles: http://blogs.sun.com/andreas/resource/superpackage_strawman.html
  12. Unfortunately, SUN has a very bad track record in imitating .NET. Just compare generics in .NET and Java.
    Why do people whine so much whenever new features are suggested? I think Sun took too long to figure that out! This should have been done 2 or more years ago. I am against transforming Java in a mutant language, they shouldn't bloat the language with all sorts of features, but I am in favor of production ready implementations of other languages on the JVM. This one VM for many languages idea was something that Microsoft did right, although only now they have actually fulfilled their original promise.
  13. Microcode[ Go to top ]

    It would be nice if you could implement new JVM instructions in a sort of microcode. It would obviously be much slower than hand crafted c code.
  14. Personally, I think this is an excellent idea, and support it 100%.
  15. They may define variations or extensions of the class format, or new kinds of objects, whose meaning and behavior are beyond the scope of current Java and JVM specifications.
    If this means I cannot run the compiled code in just any JVM than it sucks. Bytecode should run on all VM's
  16. I am not in any way an expert in JVM or VM's in general. But I consider it very likely that a JVM specification created for the Java language would have som bias towards languages like Java. Dynamicly types languages like PHP, Python, Ruby etc. may have different requirements. If the JVM can be extended to better support this type of languages without decreasing the support for the main language Java, then it sounds as great idea to me.
  17. This sounds an interesting idea. Another thing that makes sense to me is an effort to utilize a single VM for more than one simple program or application. This already exists for common Java VM, and is great because there area a lot of benefits on memory management and performance, and even the reuse of String intern table. Now, I think that in the mlvm, this feature should be native and also an IPC mechanism so all supported languages in this VM could interoperate.
  18. A very good thing for Java[ Go to top ]

    This is very good news for Java and Dynamic Scripting. The JSR 223 ScriptEngine supports JNI dispatching to external script languages (that is a bad idea) and a common API to call on-the-fly byte-code compiler script engines (a very good idea.) The more support for the JVM the more longevitiy the JVM will have in the world. The current JVM lacks an efficient way to dynamically dispatch calls to methods. Enhancing the JVM with an "invokedynamic" instruction will make it much easier to write the compile-on-the-fly kind of script engine. Also, the original JSR 292 project includes not only invokedynamic but also some sort of class modification or extension. The expert groups believes something is needed beyond invokedynamic to support some sort of lightweight behavioral extension (method handles, autonomous methods.) This is really cool! -Frank Cohen http://www.pushtotest.com
  19. It is definitely a very good idea. We can have C#, VB and Fortran on JVM. (each language has its own audience and developers) I am thinking of mixed applications (swing, web, enterprise). We can really have a stronger JVM market and take revenge of Mono project too :) (just kidding)
  20. Sharing objects across languages[ Go to top ]

    One thing that has not yet emerged is how JSR 223 will act as a broker of objects between languages. If I create an object in a Jython script then how can I access the same object in a Groovy script. I'm looking forward to what John has to propose. -Frank
  21. I certainly like the idea of not over bloating Java with more features. Sure, generics are nice, so it's the super package and there are probably lots of use cases where one will need something of this sort, but why to put everything dynamic languages support in Java?! Having the JVM supporting these languages seems a lot more reasonable, since anyways you can still interact with the Java world just like JRuby does.