David Herron's Blog

February 2006 Archives

Scripting languages and Java

Mustang, a.k.a. Java SE 6, is getting ready to bolt out of its corral. We've done a lot of good things in Mustang. There's a recent article published on devx.com giving an overview of changes in Mustang, plus we've published the official docs which you can browse.

There's one new feature that I want to talk about today, and that's the support for scripting languages in Java. I have some personal interest in language interpreters, from working on several projects involving interpreters. In my college years I wrote a BASIC interpreter (it's in the comp.sources.??? archives from around 1986 as "BASIC interpreter, needs work"). In the early 90's I spent a lot of time working with TCL. And I also got to do a little work with porting Microsoft's vbscript/jscript interpreter to Unix (I used to work for Mainsoft). And then, of course, I've been with the Java team for nearly 8 yrs (to be exact, Java's not exactly interpreted).

One attractive meme in all these different languages is the ability to take the same program and execute it on multiple operating systems. With the right software. I see this as being about freedom. There's the vendor lock-in that occurs when your software is compiled to machine instructions for a given operating system. But if your software is written in a language/runtime which offers portability, you have the freedom to choose a wider set of computers and operating systems.

How is this portability implemented? There's an architectural pattern that's followed in many "interpreted" languages. The language is implemented with two major modules. The first is a compiler to translate the high level language to byte-codes for a virtual machine. The second executes those byte-codes. Of course there might be other modules, such as to interface operating system facilities to a higher level abstraction.

In a few cases a language might be interpreted directly from the program text. This was the case for early versions of TCL, where the program text was reparsed each time a statement was executed. Last time I looked the TCL runtime converted TCL expressions to a string of byte codes for execution.

Obviously there's a huge efficiency gain when a language is executed from byte codes, rather than having the program text reparsed each time a statement is executed.

In the case of Java the intermediate language is the well documented class file format. Sun's Java implementation takes the class files and Hotspot will dynamically decide which parts are executed most often, and compile those parts for the given CPU/OS currently executing. This is why I earlier said Java is pseudo-interpreted, as some parts of your application will be interpreted, and other parts will be machine code instructions running at native execution speed.

Mustang offers an exciting possibility for language authors.

Think about the architectural pattern I described. Anybody who has a hankering to write a new language has two problems. One is the language design, and the other is the most efficient way to execute programs written in that language. What Mustang offers is a way for a budding language designer to skip that second step, and just focus on their language design.

Consider: jrunscript

One of the options is "-l language", and it's silent on which languages are supported. That's because the underlying technology allows "any" language to be plugged in. By default the javascript language is included in the JRE. The javax.script package, new in Mustang, allows you to plug in other languages. (see the javadocs)

I'm not going to go into much depth with this feature, if only because I've not yet used this feature. The language author embeds their language using the ScriptEngine interface, using the service provider mechanism to tell Java about their ScriptEngine. The system allows for multiple scripting languages to run inside the same Java virtual machine.

Apparently it's a little too soon, still, for many languages to be implemented with the javax.script interface. Doing a web search I see some activity. For example BeanShell can hook up with javax.script. An exciting possility is for a PHP/javax.script implementation (see php-java-bridge).

UPDATE: Stevey's JVM Language Soko-Shootout is the beginning of some interesting research into JVM's support of other languages. Unfortunately he was hired by Google, which cut short his research.

Bendy classes and dynamic programming

Jack Herrington has published this article: Going dynamic with PHP claiming to show some things PHP can do which Java can't.

Okaaaay... This is another of the articles in the meme that dynamic languages are great, and rigid languages are uncomfortable. I don't know if I got the analogy right this time, let me know please?

The problem he poses is about implementing the database interface classes. The traditional method might be to write one class per database table, expose get/set methods for each field, etc. You'd end up with a tedious implementation and a lot of typing of highly similar code. He poses three possible solutions, and claims that PHP implements the best of the three.

One problem with the article is there's more than three possible solutions. The problem with the proposed solution is it doesn't give early warning of broken code, leading to greater expense to fix coding problems.

Whever a writer presents a problem .. and then presents a selected list of solutions .. the writer (maybe unknowingly) is trying to limit the readers thinking to the given solution set. But what if there are other solutions the author doesn't present?

What's another solution? One that comes to my mind is to use Java's annotation feature. I am imagining an annotation you attach to each field in the object which declares the database column corresponding to the given field. A class-level annotation would declare the table to which the class corresponds. I can imagine this class could be autogenerated from the database without the programmer writing code. The only actual methods to write would be get/set methods. You could have a persistence library which introspects the class looking for those annotations centralizing the JDBC code to the library rather than spreading it among the database classes.

Seems pretty simple ... and it appears hibernate makes it even easier than that.

Of course using annotations requires JDK 5 (or later).

As simple as this approach might be to implement, it doesn't offer some flexibility Jack Herrington's article discusses. Namely, dynamically generating the object interface at runtime. I suppose that's even simpler, maybe. Certainly it lets the developer more quickly implement the code. But, I think this solution has problems of its own which Jack skips over.

The problem with a dynamically generated object interface is you don't know about any code mismatches until runtime. Meaning, you might not discover certain bugs in the code until the application is out in the field.

With Java you have compile time checking, and if some code refers to a field or method that's no longer there the program will fail to compile. That may seem burdensome but that's also A Good Thing. It tells the programmer up-front about a coding problem, letting the programmer more quickly fix it. It's well known that quickly identifying a bug makes it much less expensive to fix the bug than if the bug is identified out in the field (e.g. a program crash) and has to wend its way back through technical support and bug triage before it can be fixed.

With dynamically bound fields or methods ... okay, take this scenario in mind. Some code in the application refers to a field/method in a class. Then later there's a revamp of the code, a database table changes, some columns are deleted, and the class no longer has the matching fields or methods. Now, take your application that used that spiffy dynamic binding which made it a lot easier to do the initial implementation ... and what will happen. Will the programmers find all instances of references to those fields or methods?

I can almost gaurantee you the programmer won't. But the compiler would find them all -- that is, if the compiler were written to do compile time checking, like Java's is.

UPDATE: Apparently I missed this, but Jack says towards the end of the article the technique he presents isn't without its problems.

Regression contest prizes

Three weeks ago I launched the Mustang Regression Contest. The grand prizes are five Ultra 20 workstations, which are to be awarded for the "best" regressions submitted during the contest. The other day Ray Gans and I brought them from the a storeroom in the Menlo Park campus to one in the Santa Clara campus. So while moving them I thought to post a picture to show you guys what you're competing for.

While moving them I couldn't help but think about a conversation I had with a colleague while serving "booth duty" at Java ONE. This particular time, in the booth I manned, our job was to hand out a "Java Junkie" t-shirt in exchange for the person taking a survey. The t-shirt was very popular which meant we were spending all our booth duty time handing out the t-shirts rather than having the insightful conversations about java features or technology that draws me to spending time in the booths.

I and my booth-mate were both thinking, here we are, highly experienced software engineers, years of software engineering talent, and our job is to hand out t-shirts. Back when I was in college, pulling all-nighters writing some toy compiler or whatnot, little did I think that 15 years later I'd be handing out t-shirts at a trade show or, in this case, moving boxes from one campus to another.

But, that's what we do in the "real world". In the "real world" our work may take us to unexpected places. What I remember imagining I would be doing in the "real world" was probably influenced by the world my professors inhabit. The professors inhabit a world of theorems, or writing papers, or conducting research, so looking to them for clues on what work in the "real world" is like only led to confusion. They don't live in the "real world", they live in academia, which is a different real world than commercial software engineering.

Where this line of thinking leads is that, in commercial software engineering it's not entirely about the technology. And the example which popped into my mind is the Beta VCR I used to own, which got supplanted by the inferior VHS technology. The problem with the Beta VCR is, of course, it never got out of Beta. Well, seriously, the real problem with Beta versus VHS was not the technology but the marketing.

Which means that in a commercial venture, and this is true for commercial software ventures just as it is for anything else, one has to do marketing activities.

Work in commercial software engineering is not just rarified technology development. Sometimes your work leads you to running a contest, manning a booth at a trade show, making customer visits, inhabiting discussion forums, making blog postings, etc. Which just goes to show that what prepared me the most for my work in the corporate world was all the hours I used to spend reading and writing Usenet postings. (FWIW, I used to be on the Usenet backbone committee)

Roundup of desktop java improvements in Mustang

Some nice comments on Mustang compatibility

Weiqi Gao has a blog posting with early impressions on Mustang, a.k.a. Java SE 6. In all it's very positive talking about several applications he tried which worked fine.

He talks a little about the adoption rate for Java 1.5 (a.k.a. Tiger), and says "I have a feeling that the lack of a 5.1 version has really hurt the adoption of JDK 5".

I want to mention that, what would have been "5.1" are the update releases. If you go to the JDK 5.0 download page at http://java.sun.com/j2se/1.5.0/download.jsp you see it saying "JDK 5.0 Update 6". Yes, there have been six updates to JDK 5.0 since the FCS, and the releases happen approximately every 2 months. The fixes in these update releases are the same sort that had previously gone into 1.4.1, 1.4.2.

If you're one who says "never trust version x.0 of anything", well, Tiger is past version 5.0 and is at version 5.0_06, and that "_06" on the end makes a world of difference. By our current release policy you're never going to see a version x.1 again, because we're relying on these update releases to fix those sort of bugs.

And, while I'm here, I want to again mention the regression contest. Weiqi Gao is talking about compatibility, the ability to take an application that works fine against a previous Java release and to have it continue working on the next Java release. Patrick Curran is working on the compatibility side of Java, and is now writing on his blog about it. Compatibility is a big part of our work with Java, and that's not just an empty promise mouthed by our management.

One of the ways we measure compatibility is in regressions, which are features which worked in a previous release and no longer work. A rule we follow in determining whether a given release is ready to ship (as FCS) is whether there are regressions. If there are regressions we will not ship. But, let me make that clear, those are known regressions, because if we don't know about the regression then we can't do anything about them.

This is where you come in. I've said this before, where compatibility is really measured is when you run your application against the new Java release. Does the application continue to work? If not it may be a regression in Java. The sooner you tell us about any regressions you see, the greater likelihood it will be fixed in the Mustang FCS. If you do find a Mustang regression, visit the contest web site and enter.

Mustang has gone Beta

An easy way to enter the Mustang Regression contest

Let me give y'all an interesting hint on entering the regression contest ... Suppose your application has a unit-test suite ... Simply run your test suite on a Tiger build (1.5 update 6 is the latest) and then on a Mustang build (JDK 6 build 70 is the latest) and compare the results.

If every test gives the same result on each then that's wonderful. But if some test gives a different result on Mustang than on Tiger, it's time to roll up your sleeves. Does it show a bug in your application? Or does it show a bug in Java?

If you're satisfied it shows a bug in Java, you've probably found a regression. Again, regressions occur when functionality which used to work in a previous release is broken in a later release. WE WANT TO KNOW ABOUT REGRESSIONS, because we want to fix them before making the final Mustang release.

There's more information about the contest here including a link to tne entry page.

Is Java 10 yrs old, or 15 yrs old?

In this weeks javaposse podcast they expressed confusion -- Happy 15th Birthday, Java! (javalobby, and computer history museum), but wait, didn't we just celebrate the 10 year anniversary last summer? What's going on.

Well, what's going on is there's two dates to consider.

One date is when they began creating the Java language. Except, it wasn't yet called Java, but called Oak (supposedly when James began the project, he wondered what to name it, looked out the window, saw an oak tree, and said "what the heck" and typed "mkdir oak"). Also the original purpose for Java/Oak was for settop boxes because there was an RFE floating in the cable TV industry for fancy cable tuners which could perform neat tricks. Java, and Duke, was Sun's attempt to pull some neat tricks. The settop box product was called "Star Seven". And the javaposse gang got that pretty much correct.

The other date to consider is when Java was officially unveiled to the public. That, as I recall, is what we were celebrating last summer. It's either that or, as the javaposse guys suggested, we were celebrating the 10th Java ONE. I coulda sworn we were celebrating the 10th year after Java's unveiling, but now that I think about it I remember John Gage talking about 10 years of Java ONE and having the audience stand based on which was their first Java ONE. I happened to attend the first Java ONE, not because I was on the Java team, but because a then-coworker at Mainsoft (where I worked at the time) was intrigued by Java and arranged for some of the Mainsoftees to attend. That first Java ONE was very small.

They also wondered about this book: Hello World(s) -- From Code to Culture : A 10 Year Celebration of Java Technology. Yes, it does exist and you can even buy it in book stores. I saw it in a Barnes and Nobles the other day. It's a glossy coffee-table style book that describes the evolution of Java, and of course it gushes with positive things to say. In the back there's page after page of names of those of us who have been involved in creating Java. Somehow my name ended up next to Josh Bloch. Sometime in early 2005 an email went around saying something vague about a book, and if you wanted your name in it to send a reply.

And while I'm here posting about the javaposse ...

I really appreciate their mention of the Mustang Regressions Challenge. They said a lot of nice things, and even dispelled some of the misinformation I've seen about this.

It was amusing to realize the word "regressions" doesn't mean to everybody what we're meaning. As one of the javapossean's said, there's some kind of statistics process called Regression Analysis. Again, what we mean is when a feature works in one release of a software product, and is broken in a later release. We really dislike regressions, and we want to weed out as many as we can.

And if that helps you guys do your Regression Analysis for Java to have fewer Regressions, then that's so much better.

The Mustang Regression Contest, and international law

A question that's come up around the Regressions Contest is:- Why are various countries restricted from participating?

This has to do with laws and lawyers. No doubt you'll have seen this in other contests, especially if you've read the fine print. The phrase is: "void where prohibited by law" ...

In designing this contest we went through an interesting and probably excruciating exercise. We got some lawyers to research for us a set of contest rules that were as compatible with as many countries as possible. That turns out to be very difficult because the law governing contests varies so much from country to country, in incompatible ways. The lawyers did the best they could, but there's only so much one can do to harmonize conflicting laws.

Contest home page

Official Contest rules

This work is licensed under a Creative Commons License.