I've previously
written about scripting languages in Java
and some of the interop issues with them. My basic thoughts haven't changed, though I also haven't
been playing with any of these lately. But I have some additional thoughts.
My DEmentor,
John Duimovich
(he's an IBM Distinguished Engineer), found me on Google Talk last night, and
we ended up chatting about all kinds of stuff, and one topic was scripting language / Java interop.
John threw out all the usual pro's that come with this sort of interop nirvana:
- You can write your (non-time-critical) business logic in a scripting language, which
will be smaller and more readable than in Java, but more importantly, you can
write it quicker.
- Your scripting language can make use of all the great Java class libraries available.
- You can probably make use of at least some class/function libraries in your
scripting language from Java.
Sounds wonderful.
I think most people, when they hear interop stories, get afraid of
performance. Ignore that one for now; consider that you could at least prototype your
Java code in a scripting language, then convert to Java later. Interop would still
be a huge benefit.
But performance isn't the issue. There are bigger issues. Let me recap, quickly. Read
my previous blog post
for more details.
- debug
- code completion on the Java you are 'writing' in your scripting language (I can't
live without Java code completion)
- impedence mismatches between languages; especially typed Java arrays
My experience is that the complete story isn't really all that easy
with these interop stories. Which is probably the best reason you
would want to do this anyway. That takes care of the first pro.
For the second and third pro, I'll just ask: what libraries are you wanting
to use in the 'other' language (be it Java or scripting language)? Is there
really that much of a difference, these days, between the functionality of,
say, Java, PHP, and Ruby? Functionality from 10K feet, because you obviously
use Rails when using standard Ruby, and are using Servlets in Java (or worse);
think holistically here. The answer is ... not really.
Is all hope lost? For language interop ... yes.
Does that mean implementations of scripting languages on Java is pointless? No.
IronPython
performance is on par with python-c. So there's no reason why
implementing a scripting language in Java isn't a reasonable option,
though you probably want to factor in things like
a need for invokedynamic
and
making Java a better C
(more on that last one in a future blog post).
The question is, do you really need user-level language interop, or do you just
need your scripting language and it's typical libraries? I say the typical libraries,
because at some point you are certainly dealing with Java objects in your
interpreter / runtime, but they don't necessarily need to be visible to the
end user; the programmer in this case. And you could certainly invent a mechanism
to allow scripting language functions / classes to be implemented in Java
for those non-mortals amongst us that implement core libraries. Back
in the early VisualAge for Java days, the Java natives were implemented in Smalltalk
(boy, was that sweet!). Who used it? Not many people (well, we didn't advertise it),
but not many people would have needed it anyway. Not many people write the
core libraries.
Taking the burden off of the scripting language implementor to add an
'interop facility' is also a huge benefit. At least, an interop facility that
you have to make available as public API.
End users (programmers) win, to some extent, because they don't have two languages/class libraries
to deal with. They lose the theoretical interop benefits, but they never really had them
anyway.
In the end, what's the real benefit to doing this? That we get to implement
our scripting languages and their extensions in Java. And not C. Or worse.
With the recent GPL-ization of Java, I'm hoping that we're going to see
Java available much more widely than it had been before. Time to take advantage
of this situation.
I've made all sorts of crazy assumptions here; please attempt to prove me wrong.
Photo
'Keep 'em separated'
with a
nice CC license,
by
Mark and Allegra Jaroski-Biava.
Found using the
Flickr's Create Commons Search.
Update: So one assumption I got wrong was that John was arguing for the level of Java interop that I'm suggesting is pointless. He wasn't. He's on the same page as me (well, closer than I thought). The problem is the term interop was used, and it clearly means different things to different people.
Useful interop are things like JNI, the Zend API, etc. Useful because I can interoperate with C, that can do anything it wants to on a machine. Useful, but difficult to use. Who wants to program in C? Especially with these rather arcane 'extension' libraries. That's not just C, that's complicated C.
When I hear interop, I hear the "end user programmers can talk to Java directly from language-X". When John hears it, he's thinking JNI. I think this is good material for a future blog post - "defining interop".
Mea culpa John. Gotta go find me a little chocolate.
