Jython and Java part 2

Well, in the week since my post on Jython, some really good news has come to my attention.

Ted, and Frank are now working on Jython and Python stuff for Sun Microsystems. I’ve heard from Frank, Jim, and Ted that the work on the JVM is actually already a much more hospitable environment for dynamic languages than I thought. And all of them have pointed to the Da Vinci Machine project as being an active project with a community that’s very concerned with making the JVM into a really great platform for dynamic languages.

Ian Bicking suggested that the runtime environment of the JVM isn’t all that friendly to Open Source sensibilities (the VM takes a while to load, it’s got WAY to many options, and is too complex to tweek properly for memory issues.) And perhaps that’s true, but I think the least friendly bit of the JVM is the what feels like open hostility towards C libraries. In my opinion this is the biggest single issue in terms of hostility to the Open Source way. So much of the Open Source community is steeped in a Unix+C ethos that’s very hard to shake. And for significant number of problems, there are indisputable performance gains that you can get when you manage the way that your data structures are arranged in memory yourself. I’ve been told that this is getting better too, and that the horrible days of the Java Native Interface (JNI) are numbered.

On another front, I had hoped that the Jython and Jruby people could reach across their respective language community cultures, and work together. And I’ve been told a good chunk of the JRuby team is coming to the PyCon sprints to help with the Jython sprint — which is awesome!

In other news:

Somebody suggested that perhaps the Tamarin virtual machine might be a viable alternative to the JVM, with the IronMonkey project porting IronPython to that vm. I honestly don’t think that will happen, both because the IronMonkey project seems stalled, and because the IronMonkey project was just a IL to Tamarin VM “bytecode” cross compiler, so it would likely always be a step behind the .NET guys in terms of performance.

4 Responses to “Jython and Java part 2”

  1. Hey Mark,

    The specific project that aims to relieve us all of the pain that is JNI is JNA: https://jna.dev.java.net/ The JRuby guys have already implemented some Posix compatibility for JRuby, and this work is on the short list for our (Jython and JRuby) collaborative efforts.

  2. Hi Mark,

    We are definitely going to try to get more cooperation between JRuby and Jython – it just makes sense to do.

    I’m sure that any of us would be happy to sit down and talk with you more at PyCon.

  3. Another VM in the mix now is Android. It’s kind of niche for mobile stuff, but even then that might be a better starting point. It’s also a moving target without a clear spec, but… well, maybe it’s not really in the mix yet. On the horizon?

    PyPy people put the most focus on LLVM. I’m surprised no one took CPython and tried targeting it to the LLVM (maybe just at the bytecode level).

  4. Ian,

    The Android project is really interesting — I’m not sure exactly what’s happening at the VM level there, but I’m sure the’ve done some interesting stuff.

    The LLVM is an interesting project too, but it seems a little low-level as a platform for dynamic language collaboration. But it also looks like they are building some tools for higher level collaboration.

    I do really think that there is a chance that standard hot-spot optimization system, memory management infrastructure, and perhaps even thing like dynamic method lookup systems and some of the other DLR infrastructre tools, make sense as shared components across dynamic languages.

    And right now the JVM seems like the platform that’s most likely to make that happen, but I’d be happy if it were the LLVM, or any other “open” solution.

Comments are currently closed.