Note: any errors in this post are mine, not Ben's.
Many of you might think that the idea of porting Perl to the Java Virtual Machine (JVM) is silly. In fact, it's not silly, but it's difficult and what would come out of it would be different. The JVM is simply not designed for dynamic languages and its "everything is an object" assumption simply doesn't fit the multi-paradigmatic nature of Perl. However, it's still not a bad idea, just a difficult one.
Ben Evans gave a fascinating talk about this topic at a recent London.pm meeting. He's posted the slides of the Perl on the JVM (pdf) online and there's a little more discussion at his journal. He would love to have people help out with this idea, but with the caveat that this is an experiment! Like any experiment, it might fail. Ben knows that. You should know that too. And don't post long explanations about why this can't work because he's done enough of the work already that he's quite familiar with the failure modes. Basically, the project could use people with a "can do" attitude rather than a "can't do" attitude (I've worked on plenty of projects getting stuck with "can't do" people and frankly, they suck).
Why might we want to port Perl to the JVM? Well, it's blazingly fast now. Not many people talk about the Perl versus Java speed metric because, except for a few edge cases, Perl loses. Oh, and Perl would have a proper threading model, decent exceptions, a well-known deployment model, etc. There are plenty of benefits here, but plenty of issues, too.
First, Perl would have to change in some ways. Perl as it currently exists won't run on the JVM, so what comes out of this project, if anything, isn't going to be Perl in the way that jRuby isn't Ruby. Once we accept that some things would have to change, what would they be? Well, new has become a keyword. Part of the reason for this appears to be this (working) code snippet:
package TestB;
use java.util.HashMap;
sub bar {
my $b = 1;
my $c;
my $obj = new HashMap();
if ($b == 0) {
$b = "yyyyyy";
}
else {
$b = "zzzzzz";
}
print $b;
print $obj->toString();
}
1;
And in case you're wondering, scalars look like this:
public class SV {
private String pv;
private long iv;
private double nv;
private SV rv; // For references
private Object obj; // Foreign objects
// ...
Look familiar?
Part of what's needed to get this working is coming up in OpenJDK 7 and the internals of that project might change, but the guts are there.
This isn't a project for everyone, but if it succeeded, this would be an incredibly valuable project which could have long-term benefits. However, this project is more of a "fun" project than a "we must deliver this" project. The idea is to learn new things rather than to deliver "Enterprise Perl", so keep that in mind, in spite of what I've written :)
Eventually Ben would love to get some core "Perl only" modules ported over just to see how much he could make work or how much he could bake into the language. Of course, some think "Perl 6" and wonder how this would fit, but Perl 5 will be around for a long, long time (I still see Perl 4 code) and this could give an exciting avenue for flexibility in Perl 5 -- particularly if Moose is built-in.
Re:XS?
claes on 2009-04-21T14:31:20
Java uses JNI which is its native extension mechanism. I'm pretty sure at least basic XS modules could be compiled using a compat layer that provides XSUB.h and perl.h definitions but calls the appropriate JNI functions instead.
(and no, I'm not volunteering)
Re:XS?
Ovid on 2009-04-21T14:43:14
It was my understanding that, like Ruby, the C extensions won't be available. That being said, I don't know that this is impossible, but it's not planned as far as I'm aware.
Those XS extensions written in order to interface with different C libraries might be problematic. Those written for speed would be suitable candidates for rewriting as Java approaches the speed of C (and in some benchmarks can exceed it due to Java's optimizations).
Re:XS?
Deprived on 2009-04-21T14:56:11
i guess that my pipe dream of a spidermonkey perl module running inside the jvm isn't going to happen.
oh well, at least there's still rhino.
In case there are people interested, I have started a similar-yet-different project.
At the moment I am concentrating in writing a Perl parser in Perl (it can currently parse itself) and writing a
Check out http://github.com/mbarbon/language-p/tree/master.
in time I hope to have something like PyPy: a complete Perl runtime written in Perl and recompilable to any lower level platform (I am dreaming to support
newhas become a keyword.
I can't see why that'd be necessary. For Perl 5 object semantics (overloading, AUTOLOAD, UNIVERSAL, dispatch) you need a thunking layer between Perl objects and Java objects already. If you want interoperability between them, you need the same thunking layer.
In my mind, the right approach is to translate all bless REFERENCE syntax into metaobject calls, not to add new syntax. The Perl 5 data and object models are flexible enough that you can implement them in terms of Java more easily than the other way around.
Of course, unless the upcoming JVM supports dynamic classes, things will get slow with all of the trampolining....
Re:The new Keyword
jdavidb on 2009-04-23T18:07:39
I agree it's not necessary to make new a keyword, and I don't think it's desirable. I wasn't thinking about making JVM objects available at the Perl level, but if you wanted to do that, I'd propose a new keyword instead: javanew, or something like that. Then Perl can be Perl, and if you want to get to JVM objects you can.
Come to think of it, even better than a keyword might be a module. It'd have to be a very special module, though, something akin to DynaLoader.
Anyway, great project! It's been done (and failed) before; I'd like to see it succeed.
Re:The new Keyword
Ovid on 2009-04-23T18:44:41
But what do you do if you want to instantiate a Ruby object? Create a rubynew constructor? New constructors for every language out there? It gets unwieldy after a while.
Re:The new Keyword
chromatic on 2009-04-23T19:28:43
Add to that the fact that adding keywords specific to an implementation diverges from the reference implementation. Library fragmentation is bad enough; as Microsoft and Sun about that sometime (though the latter has been happy to inflict it upon other languages).
Re:The new Keyword
Ovid on 2009-04-23T19:40:07
You'd have to talk to the people putting it together. At some point, there's probably going to be some divergence. Perhaps they can also get rid of legacy stuff that's holding Perl back?
Re:The new Keyword
chromatic on 2009-04-23T22:46:53
Perhaps they can also get rid of legacy stuff that's holding Perl back?
I have no hope of that experiment succeeding until p5p consensus finally acknowledges that its long dalliance with DarkPAN-paralyzed stagnation has failed, miserably. (Perl 5 doesn't have classes in 2009?)
Of course, a successful Perl 5 on the JVM (or even Parrot) might demonstrate that the sky hasn't fallen, and both people who care about running code last modified in 1995 on a release from 2009 can well and truly port it themselves (especially if compatibility mode means only adding
use crufty 5.004;to the top of most programs.You might recognize this as the digital television converter box strategy, which seems to have affected a fair few more people than Perl releases.
Re:The new Keyword
jdavidb on 2009-04-24T14:13:45
In that case, I like the idea of having to go through a module, better. When you want a Java object, you have to explicitly go through a Perl module that provides that access. When you want a Ruby object, similar story, different module.
I had no idea you were trying to provide access to objects in so many different languages...
First of all this sounds like a very exciting and interesting project.
But I have to agree with chromatic that, if you want to support as much of Perl as possible, you'll probably need some kind of indirection layer, both for the object system and for things like local $a[2] = $stuff; (Or is that handled in the SV structure?)
Another piece of interest - does it support BEGIN blocks (and if not, is that planned)?
I posted this blog entry into reddit and this link was posted in comments: Considerations on Porting Perl to the Java Virtual Machine - master thesis.