The Cool Stuff Keynote

My mind wanders during most keynotes, but I always enjoy James Gosling's cool stuff keynote on the last day of Java One. No marketing, just one amazing Java-powered piece of hardware or software after another. Here is what caught my attention:

• Tor Norbye demoed the JavaScript support in Netbeans. Here is a man who can give a better presentation typing code on the screen than most people can with the slickest slides. (Not wanting to name names [Hi, Ed...] but this is not something most presenters should try...) He types a line of code, something cool happens effortlessly, whoops, he makes a typo...no, that wasn't a typo but a calculated manoeuver to show off error handling. A few years ago, I saw him briefly flustered by a bug which he fixed on the fly, talking all the time as if nothing happened, and then he continued the demo.

  Those Java-powered micro-sensors draw so little energy that they can be powered by ambient vibration. The presenter gave one convincing application: sensors in beer coasters that would communicate through the mesh network which glasses were empty or not cold enough. I suppose the sensors ask each other: “Do you come here often?” A bit off-topic...so many engineering colleges persist in teaching C++ to freshmen because obviously nobody would use Java for embedded development. With the sensors, smart cards, and industrial controls that we saw today, I am not sure how much longer that will be the wise choice. My guess is that the users of those technologies are willing to pay for the Java layer because it gives them ease of development, my personal theme of this Java One.

• James Gosling asked the fellow who showed off the Java-powered Pulse pen the exact question that was on my mind: “Why would anybody want a computer in a pen?” But the demo was very impressive. Check it out on the video, starting at 56:15. Too bad the docking requires Windows.
• The keynote ended with some big science: JMars and the use of Java at CERN. When Gosling visited a control room at CERN that was filled with monitors, he asked whether they had any Swing apps. Well, all of them were Swing apps.

Concurrency

Unfortunately, I managed to miss two good talks by Brian Goetz, which does not stop me from pontificating about concurrency, of which I know very little. Check out the excellent slides for TS-5515 and TS-6206. TS-5515 is about the fork-join framework that lets you parallelize certain tasks (such as searching or combining array elements) with a fairly reasonable syntax (which, BTW, would look quite a bit more reasonable with closures). The reason I am getting concerned about this issue is neatly summarized in the overview slide of TS-6206:

The hardware, the OS, and the JVM are ready for large numbers of cores.

The languages, the tools and the programming community at large are not ready for large concurrent programs.

So... good luck, guys!

Last year, Brian had suggested that I check out actors and software transactional memory. I managed to learn a bit about actors, by the expedient device of assigning my students lab work with Scala actors.

Actors share no state...except when I am a knucklehead. The Scala actors are closures and—Josh Bloch will love this one—more than once I accidentally captured a variable from an enclosing scope in an actor. Ok, they don't share state, and they communicate by sending messages. So, you break up your task into actors, each of them does a bit of work, and then they send a message to some other actor that combines the results. How does it know when it is done? You send some other message with a total count. It takes a bit to get used to it.

I then solved the task with Java locks—tedious as usual, and the nagging feeling that I overlooked something, as usual. Finally, I used java.util.concurrent. That was pretty easy...for me. Judging from some very blue-collar comments on the class discussion group, some of my students had a much harder time with the Java constructs than with actors. So, maybe actors are good, and in Scala, they can certainly scale. But concurrency utilities are also good, if you know what you are doing. (Buy Brian's book...)

In the presentation, Brian writes: STM (Software Transactional Memory) is a not-yet-here technology that takes locking decisions out of the users hands.

• Commonly compared to "garbage collection for concurrency"
• With a name like that, who wouldn't want it?
• Despite widespread enthusiasm, still a research subject

I'll suppose my students will learn more about that next year :-)

Web Services...Not!

When SOAP web services first appeared, I thought simple...object...who wouldn't want them? Well, when I was bombarded with JAX-this and WS-that, when all I wanted to do was get some stuff from a server, I felt like those people in the “future Java features” BOF. I knew I wanted something...just not that. I looked at the TS-5425 slides to see whether REST would save me, and I am cautiously baffled.

So...here is my test to see when web services have truly arrived... Today, being a packrat, I downloaded all the presentation PDFs. I manually logged in to the schedule builder, queried for all sessions, did View Source, saved the source to a file, and ran

for f in `grep -o "/[^/]*.pdf out.html` ; do echo wget --user contentbuilder --password doc789 http://www35.cplan.com/cb_export/$f ; done

I know that web services have truly arrived when that most pathetic of tools, Sun's schedule builder, publishes a web service (SOAP or REST—their choice) that lets me get the schedule data as objects and stash away the presentations, without scraping HTML.

In the meantime, if anyone has a pointer to some tool that records browser activity over multiple pages and gives me Java code to replay it (for HTTPUnit or something similar), I'd be very grateful. I have to do HTML scraping all the time with the IT systems at my university. Nobody there is telling me “just call this web service”.

What Does It All Mean?

Another Java One is over. I had a great time meeting a lot of interesting people, I learned a lot, and I think it is an excellent conference even when there are no huge announcements or great surprises. Here is my personal take-away.

• Incremental improvements. One of Germany's great post-war politicians, Herbert Wehner, likened politics to the tenacious drilling through thick pieces of wood. The Java community has that tenacity. Bad stuff gets fixed, and good stuff just get better every year. If you hated Java technology X, have another look. Chances are it is much better today. The Swing app framework, JPA 2.0, Web beans, ever more amazing IDE support, are all very good at reducing drudgery and increasing productivity.
• Multiple languages on the JVM. As much as I would personally like to see more vigorous evolution of the Java language, I can appreciate that the majority of Java users don't share that eagerness. Mixed-language use will become a fact of life. It is just a matter of time when I'll start a project in my IDE and, instead of choosing “Java project” or “Scala project”, I'll check multiple boxes.
• Healthy skepticism, transparency, and community. As an Apple developer, you better like Kool-Aid. As a Windows developer, you are stuck with what is handed down from the top. In Java, you don't have to love everything, decision making is by and large not a black box, and the community gets to participate.

Nimbus

The presentation on the Nimbus look and feel was packed. Nimbus is a pretty L&F, and it will be the standard for Java FX. Everything is vector-drawn, so it will scale nicely to high-resolution displays. (Check out this nifty sampler.) I would like to tweak the colors a bit, perhaps make the nimbusSelection less green. In a Java program, or in a L&F JAR, I can do that by calling UIManager.put("nimbusSelection", new Color(...)). I asked what the story for end-user tweaking was, and was told that I'd have to edit swing.properties. Ok, but how do I specify a color?

JSF 2.0 (JSR-314)

The JavaServer Faces 2.0 presentation was also packed. Ed Burns and Roger Kitain listed some of the pain points (which I amplify a bit):

• Component authoring is too hard
• Component kit producers had to invent mechanisms for resource loading, AJAX, that sometimes conflict with each other
• Configuration is way too tedious and dispersed over too many artifacts
• The need to frequently redeploy, and the “stack trace from hell” are productivity killers

JSF 2.0 will be based on facelets, which should really help with error messages.

There were demos of a page description language and the ability to author components using Groovy (see also this blog), and also some AJAX stuff that went over my head.

There was no information about how configuration will look like. Hopefully, we'll get a Seam-like navigation option and annotations for managed beans. Or better, Web beans. I asked Ed about the strategy for Seam-like Web beans, but it all seems still very much in the planning stage. It is all supposed to be done by Java One 2009, so hopefully things will get moving soon :-)

Blue-Collar Types

When discussing the complexities of wildcards and closures, the issue of types kept coming up. I really like compile-time typing. It enables the compiler to catch stupid mistakes, and it enables the IDE to do auto-completion. Of course, there is a tradeoff: I can't share code like the duck-typers do. For example, no

max(x, y) { return x < y ? x : y }

But I don't want to catch everything at compile time if the cost is too high. For example, C++ checks for const at compile-time. It is a pain in the rear, and Java wisely decided not to do that. I am not sure that the various experiments with compile-time checks against unintended null pointers are worth the trouble. I am not even sure that checked exceptions are so great. In particular, I am mightily tired of propagating the InterruptedException.

I find that Java arrays (with covariance and the array store exception) are a reasonable compromise. A number of people who feel strongly about this gasped when I expressed that sentiment, admonishing me that this is unsound. Well, life is unsound.

Every language makes tradeoffs between compile time and run time checking. I think with generics, we may have tried to check too much at compile-time. Consider this blog by Alex Buckley where he explains why we can't have a generic new T(). The type system cannot ensure that there is a no-arg constructor. Ok, but that doesn't mean that we can't have the feature. One could make a run time check. My feeling is that the type system should be my servant, not my master.

Closures

Martin Odersky and I chatted about the wildcard syntax and the history of generics. He said that the Sun folks approached the introduction of generics very cautiously because they did not want to repeat the disaster of inner classes! At the time, inner classes were perceived to be a short-sighted reaction to C# delegates, with ugly syntax and initially underspecified semantics. Indeed, it took many years for the generics proposal to mature. Wildcards were literally tossed in at the last minute. (The ? super T syntax was suggested at Java One, shortly before the Java 5 release, by someone in the audience of Gilad Bracha's presentation, to replace the proposed T extends ?.)

Now, of course, we have people urging caution with closures so that we don't repeat the disaster of generics.

Alex Buckley told me that he asked in the “future language features” BOF how many people wanted closures. Lots of people, more than half the room, raised their hands. How many wanted BGGA? Maybe 6. CICE? Maybe 6. FCM? Maybe 5.

I ran into Josh Bloch, and he walked me through a presentation about some nasty aspects of BGGA closures. Among them:

• To properly do a control structure where a variable can be either one of the 8 primitive types or a reference type, one would need to declare 9 variants. Make that 81 variants if two variables are involved. Or somehow throw more autoboxing at the problem. I agree this is nasty. I sure wish Java didn't have those 8 primitive types.
• Non-local return is bound to be confusing. I agree. The trouble is that there are two use cases: the “snippet of code” use case and the “control structure” use case, where Java programmers have opposing intuition what return means. I still hope that this can be salvaged. Perhaps by outlawing return outside control invocations, but Neil Gafter doesn't like that.
• Capturing a non-local variable can be surprising. Josh had an unpleasant example where a closure captures a for loop index. I can see how this would be baffling to a programmer who is unaccustomed to closures, i.e. most Java programmers.
• There is no way to implement the Java for loop with BGGA syntax. For example, you couldn't do myFor(int i = 0, j = 0; ...). True enough, but it doesn't bother me. I'd still like with, withLock, doLater, even if they don't have 100% the same syntax as for.

Josh doesn't think that there is much in terms of the “etc.” Is a handful of control structures worth the considerable hassle? He makes a strong case that the hassle is considerable. I still prefer closures over inner classes, and I am holding out some hope that a clearer syntax will emerge.

Scala

If the Java language is increasingly resistant to large-scale evolution, what is a programmer to do? Is it time to plan the escape from the Java prison? Like so many other people, I have been looking at Scala. Martin Odersky has given his Scala talk again. I liked the talk much better this year than last. Maybe because the Scala syntax looks much more familiar after I had used it a bit. Maybe because I now believe his claim that a typical Scala program uses half the lines of code as the equivalent Java program--because that is exactly what happened to me. It is so liberating to do without all that boilerplate that you have in Java.

Clearly, Scala is not a blue-collar language, and I cannot see every Java programmer flocking to it. But I would like to get more experience working with a project that mixes Scala and Java. Preferably with IDE support. There is an Eclipse plugin that is “getting better”, and just recently Caoyuan Deng has made amazing progress with a Netbeans plugin. Adam Bien relates this story:

During a meeting in the Community Corner (java.net booth) with James Gosling, a participant asked an interesting question: "Which Programming Language would you use *now* on top of JVM, except Java?". The answer was surprisingly fast and very clear: - Scala.

Swing App Framework (JSR-296)

Hans Muller gave a presentation on the Swing app framework, a great example for ease of development. Some people think Swing is dead, but there are more people crunching out Swing apps than VB apps. I imagine mostly corporate stuff. The presentation was pretty well attended.

To customize and internationalize components, set their name property (either programmatically or in the GUI builder), and then populate resource files with instructions such as

infofield1.font=Arial-PLAIN-12
infofield1.icon=dynamite-stick.png

For actions, define a method, tag it with the @Action annotation, and then set accelerators such as

submit.Action.accelerator=control S

This is something I have been waiting for for a looong time—it surely has been reinvented a million times (at least twice by me). Now it will finally be a part of standard Java. The framework has many nice touches: support for background tasks, pesky Mac OS X issues, and saving of session state. If you write Swing apps, check it out! (Also check out beans binding.)

JPA 2.0 (JSR-317)

JPA is one of my favorite “ease of development” technologies. I design my object model in Java, toss in a few @OneToMany annotiations, and presto, I get a database schema, entity caching, and an OO query language. I am not the only one who feels that way—the session filled completely. Of course, there are a few issues in JPA 1.0 that even a casual user such as myself runs into, mostly because the API was designed by database wizards but it increasingly used by people who think in Java, not SQL. I was glad to see that all my pet peeves are being addressed in JPA 2.0:

• Ordered lists (e.g. a Quiz class with a field ArrayList<Question> questions). The order of questions matters to me, and I want an index column to be generated automatically. JPA 2.0 will have @OrderColumn
• There will be support for sets of basic and embedded types, and better support for maps.
• There will hopefully be better support for prefetching lazy relationships. For example, when I detach a Quiz object into the web tier, I will want to prefetch the Question entities, and for each multiple-choice question, I want to prefetch the Choice entities.) The details are still being worked out.

Web Beans (JSR-299)

Gavin King talked about Web beans. I wanted to know whether/when we have will have something like Seam as part of EE 6. For me, the key feature of Seam is that I can hook a EJB session bean immediately into a JSF page. (It is painful to access JPA entities in a JSF managed bean, so right now, I shlep a bunch of stuff from JSF beans to EJB beans. Seam avoids that tedium.)

Gavin is an opinionated and charismatic speaker, but he was opionated and charismatic about a general-purpose plumbing mechanism that, once it becomes part of Java EE 6, will make Seam-like components possible. It was quite interesting if you are into meta-annotations, and the design looked very clean. But I still don't know whether I will get Seam-like ease of development when EE6 ships.

JCP Roundtable

Through the power of my press pass, I got into a “JCP Roundtable Discussion on Open Source and Open Standards”. The table was actually not round, just your usual long table with speakers Patrick Curran (the JCP Chairman), Alex Buckley, Stephen Colebourne, Rod Johnson, and other luminaries.

Some things I learned:

• It isn't just me who can't figure out what goes on behind the closed doors of some JSRs. One of the Java EE expert group members has trouble getting onto the internal email list of the servlet JSR.
• Everyone agreed that transparency should be the default for all JSRs, but it simply isn't so today. JSR-166, which Doug Lea ran completely in the open, just to show that it can be done, is still the exception.
• Alex Buckley said that one important part of transparency is for JSRs to not just publish a spec but to give the rationale for their decisions.

All of this may be rather arcane for most users of Java, but as a book author, I feel the pain caused by a lack of transparency. And, ultimately, so do you. There are some JSRs that are best left unmentioned (such as JSR-127) that would surely have produced better specs if they had received more broad-based input.

Java Champions BOF

The Java Champions are a motley assortment of (Java luminaries|whiners and complainers), including yours truly. It is to Sun's great credit that we get access to their executives, and that they even listen to us (in Bob Brewin's case, not for very long :-)). Today, we had a BOF where we got to do what we do best, and one of the common complaints was lack of transparency.

Consider the case of Java FX. I am rooting for Sun and FX. You can't win if you don't fight, and I give Sun a lot of credit for fighting.

I don't see what good it does to develop behind closed doors, and only show a preview to a select few who sign up and get chosen. That may work if you really know what you are doing (e.g. the iPhone but not the Newton). But there is a reason that open source projects succeed with a transparent development process where everything is out for anyone to see. Let people whine and complain early and often, and you get great feedback what you need to fix, before it is too late.

Java FX Script

The day started with, you guessed it, another keynote. I just can't stay focused during them, so FWIW, here is what I got out of it.

• Sensors let you figure out whether people leave a keynote early.
• RFID tags are a mixed blessing. In passports, maybe not...Chief scientist John Gage: “Hi, I'm an American. Can you detonate the closest device?”
• Sun's VP for software Rich Green promises huge announcements, great surprises. He also says that Sun is the world's largest open-source software provider on earth.
• A fellow from Amazon (the shopkeeper, not the river) demonstrates the Kindle which, as it turns out, is a Java ME device. I never knew that. Actually, I think that is good news. Amazon quietly picked what they perceived to be the best technology for the job. That's a much more credible validation than the usual co-marketing arrangements (like those tacky “Intel inside” or “Designed for Windows” stickers.).
• Here is what was best about the Amazon demo. The fellow demonstrated how to buy a Java book. And which book did he pick from the multitude of choices? Yes, my friends: Core Java, authored by yours truly. He mumbled that it seemed to have good reviews.
• One thing that always bugs me about keynotes is when partner from company X appears on the stage to share ... absolutely nothing. Can anyone tell me what value the fellow from Sony Ericsson added?
• The highlight of the keynote was Java FX Script. The pitch was that there is intense competition for consumers' eyeballs, and that rapid prototyping and frequent iterations are essential to develop the killer UI that captures those eyeballs.
• There was a cool demo where an applet was dragged off the browser and dropped onto the desktop. I really liked that part. The applet—written in Java FX Script—also ran (somewhat degraded) in a low-rent ME phone. There was another cool demo with spinning video players, all running at a good speed.
• Delivery timeline: July 2008: JFX SDK EA. Fall 2008: JFX Desktop 1.0. Spring 2009: JFX Mobile 1.0
• The Glassfish 3.0 kernel is 98K.
• Open JDK ships in Ubuntu. (To my delight, there was a fair amount of applause from the audience.)
• Sun is working on Project Hydrazine. Find. Merge. Deploy. Share. Monetize. Huh. It has something to do with instrumenting Java FX apps and sending data back to the trustworthy service deployer, not the evil technology vendor.
• Jonathan Schwartz is much better at explaining stuff. His take on Java FX:
  1. More devices: Linux, Mac, Windows, embedded devices
  2. Performance (better VM)
  3. Insight (instrumentation)
  4. Free
• The keynote ended with Neil Young, a bard who pitched a multimedia project that chronicles his life work on a set of Blu-Ray disks. The UI was very pretty...Java-powered, of course.

A few months ago, I had asked Bob Brewin at Sun about the situation about audio and video codecs in Java and FX. He hemmed and hawed and mumbled something about how Ogg Vorbis wasn't really going to work out. The good news is that Sun now licensed the same codecs that are used in Flash, and there will be decent multimedia support going forward. It is just extremely annoying that codecs are so patent-encumbered, and it is yet more evidence that patents hinder, and not promote, the progress of science and the useful arts.

At the press cocktail hour, James Gosling was kind enough to give me some inside dope on JFX development. One of my graduate students, Sadiya Hameed, is working on reimplementing Java FX Script as a DSL. Whenever she showed me some code that she found in the wild, I thought “Whoa! That's a lot ofmath.” (Which, BTW, one of the keynote speakers said today as well.) As it turns out, a lot of the math is apparently auto-generated when a set ofAdobe Illustrator files is transcoded into Java FX Script. The work flow is that the creative folks work in the tools that they like (and not so much in Java FX Script), and that the programmers work in the tools that they like (maybe Java FX Script for the front end, and definitely Java on the backend). Gosling also said that some of the tools were still pretty rough, which is why the keynote didn't show them off. That all made perfect sense. They should let him give the keynote next year.

EJB 3.1

I am a definite fan of JPA and EJB3, so I was keen on learning what is new in EJB 3.1. Fortunately, much of it centered on my pet topic, ease of development.

• No more boilerplate local interfaces. Session beans can be POJOs. Hooray.
• Packaging complexity bites the dust. No more EJB JAR inside the EAR. Hooray.
• Work in progress:
  • Standardized JNDI lookup
  • Component testing in lightweight container
  • Using EJBs in single SE client (lookup, injection)

It surprises me how many people still don't realize that EJB3 was a game-changer. Last year, it was still ok to complain about EJB bloat. This year, not so much.

Defective Java

Bill Pugh gave an amusing talk about “WTF code”. He is the inventor of the nifty Findbugstool and regularly trolls for dysfunctional code (in unsavory places such as this one) to add more bug-finding rules. Here are some of the beauties that he presented:

• while ((c = (char) in.read()) != -1) { ... } 

  A char is a value between 0 and 65535, never -1...

• private final String lock = "LOCK";synchronized (lock) { ... }

  Literal strings are interned, so hopefully two programmers don't have that bright idea...

• synchronized(getClass()) { myStaticCounter++; }

  Let's hope nobody calls this from a subclass...

• DateFormat is not threadsafe...
• java.sql.Timestamp is not symmetric...
  The audience's collective eyes glazed over at this point. An informal poll revealed that a large fraction was blissfully unaware of the instanceof vs. getClass() controversy in the equals method. This seems to be a lost cause. Maybe anyone who overrides equals in a non-final class needs to supply an annotation @IKnowWhatIAmDoing.

Java Language Evolution

An interesting presentation about what to expect in Java 7 and beyond.

Rules:

1. Respect the past. No new global keywords (like enum, assert). “Restricted” keywords are ok (module, and hopefully, property :-))
2. Respect the future. Leave room for syntax to breathe. Counter-example: Maybe we'd like to have named parameters for ordinary methods in the future. When annotations with named parameters were introduced (@Foo(name = "fred")), the choice of = was a mistake, because you can't do foo(name = "fred") for ordinary methods. Had the Java 5 designers respected the future, they would have chosen something like @Foo(name : "fred"). Or not...wouldn't that conflict with BGGA control invocation?
3. Respect the model. Java is a general purpose OO language.

Principles:

1. High-level. (Express the idea, not the bits)
2. Covet clarity
3. Static typing
4. Loose coupling between language and API

Likely to be in Java SE 7:

• // Multi-catch
  try { .... } catch(X1, X2 e) { ... }

• Modules
• Annotations in more places

Definitely won't be in Java ever:

• Operator overloading

I want the multi-catch. Modules and better annotations are noble but dull. Did I ever mention that I want native properties? That I am sick of the boilerplate? I asked James Gosling. He said that there is a long stack of proposals on what to do with properties. And they all run against a brick wall when they try to deal with bound properties. (I know...one of my students, Nikolay Botev, compiled a long list of them, and another, Alexandre Alves, implemented a javac extension to implement one.) I agree...bound properties are a lost cause. Let's just admit that and move on, with simple properties and a “restricted” property keyword!

Too bad I didn't have a chance to ask about that in the BOF. I had been a reviewer for the tools and languages track, and Sharat Chander, the track chair, took out all of the reviewers for a great dinner. Potentially little known facts: (1) Competition for slots at Java One is intense. We had over 300 proposals for maybe 20 slots. (2) Most of the reviewers—at least in our track—are not from Sun.

Ian Murdoch (the ian in Debian) gave the keynote speech. My mind wanders in keynotes, and here were some of its destinations.

• His boss, Jonathan Schwartz, likens open source to the thousand tributaries giving rise to the mighty Amazon river (not the shopkeeper, although that too might be a valid analogy)—the reverse of this image.
• Maybe the MySQL acquisition makes more sense than I thought. As a card-carrying member of the chablis and brie set, I had always preferred PostgreSQL, but MySQL is a blue-collar database, just like Java is a blue-collar language.
• Core + edge. There is an open-source core (Java, OpenSolaris, etc.), and vendors add value at the edge. I thought of Donald Knuth and TeX, and how he insisted (wisely, I think) that it be the immutable core, whatever its flaws. Maybe that's what will happen with Java, and innovation will come at the edges, with new languages and technologies.
• This doesn't work so well with a closed-source core. Amen. At my university, we use the wretched Blackboard software that is sold to CIOs, not users. Over the weekend, I googled to find out how to import quiz questions to Blackboard. I got a zillion hits on how to do this for Moodle, an open-source alternative, in a variety of formats. With Blackboard, there is a solitary third party product for the job that uses Windows. Too bad I don't.
• One problem with the OLPC is that the coders aren't it's users. Amen.
• Open source lets you be brilliant faster. Amen.

Charles Nutter gave an interesting overview of languages that run on the JVM. There were the usual suspects: Groovy, Jython, JRuby, Rhino, Scala, and some more exotic ones. (Note to self: Check out Clojure and see if it makes software transactional memory easier to understand.) Charles' advice: The era of doing everything in a single language is over. Be a polyglot.

Sadly, the Netbeans talks were far from riveting. Instead, I walked off to the exhibit area and had a chat with Winston Prakash and a very friendly fellow from the Prague office about the JSF visual designer. The Netbeans 6.1 editor isn't bad, provided you don't use absolute positioning and ignore the useless backing bean that it insists on generating. But it could be so much better. An improved visual editor is being planned, but apparently JSR 276 is going nowhere. That's too bad. Wouldn't it be nice if you could use your favorite JSF library (ICEfaces, RichFaces, ADF Faces/Trinidad, Woodstock) in your favorite IDE, with visual builder support? It has taken far longer than I expected for these components to appear, but now that they are there, I want to drag and drop them, and not be stuck with the drab standard components. (Check out this blog by my graduate student Ashlesha Patil...)

There was a very nice presentation on EclipseLink. It looks like a great JPA provider, blazing the trail to JPA 2.0 and offering amazing configurability. But it surely takes the prize for the most confusingly named product of the day. Recall that Toplink WateredDown, erm, Essentials, is the JPA provider in GlassFish. The original Toplink is now open-sourced with the Eclipse foundation, hence the name. Where can you find it? In Glassfish 3, which you can install into NetBeans (!). The Eclipse IDE has not yet caught up.

My favorite event was a fun presentation about using robots in computer science education. These aren't your usual Lego robots. They have several processors on board for “cockroach reflexes”, and they can be equipped with a Java-powered SunSpot for its brains. The presenters demoed a nifty development environment based on Greenfoot. You can prototype your robot in the safety of your laptop, and then download the program into the SunSpot to control the actual hardware. There is a maze-solving contest going on at Java One. If you have any brain cycles left for coding at Java One, give it a try!

• Great post!! never knew about wildcards
• I cant believe this. I cannot think how a wild card in generics fits into the java OOP theme. Upto now the rules were always simple and straight forward. In this case list object should have accepted all objects of sub classes by default. I feel generics in Java has made things complicated and confusing for the programmer.
• If you find yourself writing way too many ? extends constructs and think you shouldn't need to, you probably should re-think whether you actually want an abstract class or whether an interface would do the job for you. [Huh?]

For the first time, I really understood what it means to be a blue-collar language. In a blue-collar language, the rules are always simple and straightforward. If something doesn't work, there is a clear error message, either at compile-time or at run-time. Overall, Java did a great job with that. Consider covariance of arrays.

Joe Bluecollar can convert a Employee[] array to an Object[] array, and he never even worries whether that is safe. If he then stores a Watermelon instance in the array, he gets an ArrayStoreException. But that's not very common, and when it does happen, Joe can see what the problem is.

Java generics? Not so simple. Check out this blog. Even a concurrency rocket scientist can be baffled by generics.

• Why in the world do I need to specify <? extends SomeInterface> for generics? What else am I going to do with an interface other than *extend* it. Well... I guess I can stare at it, but I don't think it counts.

I am teaching a graduate course in programming languages at San Jose State. One of the topics is generics in Java and Scala. I thought my students would enjoy a topic of current interest, but they are not happy. Variance and wildcards seem to belong to that category of mind-benders that most people find impossibly challenging, similar to the pumping lemma or 2D array types in C.

(When teaching C, I used to patiently explain, with many examples, why the type of an array declared as int a[3][4] is int (*)[4] and not int**, but I was rarely successful. )

What is it about these topics that makes otherwise perfectly capable programmers stop thinking and start guessing randomly? Maybe we all use intuition more often, and formal reasoning less often, than we think? A language that wants to capture the hearts and minds of the blue-collar programmer needs to work very hard to have rules that are always simple and straightforward. In Java, arrays are simple and straightforward. Wildcards are not. I now appreciate how challenging it is to develop a blue-collar language, and how much thought must have gone into the design of Java.

I don't mean to say that everything in the language has to be easy as pie—we all know easy languages that lack power and expressiveness. But the rocket science stuff ought not to be in everyone's face. In Java, the rocket scientists can use annotations, reflection, and byte code engineering, to deliver constructs that the blue-collar programmer finds intuitive to use. The problem with Java generics is that they are too weak. For example, it is not possible to implement a covariant array with an array store exception (because of erasure). Instead, the wildcards leak out and give the blue-collar programmer a headache.

What does that mean for closures? How leak-proof is the rocket science stuff? With BGGA, for the most part, I think it is pretty good, particularly when it comes to control invocations. Of course, you'd never know from looking at all the blogs that show complex syntax for writing closures. Well, using reflection, dynamic proxies, and annotation processors is no picnic either. What counts is whether the resulting artifacts are “always simple and straightforward”.

Has computer science become as unpopular as Latin for American teenagers? That would have serious consequences for our industry. As it happens, I just finished serving on the Development Committee for the AP Computer Science courses, so I have a little more inside information.

The number of computer science majors has dropped substantially after the dot-com bust (see the graph below). At the same time, U.S. employment in the IT sector is solidly up, outsourcing nonwithstanding, and there is widespread concern about a looming skills shortage.

Why don't students major in CS? Nobody knows for sure. The Dilbert image of working long hours in cubicles, only to have your job outsourced, surely doesn't help. We do know that most students have made up their mind by the time they reach college, so the way to their hearts and minds is in secondary school.

That's where the AP program comes in. In the past, there were two courses, AP CS A and AB. The A course covers college-level CS1, the AB course covers college-level CS1+CS2.

That, of course, begs the question what college-level CS1 and CS2 are. In most universities, CS1 is an introduction to programming, and CS2 covers data structures (linked lists, trees, hash tables, etc.) While CS2 is fairly standardized, there is quite a variety of approaches for CS1. The most popular programming language is Java, followed by C++, but there are enthusiastic proponents of Scheme, Python, C, assembly, and just about any language other than Intercal. Some CS1 courses are “breadth first”, covering a bit of networking, databases, software engineering, and theory rather than diving deeply into programming. MIT starts out with robotics, mixing hardware, software, and systems design. That sounds like a lot of fun but it is so expensive and labor-intensive that it is unlikely to become mainstream.

AP CS must have a single curriculum, so they go with the middle-of-the-road approach: Programming and data structures in Java. That doesn't make them popular with the (intrepid experimenters|lunatic fringe)—see this article. Some of that criticism is below the belt. You can't judge the quality of a course by the weakest question on the final exam. But not all is well with AP CS. There needs to be more room for excitement and fun, not just teaching to the test.

Enrollments in the course have declined somewhat less than at the college level. Here are recent numbers of test-takers, courtesy of Dave Reed, the Chief Reader who administers the CS exams:

YEAR      A      AB
---------------------
1998    6,478   4,057
1999    12,218  6,619
2000    13,646  6,876
2001    15,827  7,595
2002    15,660  7,799
2003    14,674  7,071
2004    14,337  6,077
2005    13,924  5,097
2006    14,662  4,939
2007    15,049  5,064

Compared to other AP subjects, the CS numbers are not very impressive. In 2007, Physics had over 60,000 test-takers, and US history over 250,000. Latin had about 5,000.

The College Board decided to cut their losses. Without bothering to ask any CS people, they eliminated the AB exam, leaving AP CS as a one-semester course. (As the VP in charge, Trevor Packer, emailed me: “We do not see this as a decision dependent upon disciplinary input.”) This is rather unfortunate since the kids taking AB are the ones most motivated to go into computer science.

There is some talk by the College Board administrators about growing CS A back into a two-semester sequence, but that is pretty dubious. Who would heal themselves by first cutting off their healthy limbs and then waiting for them to regrow? (Trivia fact of the day: According to the April 2008 Scientific American, Salamanders are unique in their ability to regrow severed limbs.)

As you can see, CS in American high schools is in bad shape. That is a problem for all of us in the computing industry. What can you do? If you have kids in school, make your voice heard with the school board. Volunteer in the CS club. (They don't have one? Start one. I fondly remember my high school days in the physics and technology club, the refuge of the nerds. We were a proud group of nerds, and many of us ended up with a Ph.D.) Get your company to send speakers, volunteers, and equipment. Get kids into your company so they (hopefully) see that it's not Dilbert land. And remember, what got you into CS may not be what excites them, so be on the lookout for new approaches such as this or this or this.

On February 28, James Gosling gave a presentation in Sun's Santa Clara Campus auditorium (formerly a part of the Agnews Insane Asylum :-)), entitled “Feel of Java Revisited”. The talk promised to revisit the classic Feel of Java paper that famously declared “Java is a blue collar language”. (SJSU students: Go here for free access to the paper.)

I teach a graduate class in programming languages at San Jose State University. Instead of covering denotational semantics or logic programming, I decided to cover what is hot in dzone (closures, metaobject protocols, etc.) and smuggle in the theory under the radar. My class has been learning about the various closure proposals for Java, and we played with the BGGA and CICE implementations in the labs. (If you want to play along, go here for a guest login. Sorry, no FCM yet. The implementation came after I designed the lab.)

Aaron Houston, the tireless champion of the Java Champions, got my class tickets for the event, with reserved seating, free T-shirts and a Sun Spot kit for the CS club. Thanks Aaron!!! We all had an amazing time.

Much to my disappointment, the presentation did not engage in mudslinging about competing closures proposals :-) Instead, James revisited his personal journey to Java. It was very interesting to see how his experience with prior scripting languages and compiler projects shaped his thinking. When Java was created, the “blue collar” language was C. Used by Real Programmers who were manly enough to spend weeks tracking down obscure memory corruption errors. Garbage collectors were used by quiche eaters. James explained his goal of combining a familiar syntax with the features that are required for security and reliability. He also recounted his many years of experience with virtual machines, from industrial and academic projects. It became apparent how Java—the happy marriage of blue collar and quiche eater programming—was no accident but the result of a careful design process.

Of course, closures came up in the Q&A. James said that he personally loves closures and would like to use them in Java if and when they become a part of it. (There had been some speculation in the blogoshpere whether closures fail the “blue collar test”, which James refuted in this blog.) I asked about the decision process that governs the evolution of the Java language. In response, James grumbled a bit about issues with the JCP process. James made it clear that he considers generics a great win, despite some of the ugly corner cases. Kirk Pepperdine asked about Java FX and whether it was competitive with Flex and Silverlight. James gamely said that it will be an interesting battle. There was some discussion about the successor of Java, and James said that the JVM is more important than Java itself.

This all left me thinking about closures and blue collar programmers. 15 years ago, only the super-rich had a plasma TV, and only eggheads used a garbage collector. Now, flat screen TVs are everywhere, and I can't think of a recent programming language that doesn't have garbage collection. Time marches on, and what was once a luxury becomes commonplace in blue collar households.

Consider this example from my homework assignment. Instead of this mess of code, use BGGA closures to put work on a background thread or the event dispatch thread like this.

            Scanner in = new Scanner(new FileInputStream(file));
            onBackgroundThread()
            {
               int lineNumber = 0;
               while (in.hasNextLine())
               {
                  String line = in.nextLine();
                  lineNumber++;
                  onEDT()
                  {
                     statusLine.setText("" + lineNumber);
                     textArea.append(line);
                     textArea.append("\n");
                  }
               }
               onEDT()
               {
                  openButton.setEnabled(true);
               }
            }

Note how much clearer the code has become. Put time-consuming work on the background thread, and put the UI update on the EDT. Java FX needs special keywords for this. With closures, you just define a couple of utility functions. It is so easy that one of my students wrote:

Last time, it took me at least 10 hours to do one of the problem, but i got through #1 in less than 1/2 an hour. most of it was copy and paste. I didn't even need more than 1 class. am i missing something? It's almost as if you can lift the solution out of the labs. All I had to do was write 2 really really really simple closures.

It doesn't get more blue collar than that :-)

In that regard, the first release of JSF was a cruel disappointment. The standard JSF components are very primitive. The most sophisticated one is the data table, and it pales in comparison with a Swing JTable. No progress bars, trees, menus, popups, or any of the other building blocks that you want for a snazzy application. I don't want “FORTRAN for the Web”.

In the last couple of weeks, I had to hack together a simple system to support classroom discussions. The instructor puts up a question, students give anonymous answers, and then the class looks at the collective wisdom and has a (learning insight|good chuckle). Many instructors use “clickers” for this purpose—special hardware devices with voting buttons. But I wanted students to send text and images, not just multiple-choice answers. (Also, they all already have a laptop, but they'd have to buy the clicker.)

At first, I thought, oh no, don't make me eat the elephant again, and I longingly looked at Rails, Grails, or Lift for my salvation. But then I googled for "Rails progress bar", and the results were depressing. I noted that NetBeans 6 has a perfectly good progress bar in the Woodstock component set, so I decided to go with JSF once again. This time, Swing for the Web seemed within reach. Here is what worked and what didn't.

1. The Woodstock components look pretty nice—much nicer than anything that I could put together with my limited CSS skills. For example, the alert component has some shading, some graphics, all that stuff that I am too busy to work on. Exactly what you want from a component set.
2. The progress bar worked great. I didn't have to know anything about AJAX. That's good because I really don't want to know any more about AJAX than about ASN.1. For an application programmer, this should just be plumbing.
3. The documentation for the Woodstock components is totally wretched.
4. The NetBeans form designer is adequate for dragging together a basic UI, but it insists on the “Creator” model where each JSF page has a backing bean with bindings for each component. That may make sense for ASP.NET programmers, but I hated it. Apparently, this will go away in Netbeans 6.1. I used the form designer for the initial layout, then converted everything to plain JSF. I also had other issues that hopefully will get addressed in a future version of the UI builder.
5. Achieving a common page layout, with a title bar on top and a menu on the left, is still way too hard. I want the framework and tools to guide me, not fuss with page fragments.
6. I used the XML JSP syntax and XHTML for the pages, and NetBeans caught all my silly formatting errors—a big help. (Why don't I follow that good advice in Core JSF? I tried, but my co-author and the reviewers all felt nostalgically attached to ye olde syntaxe.)
7. NetBeans is pretty good about keeping the various configuration files in sync, and I didn't have to fuss much with faces-config.xml.
8. If I had used Seam, I could have ignored faces-config.xml altogether, but I ran into some GlassFish problems. Once WebBeans is integrated into NetBeans/GlassFish, I will definitely go that route.
9. JPA was a winner. Having the ORM and caching for free is nice, and JPQL is far less tedious than SQL. I spent essentially no brain cycles on persistence. Mostly, that was because my app is so simple that I never felt the need to export any entities outside the managed environment. Again, Seam/WebBeans would make this even nicer.
10. I still got the Stack Trace From Hell far more times than I wanted to. NetBeans did a fairly creditable effort in trying to scrape what little useful file name/line number data it could find. This still needs lots more work. For example, errors in session beans are silently swallowed.
11. The NetBeans debugger saved my bacon many times. It is very savvy about tracing from a JSF bean to a session bean, bypassing the intermediate layers.
12. I tried my best to use hot deployment, and even hot-switched code whenever possible. But every time that I edited a JSF page or even a CSS file, I had to redeploy, redeploy, redeploy, and each time, I stared at the console for what seemed like an eternity. I hated that. My Rails friends tell me that they can keep tinkering with their code without ever redeploying.

Overall, I felt that I still had to focus far too much on the care and feeding of the app server. GlassFish programmers—remember that the app server is not just a tool to run perfectly working applications, it is also a part of the development environment!!! We need good error messages and red-hot deployment to be productive.

Swing for the Web is getting closer. Woodstock, RichFaces, Trinidad, all show promise. But do we really want all of them? After all, there is just one Swing. And if we must have them all, they should all play nice in a web GUI builder. JSR 276 should get us there—that started in June 2005. How time flies!

Apart from the UI components, we need more architectural guidance for mediating between the UI and persistence layer. I think JPA with Seam/WebBeans is our best bet, and NetBeans should support it ASAP.

All these issues are solvable, and I am hopeful they will be solved. I did enjoy having the Java API for all those other things I needed to do (such as crypto, zip file management, image manipulation, and so on). In the end, I was able to hack together a somewhat nontrivial application using NetBeans, GlassFish, JSF, and JPA, in a couple of weeks, while at the same time contending with sick infant twins and a broken clothes dryer. Not bad...but it could have been one week without the Stack Trace From Hell and redeploy, redeploy, redeploy.

Pain vs. Discomfort

Let us go back in time, to 1995, when Java first appeared. We were programming in C++, Visual Basic, and “fourth generation” languages such as FoxPro. Since I was a C++ programmer, I remember exactly what my pain points were:

• Memory management
• Access to database and GUI features

Memory management was intensely painful. One bad pointer could wreck your entire program in mysterious ways and condemn you to many days in debugging hell. Writing a GUI that accessed a database in C++ was (and is) like eating soup with a fork.

When Java came along, I got garbage collection and an API that let me do stuff. I was sold.

I was (and am) surprised when people tell me how they hated operator overloading and multiple inheritance in C++. In the grand scheme of things, these caused me discomfort but not agonizing pain.

Deckchairs on the Titanic?

Now let's look at C++ in 2008. It is still alive and kicking. There is an effort to make sweeping changes in the language and library: templates on steroids, “smart” pointers, multithreading support, even optional garbage collection. The folks who work on that stuff eagerly discuss the merits of the various proposals while the rest of the world looks on with wonder. Even if all these efforts come to fruition, can you imagine banging out a web application in C++? C++ has become a niche language, but I talk to many C++ programmers who live in total denial about that fact.

How about Java? Are we living in denial? Are our discussions about closures simply arguments on how to rearrange the deck chairs on the Titanic? What about the point of view that Java should be “stabilized”? Does that mean “fossilized”?

I think that there has been way too much discussion whether this or that proposed language feature is elegant, ugly, or confusing. Java, its APIs, and its development environment are tools to produce software. Where there is too much pain, we should evolve to address the pain, or the rest of the world will look on with wonder about our silly syntax discussions.

It is futile to hope for stability. There always will be pain since we are bound to take any technology and push it beyond its limits.

My Pain in Java

Here I am, a Java programmer in 2008, and I know perfectly well what I hate.

• Boilerplate, boilerplate, boilerplate
• Web applications
• Concurrency

From an emotional point of view, the boilerplate is what I feel every day. Every time I write a stupid getter/setter, an event listener with that wretched inner class syntax, or another long-winded type declaration that the compiler could perfectly well infer, I cringe. But that isn't enough for me to change languages. It is discomfort, not pain.

But when I embark on another web application (which is what I should be doing this morning instead of writing this blog), I groan. I use JSF in the forlorn hope that someone else has given me components that make me not worry about AJAX and GET vs. POST, all of which have nothing to do with the problem that I want to solve. But then I read descriptions such as this or this, and I despair. If I have to paste random pieces of code to make things work, I just know I'll be hosed when things don't work.

Come on, folks, When I write a web application, I want to be able to say "This is the common layout of my pages, give me a standard login screen, I want a menu here, and fill that table with those database values, but add a column with buttons..." I can do it in JSF, but it is like eating soup with a fork.

Why is it that Sun can't give me a decent web framework? Is it a shortcoming of the Java language? Or crummy API design? Rails uses the metaobject protocol to good effect in Active Record, but as it turns out, that isn't my problem. JPA works ok for me. The rest of Rails doesn't attract me—I want components, not RHTML files. I think in this case, the Java language is sufficiently powerful, but we are hobbled by backwards compatibility with JSP and JSF, both of which are simultaneously complex and underpowered. Or could a language enhancement such as continuations make web programming dramatically easier? If so, why does Rails get all the buzz and not Seaside?

Finally, concurrency scares me. I am not smart enough to write a nontrivial concurrent program where I can say with confidence that it won't ever deadlock and that it won't have any race conditions. Just like I was not smart enough to write a nontrivial C++ program where I could say with confidence that it won't ever leak or corrupt memory. So far, I just stick my head in the sand. But as multicore becomes more prevalent, that won't work. Do we need a language change or a better API, such as actors in Scala?

I'll suffer through the boilerplate discomfort, but if something doesn't happen with web applications and concurrency, I'll eventually bail. Dinosaurs can endure pain, but I can't.

What are your pain points? Can the Java ecosystem change to address them?

Twelve 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.”

So, 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 http://java.com/en/download/linux_manual.jsp

Download "Linux RPM (self-extracting file)". Use scp 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 
./jre-6u3-linux-i586-rpm.bin 

(The exact name may differ.)

By the way, here is the result of running df before

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:

javaws http://www.horstmann.com/violet/violet.jnlp

If you get an error message such as

java.lang.UnsatisfiedLinkError: /usr/java/jre1.6.0_03/lib/i386/libdeploy.so: libstdc++.so.5: 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/libjavaplugin_oji.so

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

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

LoadPlugin: failed to initialize shared library libXt.so [libXt.so: cannot open shared object file: No such file or directory]

LoadPlugin: failed to initialize shared library libXext.so [libXext.so: 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/libjavaplugin_oji.so [/usr/java/jre1.6.0_03/plugin/i386/ns7/libjavaplugin_oji.so: undefined symbol: _ZTVN10__cxxabiv121__vmi_class_type_infoE]

I got rid of the first two error messages by making symlinks /usr/lib/libXt.so -> libXt.so.6 and /usr/lib/libXext.so -> libXext.so.6

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.

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.

But 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.

While everyone else is madly milling about at the mall, please take a few minutes to see check it out: http://oslo.cs.sjsu.edu:8080/xwiki/bin/view/JavaProperties. If you are a properties enthusiast (you know who you are), please make an account and add to the Wiki.

Happy holidays!

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 the bind 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?

I loathe authoring with Powerpoint (or its OpenOffice equivalent). Putting together a presentation requires a horrid amount of mouse clicking and fussing with fonts and formatting. Instead, I use the amazing HTML Slidy. You write your slides in XHTML (I use XMLMind, but any web editor that produces XHTML will do.) Then you add links to the Slidy style sheet and JavaScript magic, and you have a great slide show.

This isn't something that Aunt Tilly would do, but I already know XHTML and a bit of CSS, so authoring becomes very, very fast. I dash off a few h1, ul, and img, and I am done.

Your Mission, Should You Choose to Accept It

Next semester, I will use Ubiquitous Presenter for “active learning” in the classroom. It is a nifty system where both the professor and the students can annotate slides. However, the slides must be in Powerpoint format (and, I am told, it is best if the Powerpoint is not too old or too new or “too complex”). As an alternative, the system will grudgingly accept a set of 576x432 pixel image files. (It took me a long time to realize that this means 8x6 inches at 72 dots per inch.)

I forged ahead with this recipe:

1. Use PrinceXML to convert XHTML to PDF
2. Use Pdftk to burst the PDF into a sequence of single-page PDFs
3. Use ImageMagick to convert the pages to PNG

It worked, but the image quality was rather poor.

There had to be a better way. My mission was to find one.

I considered using JEditorPane, but I had not been happy with it in the past. It has a lot of quirks and doesn't seem very actively maintained. Then I happened to spot Flying Saucer.

Flying Saucer

Flying Saucer is “an XML/XHTML/CSS 2.1 renderer in 100% Java”. It renders to Java2D images, and, together with the iText library, to PDF. (It does not try to process arbitrary HTML, so you won't want to build a web browser with it.) Some people use it to produce PDF or images on the fly, for example in web applications. Generate XML or XHTML, use CSS for styling, and you can produce quite a variety of output with very little work.

I loaded a slide sample into the Flying Saucer viewer application. Impressively enough, all of the CSS was correctly interpreted. Make that “almost all of the CSS”. A bug with image scaling was a showstopper, but I sent a message to the mailing list, and a patch materialized within hours.

Flying Saucer comes with command-line utilities to generate PDF or images, but there was nothing to produce an image per page. In a day, I hacked together a simple program for this purpose, by copying the pagination code from the PDF generator and the image rendering code from the image generator. I don't understand all the mumbo-jumbo with devices and contexts, but it works perfectly. Here is a slide sample:

If you ever need to render images or PDF with lots of text and a fairly rigid structure, give Flying Saucer a try.

Infrastructure

What does this all mean in a bigger way? It is an issue of infrastructure. The Ubiquitous Presenter tools are tethered to Powerpoint. It is a fragile infrastructure. There is no reliable mechanism to process Powerpoint other than Powerpoint, and even that comes with the proviso that the files are neither too old nor too new.

In contrast, open standards and open source enabled me to leverage a huge infrastructure. When I submit a bug report about CSS, there was no arguing about the expected behavior, but the bug simply got fixed. (Try that with Powerpoint!) There are lots of tools that produce or consume XML+CSS. The Flying Saucer people integrate the iText stuff; I take the Flying Saucer stuff and solve my problem in a day. It's all open source and there is very little friction. It isn't something that I think about very much, just like I don't usually spend a lot of time thinking about the physical infrastructure that surrounds us. As long as it works, it is invisible.

For this reason, I am somewhat reluctant to embrace the Ianguage du jour. If I switch to Ruby or Python, I have a different infrastructure. How good is it? For example, how do I render XHTML into PDF? Is it like moving from the United States to Mexico? Fun at first, but then the bad plumbing gets to you? Maybe the JVM will become a part of the infrastructure, and in ten years, I'll call Flying Saucer from JRuby or, more likely, Scala.

When JDK 6 was released, there was a lot of buzz about the bundling of Derby, erm, JavaDB: buzz, buzz, buzz. Of course, there also was some bile. Programmer opinion was mixed. My personal feeling (recorded here for posterity) was “Doesn't the Java team have better things to do?”

But so what—once the deed was done, I felt that I might as well take advantage of the bundled database. In a couple of books, I suggested that readers download JDK 6 and put jdk/lib/db/derby.jar onto the classpath. The publisher of my college text developed a nifty tool for homework checking that is deployed with Java Web Start. It allows students to run sanity checks on their homework assignments, and it uploads the solutions and the results of the checks to the professor's gradebook. For database problems, it simply uses jdk/lib/db/derby.jar.

All was peachy until Java SE 6u2. (Don't get me going on the numbering...)

Now, out of a sudden, the rules have changed. According to Sun,

“This distribution bundles Java DB, Sun Microsystems' distribution of the Apache Derby pure Java database technology. Default installation locations are:

• Solaris: /opt/SUNWjavadb
• Linux : /opt/sun/javadb
• Windows: C:\Program Files\Sun\JavaDB”

The reality is a bit more complex.

On Linux, JavaDB is no longer included in the Sun JDK download. It may be that they hope that Ubuntu and others add it to their package, but Ubuntu doesn't even use the /opt directory.

On Windows, the installer charmingly continues making the jdk/lib/db directory, but it leaves it empty. Users can select where they want JavaDB installed (with C:\Program Files\Sun\JavaDB as the default). You can find their decision in the registry (HKLM\Sun Microsystems\JavaDB). Except that the uninstaller doesn't remove the registry entry, so you don't want to rely on it.

I have no idea what Apple does with their JDK for the Mac, but I would love to know.

The takeaway from this sorry episode is:

• Don't rely on JDK users having JavaDB. They may or may not have it, and if they do, it is a nightmare to locate it.
• If you write an article or book, just tell your readers to download Apache Derby.
• The lesson from Sun's blunder is: Don't bundle unless (a) there is a truly pressing need and (b) you have the resources to do it right. A bungled bundle is worse than not bundling in the first place.