Summary
Sun announced last week the hiring of Thomas Enebo and Charles Nutter, the two key developers behind JRuby. Artima asked Enebo and Nutter, as well as Tim Bray, Sun's director for Web technologies, what this move will mean for the Java and Ruby communities.
Advertisement
Sun's hiring of the two key figures behind the JRuby project, Thomas Enebo and Charles Nutter, promises a truly robust Ruby implementation on the JVM. Enebo noted that working for Sun full time will allow the duo to focus on achieving the JRuby project's ambitious goals:
[The goal of JRuby is to] make the best Ruby implementation we can on the JVM. Part of this is making the runtime perform well, and part of it is helping to bridge the Java and Ruby worlds in a way that is easy for a programmer to use...
Sun's hiring us will give us much more time to work on JRuby, which will obviously speed things up; but it will also increase the quality of how we work, since we won't be taxed from an additional day job.
Nutter pointed out that JRuby will be entirely compatible with the C-based Ruby implementation:
We...aim to provide a drop-in replacement for the C Ruby interpreter... We are working to keep JRuby as compatible with C Ruby as possible... Compatibility with C Ruby is of paramount importance; if we can't run what Ruby can run, what's the point?
At the same, JRuby may provide capabilities to Ruby code not available in the C-based Ruby interpreter. Here, again, is Charles Nutter:
There are many cases where the Java platforms and libraries are required for a given project, owing sometimes to the fact that there's just so many Java libraries out there. Other projects may have threading requirements that go beyond what C Ruby can provide, or database connectivity issues that JDBC can solve.
Nutter noted that by keeping JRuby compatible with the C-based Ruby interpreter, projects can easily migrate back and forth between the C-based and JVM-based Ruby interpreters.
The move to support a high quality Ruby implementation that runs on the Java virtual machine highlights the JVM's gradually evolution into a general-purpose execution environment, not unlike the role Microsoft's CLR environment plays. Sun's Tim Bray noted that,
Looking back ten years, it might have been really smart, at the birth of Java, to brand the platform and the language separately. But during Java's early years, the technology was hitting such a big sweet spot that it was easy to see the whole thing—VM, libraries, and language—as a single engineering triumph. Microsoft was smart to get out there and evangelize that a virtual machine and API repertoire aren't necessarily tied to a language. On the engineering front, we've been pretty serious about going multi-language for some time now, [for example,] with the work on Rhino and the proposed new dynamic-method-dispatch bytecode.
Bray also noted that the JVM can become one of the most capable Ruby execution environments:
Currently, native Ruby runs mostly in interpreted mode. If we arrange for JRuby to be compiled into Java bytecodes, it'll be running on the JVM, which is one of the world's most heavily-optimized pieces of software. So JRuby might end up having a general performance advantage.
More specifically, Sun is leading the charge toward highly-parallel multicore computing with the T1000 and T2000 "Coolthreads" chips, which are really well-suited to server-side Web apps. The native Ruby implementation of threads is fairly limited and may not take good advantage of this kind of CPU. JRuby uses native Java threads, which are very highly tuned; so in the particular case of highly-threaded parallel code, there's a pretty good [chance] that JRuby will be a performance winner on modern silicon.
In addition to the performance advantage, the JVM may offer a political safety to developers wanting to code in Ruby in an otherwise Java shop, as Nutter pointed out:
JRuby may ... be able to offer some "platform confidence" to existing Java shops wary of accepting Ruby as a business-critical application language. We all know the suits love anything that says Java, and as far as they're concerned JRuby is just Java in a different form. Of course we've always had to pick and choose languages and libraries from many places, but now there's a much easier path to introducing Ruby into a Java-based organization. That should make a lot of Ruby folks happy, since it means more work, more exposure, and more opportunities to grow the language and the platform.
In addition to runtime and political benefits, a robust JRuby implementation will bring Ruby developers the biggest benefit by allowing Ruby code to make use of thousands of Java class libraries. Enebo noted that,
Java has a huge corpus of libraries... In some semblance most libraries you can think of have already been implemented in Java, usually as an open source package. JRuby allows Ruby to access any Java class and interact with it as if it was written in Ruby. This means a Ruby programmer has a much larger toolbox at their disposal.
Nutter also remarked that JRuby may be a natural way to bridge Java's suitability for writing library code, on the one hand, and Ruby's productivity, on the other:
JRuby is the right tool for anyone who wants to leverage the decade-old decade-tested Java platform and libraries without the sometimes cumbersome overhead of writing everything in Java. Java the language is great... but it's great in the way that C is great, as a language for bare-metal, system-critical libraries and algorithms. Developing more squishy, dynamic, touchy-feely "application" code in Java is a joyless proposition. That's where Ruby comes in...
I like to think that JRuby is to Java what Ruby is to C. UNIX guys have known for years that while the heavy lifting is best done with a fast, static, compiled language like C, most of the real work gets done with scripting languages like Perl, Python, and Ruby. For some reason, it's taken much longer for Java folks to realize the same thing.
Indeed, Sun's Bray noted that accesses to Ruby's productivity is the biggest pay-off of JRuby for Java developers:
The most obvious short-term benefit will come to Java developers who want to write part of their app in Ruby. There are certain classes of problem where dynamically-typed languages give a better fit and you get your solution [finished] sooner. This kind of developer will be able to go on using their existing Java classes and packages and interfaces, while still enjoying Ruby's advantages.
In addition, Enebo pointed out that JRuby is also available as a JSR 223 scripting language:
A Java project can also make use of JRuby by embedding via JSR223 or BSF. This allows a Java application to delegate some subset of its code to a language that may be better suited for filling a particular need. One example I have been playing with recently is interacting with JMX MBeans.
While Ruby and Java seem a natural pair, working full-time for Sun will allow Enebo and Nutter to focus on some of the thornier issues of marrying Ruby's dynamism with the JVM. Nutter pointed out that,
Java has always been designed as a multi-lingual platform, but its support for dynamic languages like Ruby isn't quite where it needs to be yet. That means that for much of Ruby we've had to implement a "VM on top of a VM" that bridges that gap. We do not have control over the Java stack...so we maintain our own. We do not have a dynamic invocation bytecode in the JVM...so we use our own method. We don't have support for closures...so we simulate them with movable scopes and command implementations. However our recent efforts have aimed toward componentizing these pieces; as the JVM evolves to support them, we'll be able to toss them out one by one.
Enebo added that,
We have to emulate a set of language semantics which do not map well with the JVM's underlying design. Those language semantics are sometimes quirky and reflected some evolutionary set of changes which need to be properly reflected in our implementation. We are getting pretty close to matching parity with the C implementation, but some of the last cases will be a challenge. Also as we understand the internals better we have ideas, but it is tough to visualize the change thoroughly because of the amount of moving parts we need to understand.
Still, Enebo, Nutter, and Bray all agreed that Ruby is a more natural match between a dynamic scripting language and Java than previous such attempts, such as a Tcl/Java combination. Here is Enebo:
Ruby has significant differences from Java, but those differences are generally flexibility at runtime. You can dynamically create classes and define methods at the drop of a hat. This flexibility takes Java's stricter statically-typed environment and allows you to do things not possible in Java to Java objects [and] classes. That gives the programmer a sense of freedom and empowerment. The differences in these cases will play off as positive features to a programmer. This is one thing I like about the combination of Java and Ruby. Java provides [a] strict well-delineated [environment] ... and Ruby provides a less restrictive environment because of its dynamic properties and dynamic typing.
Nutter added that,:
The disconnect between Java and Ruby is much easier to bridge. Ruby is a pure OO language where Java is a "mostly" pure OO language... Ruby has classes, methods, objects, just like Java. Ruby has basically the same flow control and exception-handling semantics. Ruby makes threading deceptively easy, as does Java. When you ignore Ruby's fluid typing system and simpler syntax, the leap from one language to the other isn't really that far.
What do you think of using a scripting language, such as JRuby, with Java? To what extent did that improve your productivity? And what are some of the downsides of using a dynamic language in Java's static environment?
Well, there's a lot of Java code. Some of it is useful. So being able to call it is nice (once upon atime before C++ - we had binary compatibility among the different languages).
OTOH, Sun is looking desperate. They have hired a lot of dynamic language luminaries including Gilad Bracha, Dan Ingalls, and now the JRuby guys, to build dynamic languages on their VM.
It seems like they are hedging their bets. Java the language is a drag - and people are bored with it. It lacks power, it requires pointless verbosity, it sucks creativity, it is dull dull dull to program in. Java the language's days are numbered for sure.
The influencers have moved on to more dynamic pastures.
It might be good - or it might be irrelevant. It depends on whether JRuby can match Ruby in performance, portability, and still provide access to the Java legacy code base in a way that is easy to use.
> It seems like they are hedging their bets. Java the > language is a drag - and people are bored with it. It > lacks power, it requires pointless verbosity, it sucks > creativity, it is dull dull dull to program in. Java the > language's days are numbered for sure.
I agree. One of the things I'm hoping for is that they will provide support for generics on VM level (like CLR), so that the language can do away with the type-erasure approach and get better support for generics. I think that's one of the most important areas where Java needs improvement.
> It seems like they are hedging their bets. Java the > language is a drag - and people are bored with it. It > lacks power, it requires pointless verbosity, it sucks > creativity, it is dull dull dull to program in. Java the > language's days are numbered for sure. > Perhaps the Java language's days are numbered, but I'd expect it is a big number. The Java language is a workhorse. It allows developers to get stuff done, and it has huge momentum.
Moreover, I think the Java language can still be improved. Over time, it gets harder to add things to it, such as closures, but it is possible. Also, it seems to me that it would be possible to remove some of the verbosity, if that were deemed of value by the powers that be. (I for one think that would be a valuable "subtraction" from the language.) In other words, couldn't type inferencing be added to Java, making certain type specifiers optional? Old code that had type specifiers would continue to compile, but new code need not include the redundancy in statements like:
int i = 1;
That would still compile, of course, but if it were otherwise not ambiguous, so would this:
i = 1;
The compiler would assign i to the type of 1, int.
Gosling suggested I think in his blog at one time a syntax like the following be a better way to do this:
i := 1;
So he seems to believe it would be best if programmers actually indicated explicitly that type inferencing should be used. I don't understand why that would be necessary.
Also, even though one of the difficulties of adding closures to Java is that the Collection interface is already set in cement using the Iterator approach, and that it would add more bulk to come up with a different collections hierarchy that uses closures, that is still possible if it is deemed a net win. All the concrete collections classes could potentially be made to implement both interfaces. Bulky, but possible.
Because of backwards compatibility, the bulk of Java's APIs and the Java language will keep growing, but I think a lot of times it will be a fine tradeoff to use the subsets of it. For example, I think you can nowadays safely use EJB3 and ignore the EJB2 and EJB1 stuff.
> Also, even though one of the difficulties of adding > closures to Java is that the Collection > interface is already set in cement using the > Iterator approach, and that it would add more > bulk to come up with a different collections hierarchy > that uses closures No, just use method additions like C#3.0 does: public static void each(this Collection<T> c, Func<void,T>)
BTW, C#3.0 also adds a shorter closure syntax and local type inference, which would look like
var i = 1;
And I can understand Gosling that it is good to see that a variable is declared, not just assigned.
What do you think of using a scripting language, such as JRuby, with Java? To what extent did that improve your productivity? And what are some of the downsides of using a dynamic language in Java's static environment?
The downside of scripting Java with Ruby is less a static vs dynamic tension but a Swing/J2EE/... - Ruby design mismatch. The larger the API the thinner the layer. Hence the Java architecture starts shining through Ruby and appears to be likely inappropriate. This begins with naming conventions and ends with inadequate documentation for the scripting layer. And what does a Rubist with all this Java framework stuff and design pattern which are obsolete by means of Rubys language features? The inverse approach is to start with Ruby and factoring performance hot spots into a language with better optimization capabilities such as Java/C etc. That's how the runtime grows adaequatly right now with all kinds of extensions. But this way you end up with another huge stdlib written basically in Ruby. So the benefits of existing Java libs are hardly exploited.
> int i = 1; > > That would still compile, of course, but if it were > otherwise not ambiguous, so would this: > > i = 1; > > The compiler would assign i to the type of 1, int.
I don't have much experience with dynamic languages so this could be a dumb question, but what advantage does
> Perhaps the Java language's days are numbered, but I'd > expect it is a big number.
Yeah sure, they still write COBOL too I hear.
> The Java language is a > workhorse. It allows developers to get stuff done, and it > has huge momentum.
Momentum implies inertia. Like a boat anchor. You can get stuff done, but it takes forever relative to what you can get done using more dynamic tools.
> Moreover, I think the Java language can still be improved.
Here we disagree. I think Java the language is BBD (Broken By Design) and cannot be fixed without breaking everything else. Many core tenets/base beliefs in the design are simply wrong.
> Also, even though one of the difficulties of adding > closures to Java is that the Collection > interface is already set in cement using the > Iterator approach, and that it would add more > bulk to come up with a different collections hierarchy > that uses closures, that is still possible if it is > deemed a net win. All the concrete collections classes > could potentially be made to implement both interfaces.
You just made my point.
> new code need not include the redundancy in > statements like: > > int i = 1;
But the Java type system itself is broken. Adding smarter compilers to do more syntactic sugar (which is all they've done since version 1.1) won't fix it. I mean, why is there int? You don't need it. Make it an object and let me extend it.
>I think you can nowadays > safely use EJB3 and ignore the EJB2 and EJB1 stuff.
Again, opportunity lost. EJB1 was an abortion. EJB2 was a different abortion. EJB3 - (fingers in ears) I'm not listening (/fingers) but what I can see it looks a bit like - well WebObjects. But I don't build apps that way anymore either.
I work for the worlds largest online retailer. I've got friends at some of the other big 5 web sites. None of us have architectures that look anything like EJB[123]. They do not scale. Sun has zero credibility when it comes to specifying scalable architectures. They have NO EXPERIENCE at it. As an illustrating example, Sun's "utility computing" business was also a PR infused fantasy and ultimately a bust. Yet EC2 just launched and that looks like a winner. Why? Experience. One company's daily revenue depends on making it work and they've been practicing on themselves for years.
So why are you listening to Sun? I've tuned them out.
The best thing that can come from this dynamic languages on the JVM move is the enabling of the "rigid outside liquid center" pattern. You've seen it a dozen times - most good long lived apps are built this way.
You have a small dynamic core that encompasses the "brains" (agile, flexible, dynamic language) of your application coordinating a much larger mass of "muscle" (rigid, inflexible, but high performance code written in C or C++).
Ruby is like this, Python is like this, Smalltalk is like this, Java is kind of like this only the Java language is designed like a RIGID language and thus officially in that class of languages known as a PITA language to work with.
is a example of WHEN NOT TO USE automatic type generation. Bill, if your example of "speed and productivity" is horriby ambiguous code subject to misinterpretation and bugs, you aren't going to convert me. Please provide a better example.
And Todd saying Java is "Broken by Design" without any followup or URLs is unconvincing. Strongly typed languages have been around for a long time. Maybe Todd doesn't like them but they aren't broken. Please elaborate.
I've been coding in Java for years, before that C++, C, Pascal, FORTRAN, assembler, and am interested in exploring new things, but am also sceptical about the "next big thing". Most bad code is not the language's fault, its the programmer's. Sun could have written a bad EJB framework in any language. :-)
Over and over it became clear when the collections classes were examined that the type system was "badly flawed". (Casting is a clue and the "generics" are not a proper fix).
Other dumb things: Primitives and "Wrapper Objects" Static "methods" are C style functions No class object hierarchy Function calling rather than message sending semantics No closures "Type" implies protocol. Ugly syntax. Cargo cult looping constructs.
Though it's interesting to see how many of the older critiques are actually critiques of the C syntax that Java borrowed, or are obsolete with new technologies or programming trends. For example, one critique complains that forcing all import statements to go at the top is tedious and bad, but modern IDEs make it simple and it's now considered good practice to make imports super-explicit and easy to find. I may get inspired to write a response to some of them.
criticizes the Collections for being not strongly typed enough with the optional methods. While the recent criticisms of Java are generally that it is too strongly typed relative to Perl, Ruby etc... Can you guys make up your mind? :-)
>criticizes the Collections for being not strongly typed enough with the optional >methods. While the recent criticisms of Java are generally that it is too strongly >typed relative to Perl, Ruby etc... Can you guys make up your mind? :-)
That's not really contradictory. Its Java that couldn't make up its mind. They started out with a half baked type system based on C++'s half baked type system and did a bunch of stuff and got to collections and went "oh no!".
So the solution? Typecasting! But that's not a solution its a workaround. It exposes a huge hole in the type system. The compiler endorsed macro system that is "generics" is a better bandaid - but still a bandaid.
The articles have in common that they all think Java's type system is lame given experience with both dynamic typing sytems and inferencing ones (like ML) and even optional typed ones like Strongtalk.
>criticizes the Collections for being not strongly typed enough with the optional >methods. While the recent criticisms of Java are generally that it is too strongly >typed relative to Perl, Ruby etc... Can you guys make up your mind? :-)
That's not really contradictory. Its Java that couldn't make up its mind. They started out with a half baked type system based on C++'s half baked type system and did a bunch of stuff and got to collections and went "oh no!".
So the solution? Typecasting! But that's not a solution its a workaround. It exposes a huge hole in the type system. The compiler endorsed macro system that is "generics" is a better bandaid - but still a bandaid.
The articles have in common that they all think Java's type system is lame given experience with both dynamic typing sytems and inferencing ones (like ML) and even optional typed ones like Strongtalk.
Previous Topic
