Skip navigation
ANNOUNCEMENT: is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write. got an OLPC for the holiday season. No, it wasn't for the Horstmann twins—after all, it is one laptop per child, so the child must be myself. I got it through the “give one, get one program”. For $400, I got mine and a much more deserving kid somewhere out there got one as well. (Hurry if you want to get yours—the program ends today.) years ago, in Chapter 1 of the first edition of Core Java, Gary Cornell and myself wrote this in the section entitled “Common Misperceptions about Java”:

With Java, I can replace my computer with a $500 “Internet appliance.”

Some people are betting big that this is going to happen. We believe it is pretty absurd to think that people are going to give up a powerful and convenient desktop for a limited machine with no local storage...We can envision an Internet appliance as a portable adjunct to a desktop. Provided the price is right, wouldn’t you rather have an Internet enabled telephone with a small screen to read your e-mail or see the news. Because the Java kernel is so small, Java is the obvious choice for such a telephone or other internet “appliance.”, now I have my $200 internet appliance. It works like a charm. I can browse the web and read my email. The keyboard is not great, but it is spillproof, which is just the thing when reading the news while the Horstmann twins are up to no good. Here is what I love about the OLPC:

  • The price. It's a steal at $200.
  • The form factor. It is small (but not too small) and rugged.
  • The screen. It morphs from a standard backlit color screen into a grayscale screen that can be read in bright sunlight—very nifty!
  • The silence. There is no fan and no whirring hard disk.
  • The openness. I don't have an epic power struggle against a manufacturer who cares more about “digital rights limitations” than my ability to use the device.

But Gary and myself were wrong in one teensy detail. The internet appliance is not Java-powered. The OLPC uses Linux, and the browser is Firefox, converted to the kid-friendly “Sugar” environment.

I am not too thrilled about that part. I'd love to put more software onto the OLPC, but not if it means doing it in C++ and some goofball X11 window manager. I am glad that other people don't feel as squeamish about these things as I do, but it made me think about the role of Java in this new class of devices.

I really believe that the OLPC, the Asus Eee, and the Everex gPC, are the forerunners of a new category of devices that are truly useful and important. What would it take for Java to be an essential part of these devices?

First off, these are not crippled ME devices. I ran Java SE apps on the OLPC (see below for details), and the performance was ok for JEdit and the Violet UML editor. I didn't try Netbeans :-)

So, why didn't the OLPC folks put Java on the machine? A major reason is surely that Java was not open source software when the OLPC was designed.

Then there is the issue of SE bloat. Or maybe not. I thought about what parts of SE one could place into separate extension libraries. There is RMI/CORBA. And the sound stuff that very few people use because it isn't very good. What else? Maybe SQL, web services, scripting, NIO? Beyond that, I don't think one can drop entire packages. Some crypto is needed by platform security. Some XML is used by logging and preferences. Last Java One, I heard some people say that they were looking into this issue, and I am curious what they found. My hunch is that there may be a smallish core for console applications, but as soon as you let in Swing, you are probably at 2/3 of rt.jar.

Anyway, there has been this huge effort to make Java play nicely with Vista's throbbing buttons. Maybe that's yesterday's battle. The OLPC shows quite starkly what you can do for $200 if you dispense with those throbbing buttons and instead give people something more useful for a specific task—such as browsing the web around the house and in the garden. I once read that when electric motors were first sold, they were expensive high-tech equipment. People would buy one motor that could be attached to various devices. Maybe one day people will chuckle when they hear about the personal computer era when we bought one computer to run all sorts of programs on a single device.

This appendix contains the gory details—skip it if you don't have an OLPC.

To install Java, go to a non-XO machine and visit

Download "Linux RPM (self-extracting file)". Usescp or a USB stick to move to the XO. Then ssh into the root account of the XO, and run

chmod a+x jre-6u3-linux-i586-rpm.bin 

(The exact name may differ.)

By the way, here is the result of running dfbefore

mtd0 1048576 346408 702168 34% /

and after

mtd0 1048576 428820 619756 41% /

On another computer, use ssh -X to get a shell on the XO. (If you use Cygwin, be sure to have X11 installed.) Try running a Web Start program:


If you get an error message such as

java.lang.UnsatisfiedLinkError: /usr/java/jre1.6.0_03/lib/i386/ cannot open shared object file: No such file or directory

then run

yum install compat-libstdc++-33

You should now be able run Java applications and have them show up on your other computer.

Unfortunately, on the XO itself, the Matchbox window manager seriously breaks Java applications. JEdit shows up, but the main window is too small and the menus and dialogs are at the wrong places. Violet doesn't seem to work at all. This will presumably get worked on in the future.

I then tried to get the Java Plug-in working in the usual way:

cd /usr/lib/mozilla/plugins/
ln -s /usr/java/jre1.6.0_03/plugin/i386/ns7/

Unfortunately, the plug-in didn't show up when visitingabout:plugins

I got these errors in/home/olpc/.sugar/default/logs/org.laptop.WebActivity?-1.log

LoadPlugin: failed to initialize shared library [ cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library [ cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /usr/java/jre1.6.0_03/plugin/i386/ns7/ [/usr/java/jre1.6.0_03/plugin/i386/ns7/ undefined symbol: _ZTVN10__cxxabiv121__vmi_class_type_infoE]

I got rid of the first two error messages by making symlinks/usr/lib/ -> and/usr/lib/ ->

But the third message persisted. Apparently, I am not the only onewith this problem, but I could not find a solution. (Setting JAVA_HOME in/etc/profile didn't help.)

Just to make it very clear—do not buy an OLPC today to run Java applications. My experiment demonstrates that the machine has sufficient power to do so, but the software needs work. has been another flurry of discussions about closures in Java and minor language enhancements, together with the usual flurry of “leave the language alone” lamentations.

Conspicuously absent from this discussion was my pet unappreciated language feature, native properties. Properties get no respect. Every few weeks, another blogger comes along and says “we need a property syntax”, proposes something, and moves on to greener pastures.

At best, properties are dull. Programmers who work with Swing, JPA, JSF components, XMLEncoder/Decoder, and other "beanish" technology cringe every time they have another class with a bunch of annoying trivial getters and setters. But it isn't the end of the world. They can cringe and keep on coding. How much gratification is there in making people cringe less? Apparently not enough to put together a proposal that deals with all the pesky details.

devilBut it gets worse. While worrying about pesky details, the hapless property syntax designer needs to fend off a barrage of attacks from the inevitable naysayers (“What's the big deal...Eclipse writes the getters and setters for me”) and the OO purists (“Properties are the tool of the devil...they break encapsulation”).

As a result, most of the effort about properties has been half-hearted and scattered about in the blogosphere. There was never enough momentum to arrive at a consensus. Nikolay Botev, a computer science student at SJSU, has done something about that. In his independent study project, he collected every reference about properties he could find, in Java and other languages, and put all the information into a Wiki. He also added nifty voting buttons to the Wiki. everyone else is madly milling about at the mall, please take a few minutes to see check it out: If you are a properties enthusiast (you know who you are), please make an account and add to the Wiki.

Happy holidays!

I am a reviewer for Java One. I have about 350 project proposals to plow through and not enough time to give each of them justice.

One submitter proposed a talk on "Doing your own language". The outline talked about parsing, abstract syntax trees, and generating code. I flippantly commented "A DSL is not a DYOL. You use a DSL precisely because you DON'T want to write another parser."

Of course, what I had in mind was the recent trend of embedding DSLs in programming languages such as Groovy and Scala. (See this blog for Groovy.)

The submitter happened to be a reviewer in another Java One track, so he was able to see my comment, and he was not happy. He emailed me: "I feel strongly that this is mistaken. Most DSL's originate with domain experts, who become weary of using general-purpose languages to work within their domain concepts and patterns. Many of us are the beneficiaries of such efforts, but DSL's don't spring forth from nothingness."

Now here is my thinking. Technically speaking, the submitter is right. A DSL is simply a domain-specific language, and the term does not imply an implementation strategy. You can use a parser and code generator, as was customary in the past, or you can embed the language in a larger host language, by rigging the metaobject protocol, doing tricks with closures and operator overloading, or whatever.

I just think that the embedded approach should be the approach of choice when it is at all feasible. After all, the toolbuilders are busy giving us tools for JRuby, Groovy, and Scala. If your DSL is contained in one of these languages, you get to leverage those tools. If, on the other hand, you start a new language from scratch, you might get a marginally prettier syntax, but you now have to build up a whole tool chain.

Consider JavaFX Script. (Doesn't that just roll off your tongue?) It has a bunch of nice features for building GUIs, such as thebind and dur operators. But it is yet another programming language. People need to learn it, they need to build tools for it, they need to learn how to use those tools. Sadiya Hameed, one of my graduate students, is implementing the key features of JavaFX Script in Scala and Groovy. The syntax is a bit clunkier, but not by much. Either of them would have made a fine host for a FX DSL.

What do you think? Am I being naive? Is it just too awkward to shoehorn DSL syntax into the Procrustean bed of a host language? Is it crazy to have a program with ten mutually incomprehensible DSLs in Scala or Groovy? Or has the time come to say "no" to building more parsers?