Programming Languages for the JVM

Back before Java became popular, I was a C++ bigot. I programmed in nothing but C++. I lived, ate and breathed C++. If it wasn't C++, it was rubbish. I thought C++ was the alpha and omega of object-oriented programming. I had "operator overloading" for breakfast, "templates" for lunch and "multiple inheritance" for dinner, and I always went back for seconds.

Then a funny thing happened. I got a new job at another company as a C++ programmer. But they pulled the old bait and switch. Once I started working, someone suggested writing a good portion of a large project in a scripting language. I protested - I would not condescend to program in any other language but C++.

Shortly after I started at this new company the following edict was put forth: "Thou shall use a scripting language." Thus I was forced by management to write a good portion of the project in a high-level scripting language. They told us to glue components written in C++ together with this scripting language (in addition to writing components in C++). At first I hated it, as any self-respecting C++ bigot would. Then, gradually, the productivity of my team - and me - skyrocketed.

I became a true believer in scripting languages. The more I saw productivity climb, the less I coded in C++ and the more I coded in the scripting language. Granted, the scripting language had some limitations, but for many tasks it was just what the doctor ordered. Have you had a similar experience with a scripting language? If not, perhaps you should.

Scripting Languages
Many scripting languages are either object-oriented or object-based. Almost all of them are interpreted and use late-bound polymorphism. This makes scripting languages extremely dynamic and easy to program, which is essential for rapid application development (RAD), gluing components together and prototyping projects.

There's a fine line between a scripting language and a programming language. For example, Smalltalk is an extremely dynamic interpreted language, yet I dare you to call it a scripting language to a Smalltalk evangelist - you'll probably get punched in the nose. When I refer to scripting languages, I'm referring essentially to languages that are mostly interpreted and extremely dynamic, that is, they employ late-bound polymorphism and dynamic typing.

Java for the most part is a glorified scripting language - granted, a scripting language on steroids. Unlike most such languages, however, Java uses statically typed polymorphism; thus it has been called a hybrid language. At first this may seem like a disadvantage, but as it turns out, statically typed polymorphism is great for systems programming, framework definition and component development. Java's design by interface is truly great for large systems and frameworks.

Calling Java a system programming language to a system programmer is likely to evoke a nasty response (similar to calling Smalltalk a scripting language to a Smalltalk evangelist). However, don't view Java as a system programming language in the classic sense. Instead, view it as a virtual system programming language for a virtual system, that is, a virtual machine: the Java Virtual Machine (JVM). And Java, like its scripting language cousins, can be very dynamic - not as dynamic as Python, Smalltalk, and their ilk, but more dynamic than C++.

The funny thing is that the parts of Java that make it a great system language are the same parts that make it a mediocre scripting language. Don't get me wrong. Java is a great language. I jumped on the Java bandwagon as soon as I could hop a ride, and it's been good to me. However, Java is not as easy to use as scripting languages are. You really need a glue language in your toolkit. Build components and frameworks with Java, but glue the frameworks with a scripting language.

Don't fret! There's a history of using high-level scripting languages with system languages. Thus it's no surprise that there are scripting languages for Java. (Note: Don't get hung up on the term scripting; you can replace it with programming.)

Scripting Languages and System Languages: A Marriage Made in Heaven
For example, on UNIX systems many programmers program in C and C++, then glue modules together using higher-level shell programming (KornShell, C Shell, Bourne Shell, etc. Thus C is the system language and the shell scripts are the glue.

Another example: C and C++ programmers on UNIX often use Tcl (a scripting language) to do their GUI programming and glue together classes and libraries written in C++. C++ is the systems language and Tcl is the glue.

At other times C and C++ programmers will use Python as a control language - Python often ships with the UNIX system preinstalled. Python is easy to extend with a C. Again, C is the system programming language, Python is the glue.

The most prevalent example of an object-based scripting language is Visual Basic, which is often used to glue together COM components written in a variety of languages - C++, Delphi, and so on. Thus C++ is the systems language and Visual Basic is the glue.

Scripting Equals Increased Productivity
For more information on scripting languages and increased productivity check out the paper "Scripting: Higher Level Programming for the 21st Century" by John K. Ousterhout ( www.scriptics.com/people/john.ousterhout/scripting.html). The paper basically states what I have experienced: namely, a sharp increase in productivity by using a higher-level language. The paper states that a scripting language is five to 10 times more productive than a strongly typed language like Java.

Scripting languages, however, don't replace a system language; they augment it. And five to 10 times more productive seems a little high to me. My personal experience has been two to three times as fast, depending on the application. Your results may vary.

Many developers are accustomed to higher-level languages like JavaScript and Visual Basic. Thus they may be more comfortable with them when migrating to the Java (i.e., the JVM). Often, especially for prototyping, a scripting language can be a more productive environment. In addition, Java programmers are hard to find; good Java programmers are nearly impossible to find. There's a lot more demand than supply.

You may want to use a scripting language for the following reasons:

You can embed scripting languages into your application so that users can extend it. You can use the dynamic interactive nature of scripting languages to inspect objects at runtime to debug an application.

The best way to learn the Java API is by experimenting. Working with dynamically typed, interactive scripting languages allows you to experiment quickly. Even though the Java API is documented well, it helps to try things out interactively. I do this all the time.

The properties listed above make scripting languages ideal for prototyping. Once you start using an interactive, dynamic scripting language, you won't stop. It's addictive and productive.

Java Was Built to Be Scripted
Java has wonderful features that make creating scripting languages easy. The class reflection and bean introspection APIs are a great basis for integrating these languages. Essentially, the scripting language can get metadata about a Java's class properties, events and methods. The scripting language can then use this metadata to change properties, handle events and invoke methods.

To learn more about introspection and reflection see the API documentation under java.lang.reflect.* and java.beans.Introspector. I've had the pleasure of doing metaprogramming with COM, CORBA and Java. Out of the three, I much prefer Java's reflection and introspection mechanism and APIs. It's a lot easier to use.

Scripting Languages for the Java Virtual Machine
Some may feel that the only language for the JVM is Java. They're wrong. Like many platforms (and Java is very much a platform), the JVM has many languages. And the list of those that work in the JVM seems to keep growing. Mixing Java with a scripting language for RAD is a powerful one-two punch that could make your next project fly.

Introduction to a Regular Column
What's been said so far is to welcome you to a new column in Java Developer's Journal. This column will focus on topics like other languages for the JVM, integrating Java with mainstream scripting languages like Perl and Python, special-purpose languages (rules, etc.), creating JavaServer Pages (JSP) in JavaScript and Python, SWIG, integrating with C libraries, and others. This will be the resting place for non-Java-language JVM-related topics in JDJ.

The Column's First Series
To kick off the column's birth, I'll start with a multipart series on programming and scripting languages that run in the JVM. These languages are Java-friendly, and often run in the JVM in both interpreted mode and as compiled Java classes, that is, they can be compiled to Java bytecode. These languages integrate well with Java classes and beans via the introspection and reflection APIs. They're great for prototyping, gluing together Java components and rapid application development. All of the languages are 100% Pure Java.

A lot of languages work in the JVM. Rather than just pick the ones I think are best, I want to solicit your feedback on which ones are most important to you. You can take part by going to the JDJ forum and voting. However, I've made a short list of languages that I think you should consider.

  1. JPython (Python)
  2. Rhino (JavaScript-like)
  3. Instant Basic (Visual Basic clone)
  4. JACL (Tcl)
  5. BeanShell (Java-like)
  6. Bistro (Smalltalk-like)
  7. Skij (Lisp/Scheme-like)
Everyone has a favorite language, and this list represents the most mature and common languages for the JVM. Most are easy to obtain, and quite a few are open source (GPL or GPL-like licenses). If you feel I'm missing a major language, let me know. We love feedback here at JDJ. The following sections give some background on each language.

Short Drill-Down of Different Languages

The above-mentioned languages are just suggestions. If your favorite isn't listed or none of them tickled your fancy, then go to Robert Tolksdorf's comprehensive list of programming languages for the JVM at http://grunge.cs.tu-berlin.de/vmlanguages.html. Over 100 languages are listed! Find one you like and tell us convincingly why it's the best thing since sliced bread. We don't want to miss the next great thing.

Convergence Dynamic to Static, and Static to Dynamic Typing
It's interesting to compare BeanShell and Bistro. The former is essentially a Java variant that has added dynamic typing with optional static typing. The latter is a Smalltalk variant that has added static typing with optional dynamic typing. Java and Smalltalk are on both ends of the typing spectrum; these variants have crossed the chasm to provide a mix of dynamic and static typing (see Figure 1).

BeanShell and Bistro are on the right track. The most popular scripting language of all time, Visual Basic, also has support for both static and dynamic typing. Note that JPython has yet another way to fill in this typing gap, as we'll see when we cover JPython in the first article in this series.

Rosetta Stone Examples for Programming Languages
This article series will give specific examples that demonstrate how scripting languages can be more productive. Some are great for certain problem domains; the series will highlight the languages working in those domains. Other languages are general purpose; the series will show all of the languages working in a general-purpose manner.

The first part in the series will cover scripting languages in general, and will introduce JPython. Every article (including the first) will demonstrate several sample applications as follows:

For comparison, each sample application will have a corresponding Java implementation. Each part in the series will reimplement each sample application in the language covered in that issue. Since people come from many different programming language backgrounds, these applications will be like a Rosetta stone for programming languages that work in the JVM. The series will be very code-centric and hands-on.

For example, in the first article the sample applications could be implemented in JPython and Java; in the second article, in Rhino (JavaScript) and Java; in the third, in Instant Basic (Visual Basic clone) and Java. And so on. The real order and number of articles will depend on the feedback we get. You, the reader, will decide the order and importance of the language. Also, we're asking you to evaluate the languages in the article to pick the best ones.

Criteria for Judging the Best Languages

  1. Ease of use
  2. Embedability
  3. Resemblance to parent language
  4. Unique features
  5. String parsing
  6. Productivity
  7. Working well with Java classes
  8. Development environment/debugging
Let's drill down on the above criteria a bit.
© 2008 SYS-CON Media