Cay Horstmann's Blog

Cay Horstmann is author of Core Java (Sun Microsystems Press 1996-2004), Enterprise Java for Elvis (Sun Microsystems Press, to appear in 2006), and co-author of Core JSF (Sun Microsystems Press 2004) Cay is professor of computer science at San Jose State University. He is a computer science series editor at Prentice-Hall and a frequent speaker at computer industry conferences. For four years, Cay was VP and CTO of an Internet startup that went from 3 people in a tiny office to a public company.

Java One Day 4

Day 4 of Java One is over. Even without huge announcements or great surprises, it was a great conference. Here are my impressions from the cool stuff keynote and my takeaway what it all means.

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.

Java One Day 3

My day 3 at Java One ranged from the Nimbus UI and the future of JSF to interesting discussions about closures and Scala. Details below.

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.

Java One Day 2

Here is my report from day 2 of Java One. I continue to feel diffident about RIA and Java FX Script, the theme of this year's Java One, so I decided to make my own themes: Ease of development, and transparency.

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 One Day 1

Here is my braindump from Information Overload Central, AKA Java One 2008.

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.

Java One Day 0

Last year, Java One Day 0 was Netbeans Day, in a cozy hotel. This year, the Java One week started much more grandly, with Community One, at the Moscone Center. There were tracks for a number of open source communities, including NetBeans, GlassFish, MySQL, OpenSolaris. Frankly, I preferred the cozy hotel, but I can see that it is savvy marketing by Sun to have a large-scale free community event.

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!

On Blue-Collar Languages

I ran across this tech tip on using wildcards in Java generics. Pretty basic stuff, I thought. But I was amazed by the comments:

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

Is Computer Science the New Latin?

This Washington Post article reports on the elimination of underenrolled Advanced Placement (AP) courses in American high schools. The subjects affected are: Italian, Latin Literature, French Literature and, hold on to your hats, Computer Science AB. (The College Board designs high school courses that aim to be equivalent to college courses. High school students who take the course and pass an exam are often given college credit.)

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.

Feel of Java Revisited

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 :-)

May 2008

Search this blog:

Categories

Archives

May 2008
April 2008
March 2008
January 2008
December 2007
August 2007
July 2007
June 2007
May 2007
April 2007
January 2007
October 2006
September 2006
August 2006
July 2006
June 2006

Recent Entries

Java One Day 4

Java One Day 3

Java One Day 2

This work is licensed under a Creative Commons License.