Thick As A Brick

One of my grad school instructors, Dr. Muth, used to stress to us that we'd get more mileage out of synthesis, connecting ideas from different sources and combining them into new ideas, than cold analysis, taking a source and stripping it down to its essentials. In that spirit, I'd like to connect the dots between what java.net bloggers and other smart people have been saying recently about "thick clients".

Phillip Brittan recently blogged about Microsoft's thick client plans for Longhorn, its next major OS rev. Philip notes news coverage of Longhorn's thick client API's, which are meant to lure developers into writing more sophisticated clients that can provide a richer experience than what's possible in a browser... and of course, such clients will only run on Windows.

This is what Daniel Steinberg and I were talking about at the O'Reilly Mac OS X conference, when we left a session on thick/rich clients by Watson creator Dan Wood. As Daniel relates in his weblog, we talked about the possibility that web content developers would create single-platform rich clients and, as we've seen so often with desktop software, just do a Windows version and figure that's good enough for the majority of users.

So much for the openness and heterogeneity of the internet. If I have to pay a Microsoft tax to go online, forget it.

But there's a way out of this trap, and we're a part of it. In the slides from Dan's session - and this is from memory because only a Keynote version is available online (um, hello? print to pdf?) - there was a very surprising item at the end of his session. Thinking about how to distribute rich clients in the future, he wondered if Java Web Start might be the answer. I was surprised to see this because as far as I can tell, Watson is very much a native Mac application, and Java was never mentioned in any other part of his session.

But let's pick up this ball and run with it. Let's say we have a net application that's poorly suited for a traditional web client. We need to build a richer, more desktop-like client. A native application is an obvious choice, but then we have to have expertese in multiple platforms (or anger users of platforms we choose not to support), and we have to hand out an installer - absolutely unacceptable to some users, particularly in the enterprise. We could try single-window DHTML, which saves us the installer hassle, but pointless differences between browsers (thanks again, Microsoft) make this as bad an option as native apps.

So here's a wacky idea... how 'bout we do it in Java? With J2SE, we get:

• A mature language with a huge talent pool available
• A deep set of API's, particularly strong in networking and XML
• Deployment via Java Web Start prevents us from having to hand out an installer, yet it practically becomes an application after repeated use.
  and most of all...
• Write Once Run Anywhere. This is the point of Java after all, why not finally exploit it?!

In my session at the OSX conference, I argued there were no Java "killer apps" because seemingly nobody has applied Java to tasks to which it alone is the best solution, where WORA is critically important. I suggested there were two general fields where Java could make the most impact:

• Off-network apps, since a web app obviously can't be considered for such tasks
• Situations where the user experience requires a richness that can't be provided by the click-wait-read cycle of a web app, yet multi-platform support is desirable or even critical

In my session, I offered DVD extras - sometimes currently offered as a Windows-only goodie - as an example of the former. An ONJava blog I did a while back, "What If the iApps Had Been the jApps" was a hypothetical example of the latter. Interestingly, when I wrote it, I had no idea that someone had actually written jTunes 4, a remarkable Java mimicry of Apple's iTunes.

But it makes sense - this is an MP3-playing app that could be run on any OS that currently supports Java, and nicely, any future OS or device that supports Java. Analysts have expected for years that Sony wants the PlayStation 2 in your living room to become a "media hub" - if it supported Java, you'd immediately have a top-flight audio player without anyone having to write or port a new app to the PS2.

What's also interesting about the iTunes example is something that Amy Fowler wrote a while back in her weblog, Would you run in flipflops (actually I did once, trying to get on Star Tours at Disney World... caught the tip of my right sandal and nearly cartwheeled) She points out that the typical web interface is a miserable way to sell and manage music. And she's right. But iTunes is a more interesting hybrid than I think she realizes.

Here's the basic iTunes window. This is how you browse, arrange, and play music.

Obviously, we're in thick client territory - lists, tables with sortable columns, custom components, copy-and-paste, drag-and-drop, and nice fast responsiveness.

But the integrated music store is different. Find some music and click on an artist. You get a screen that looks like this:

This is obviously HTML, supported by the Safari WebKit, and if it's not it might as well be - simple paragraph formatting, some images, links to each album, and a "buy" button for each album's form. Notice also the simplified browser-like navigator above - forward and back buttons, plus browsing hierarchy links for "Home -> Rock -> Supertramp"

So then, what do we make of this situation:

In this case, we see a merging of the two worlds - the album info is HTML, with links to the artist, top downloads by this artist and (if you scroll right), recommendations based on purchases of this album. But below that, we have a thick-client table, still sortable by title, artist, time, etc. And the "arrow" icons here act as links to albums or artists, reloading the HTML section above. Overall, iTunes is a very slick merging of the thin and thick client.

So getting back to the concerns about Longhorn and its thick client API's...

if writing thick web clients is such a good idea, why don't we do it today, in Java?

Longhorn's not coming out for two years. Java works today. Java Web Start works today. Swing works today (despite Joshy's complaints to the contrary). Sockets, RMI, JDBC, XML parsing, even auto-discovery with Jini are all available, for free, today. Simple HTML support is in Java today (maybe not enough to write a good browser with, but enough to do something like the music store).

Consider how Apple had to whip up a Windows version of iTunes to get their music store to Windows before they were eclipsed by competitors (analysts actually suggested that Napster releasing its music store a week before iTunes would kill iTunes... ha!). Had Apple written iTunes in Java in the first place - and jTunes proves they could - then they could have had a Windows version out three years ago And it would run on Linux. And it might make users want Java on their PS2's.

Why wait two years for Microsoft to screw up the internet for everyone? Java is ready for the future today. Are you?

Toasting Java GUI's

My last weblog entry generated some good discussion about Java GUI builder tools and how they should work - how they could be made to save serialized objects instead of code, and how some apps already do this.

A couple of people made the point that new and better GUI tools won't necessarily result in better applications. jeremyzacker writes:

The problem with Java GUIs isn't the language, its the notion that any Java developer can write a GUI. Java makes it so darn easy to write GUI code that people who would normally have nothing to do with a GUIs think that they can write one.

He goes on to note that the real problem is with developers who don't understand threading and the Java AWT event-dispatch/repainting scheme, who block the GUI and create apps that appear slow or prone to freezes. Good point, and one that was directly addressed in a recent java.net article by Jonathan Simon. I ran in to similar problems a while back and blogged on ONJava about it.

In a way, this ties back to how I kicked off all of this with a mention of my session at the OS X conference, which in discussing Java's perceived slowness, asked the question "Java often used for enterprise / nework apps... does network latency look like a performance problem?"

Sure, you could save some time laying out your GUI with a visual tool... but is that really the hard part of developing Java GUI's? In the last couple of years, I've done complex GUI's, and yeah, I blow half a day on 500 lines of GridBagLayout code, but the parts that seemed challenging to me were some of the parts I did myself - multi-line list labels with icons and different fonts, a historical performance widget that rendered itself as a bar with colored segments representing performance over a certain time-slice, a JTree that supported drag-and-drop to its contents by tracking the drag event's (x,y) and repainting the node underneath based on whether it could accept the drop, etc.. A GUI builder isn't going to help with that, and I don't think those kind of tasks are any easier outside the Java world. Sometimes doing Neat Stuff requires getting your fingers dirty.

And maybe I've gotten off track from my original point. The Q&A for my session did get deeply into why we don't have an Interface Builder - like tool for Java, but one of the points of my presentation was that Java developers have turned out a disproportionate number of developer tools. We've got JBuilder, Eclipse, IntelliJ IDEA, Netbeans, BlueJ... and yet not one Java app that really matters to end users.

I keep having this troubling analogy in my mind, that Java is like one of those college degrees whose only practical application is to become a college professor in the topic.

If you haven't read the slides yet, this is "Why Mac Users Hate Java". They were promised that they'd get more apps out of the deal, because developers would stop writing Windows-only apps and start writing stuff in Java. Hasn't happened. Because those developers don't have pretty tools? I doubt it. I think the people who didn't care about non-Windows platforms in 1997 still don't care about non-Windows platforms and continue to write native apps (or worse, they write Java apps that only work on Windows). To a degree, many cross-platform apps that might have been written in Java have instead been developed as web applciations - MapQuest replaces the Rand McNally CD-ROM, TurboTax.com replaces the TurboTax CD-ROM, etc. And maybe these are done in J2EE, so we really are using Java.

But I digress. The point was, is it the lack of better GUI building tools that has held back Java on the desktop? I don't think so - I think the hard part of delivering a Java GUI has to do with things like threading and custom painting and delivering a polished, intuitive user experience... things that a GUI builder doesn't address. If an app is worth doing, then hard or not, developers will find a way to get it done. In fact, it's more typical that something cool is done the hard way first, to prove it can be done, then is made easier through a process of refinement.

To my mind, we're still struggling to come up with really good applications for Java applications... we'll work through the GUI stuff once we figure out problem domains where being cross-platform is critically important, where only a Java app will suffice. So I think we need to stop trying to please developers and start trying to please end-users.

Defrosting Java GUI's

I presented a session at the O'Reilly Mac OS X conference with the cheerful and innocuous title Why Mac Users Hate Java.

Seriously, it's not as bad as it sounds. Read the slides when they go up. What my research (I have a folder with 300+ web site postings and mailing list entries) showed that developers are very happy to be able to develop Java applications on PowerBooks and iBooks, even if they're deploying to another OS, a typical scenario for enterprise developers who deploy to Linux or Solaris. The second part of the session went into why end-users are dissatisfied with Java applications and yet why complaints of "slow, ugly, and irrelevant" could be trumped by applications that better exploited the potential of "write once run anywhere".

In the discussion afterwards, many of the questions focused on GUI builders -- a typical concern of developers, even though one of my rants was that Java developers have spent too much time on tools for other developers as it is. Specificially, they wanted to do something like Mac OS X's "Interface Builder" in Java.

The idea here is that instead of a GUI builder that spits out code, you'd have a GUI builder creating what Mac developers call "freeze dried" widgets. They're not code; they're properties like size, location, appearance, etc. At runtime, the objects are reconstituted and wired up to code. Obviously, in the Java world, this is a job for serialization, right? Instead of dumping hundreds of lines of GridBagLayout to a file with big nasty "do not edit anything below this line" comments, we'd have serialized objects that could simply be deserialized, then we'd make a method call to attach them to the rest of the application (the value of model-view-controller should be quite obvious in this scenario, where the "view" isn't even code anymore, forcing you to migrate your logic elsewhere).

If this is such an obviously nice way to do things, why hasn't it been done yet? Well, the straightforward serialization approach is kind of nuked by the warning that appears on every Swing widget's javadoc:

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. A future release of Swing will provide support for long term persistence.

Well, OK, fine. All Swing widgets are JavaBeans, right? In 1.4, we can serialize with java.beans.XMLEncoder instead.

So if this is such a good idea why isn't it happening? I don't know. When asked, I speculated that the Mac's Interface Builder has the luxury of absolute positioning - the sizes of buttons, fonts, etc., on the Mac can be expected to be fairly static. This clearly isn't true in Java, since we hop platforms. A Mac button is a different size than a Windows button. Heck, I can have different widget sizing on the same platform by hopping around the available look-and-feels - can anything intended for the Motif L&F look right in another L&F? That's why we use LayoutManagers, to express the relationship between widgets - that they're arranged in a certain spatial order or that some get extra space and others don't. Can a GUI present a LayoutManager effectively? I think so - I remember Visaj making even GridBagLayout feasible in a GUI tool.

Maybe the blocker is that even when unfrozen and laid out, the different sizes of widgets still afford a surprise factor, but this should be true of code-based layout too. Nothing is a good substitute for actually testing on the major platforms.

So, I don't really have a good answer. It seems like this would be a nice way to develop and deploy apps, and a lot of people have talked about it for a long time. But it still hasn't happened. What's the blocker?

You Call That An Application?

So, I've done the nice Java thing and deployed my applications as executable jars, with properly formatted manifests, and, um...

well, I'm feeling a little underwhelmed.

Let's face it, those don't look like applications. Nothing about them stands out in a folder and says hey, double-click me!

Oh sure, I could use an application to create an "installer" for my application. That would wrap my jar with an .exe on Windows, put it in a .app bundle for Mac OS X, etc. But I'm not entirely comfortable with reducing "write once, run anywhere" to "write once, run wherever the installer bothers to support".

Is a Java application just a class with a static void main (String[])? I think that fails to capture many of the behaviors we typically expect from desktop applications, such as:

• A custom icon.
• Document association (the ability to launch and open docs when they are double-clicked, based on metadata about the file like its filename extension, Mac TYPE/CREA, BeOS MIME type, etc.)
• The ability to ask for the user's attention while in the background (flashing the button on Windows task bar, bouncing the Mac OS X icon, etc.)
• Provide a real name to the rest of the OS (ever run five java apps on Windows, noticed one has hung, then gone to the Task Manager and had to guess which of the five "Java"s needed to be killed?)

While I'm at it, I'm going to be greedy. After all, I played with Project Builder on Mac OS X to bundle up a java app in a Mac wrapper recently, and I'm jealous of some of the things that developers over there can take for granted in native applications, including:

• A standard for placing localization files. Sure, we have ResourceBundles in java, and a scheme for locating them based on the current Locale, but where do they go? Do you have one per class, one per package, or one per application?
• Same thing for artwork. Yeah, both L10N files and artwork can go in the jar file and be found along the classpath with a ResourceLoader, but if that's such a great idea, why don't we standardize on some paths in the jar, instead of making new developers repeatedly re-invent the wheel? This would be great for tools too.
• Java command-line args. Ever tried to set something like the max stack size (the old -mx command-line arg for "java") with a double-clickable jar file? Last time I checked, no amount of Manifest voodoo could do this. But Project Builder will do it for pure-java bundles on OS X.

To top it all off, I don't want to get any of this by going outside of standard Java... maybe I could get some of my application behavior with a mixture of a platform-specific installer and some JNI code to get outside the Java "box", but then I'm radically limiting the number of platforms, present and future, that my app can run on.

Obviously, this is a big wish-list. And I don't have all the answers. But I think I see where part of the problem is.

I've been openly envying Mac OS X application development above, so let's look at the layers involved with a Cocoa app:

• Language - in which we write the behavior specific to our application - Objective-C (or, if you're gutsy, Java)
• API's - which provide common functionality to applications - CoreFoundation, Quartz, QuickTime, etc.
• OS - which executes the code and provides the display, sound, networking, I/O, etc - Mac OS X

• Language - Java
• API's - Java core libraries
• OS - Java Virtual Machine

From what I can see, we have a very nice language, a vast set of API's, and a runtime environment that's not holding up its end of the deal. When people complain to me about the inability of Swing to deliver professional applications, I tell them that I don't think that it's Swing that's lacking. Surely anyone developing AWT or SWT applications has the same problems developing apps that act like real apps.

What do I want from the JVM? I think two things need to happen:

• There needs to be an Application class or interface that gives us some kind of abstraction of behaviors like requestUserAttention() to bounce an icon or flash the task bar. The JVM then provides a platform-appropriate implementation, if any.
• There needs to be a standard for where we put localization files, artwork, etc. inside the jar. Maybe also files defining file-associations by filename extensions, MIME types, or other predictable and somewhat standard systems. And a file for java runtime arguments.

I know, this is probably idle dreaming. But something along these lines would make it easier for developers to make "first-class" applications in Java.

Widgets follow form follows function

Years ago, I worked at CNN Headline News as a Writer / Associate Producer, which pretty much meant I was an editor, except they paid me the Writer/AP salary (the editors, in turn, were really producers, etc., up and down the corporate ladder).

At the time, the de facto standard for newsroom computer systems was "Basys", which wired dumb terminals to a mainframe, and let users view directories, edit files in those directories, print, and roll text up a teleprompter.

The commands in Basys were cryptic, and learning the keyboard took a long time. At CNN, the numeric keypad was repurposed into a collection of cursor-movement and text selection keys. Even if you'd been touch-typing since age 10, it took a while to get the hang of it.

Then one day, they installed new Windows desktops in the newsroom, with a new GUI Basys client (I think it was from Avid, who bought Basys). Now the directories could be browsed in a familiar "tree" format, text could be managed with familiar mouse gestures, and it was in eye-pleasing colors instead of 10-year-old, burned-in dumb-terminal gray.

And we all hated it.

Despised it.

Threatened to quit if they didn't get rid of it.

To the software engineers, this must have been outrageous. I can imagine them saying Don't you see how much better this is? You can see the heirarchy of the directories! You can copy-and-paste from other applications! You can have many windows open for your source stories instead of wrangling a simple emacs-style split! You can ditch the keypad!

What they didn't understand was that the crummy terminals were crude, but once mastered, they were very, very, fast. Remember how fast Data on Star Trek could operate the flat-panel controls of the Enterprise? We were faster than that. Select-word, bangbangbang, del, typetypetype, readreadread, scrolldown, readreadread, scrollup, arewecool, yeah, save, print!

Having to manage windows and mouse around might be easier for the novice, but it absolutely strangled the expert. A top speed with the GUI was nowhere near the top speed with the dumb-terminals.

And this is is the important part: editing speed turns out to be the absolute number one priority for a newsroom system. If a GUI costs me five seconds, it might mean that I can't get a breaking story to an anchor in time to read it.

So while the GUI was fine in and of itself, it totally failed to meet the users' primary needs, and was quickly abandoned.

This is one thing I was thinking about when I read Philip Brittan's weblog on usability in Java apps. Not that I disagree with him at all; I just want to reinforce the point that good-and-bad in a GUI doesn't necessarily derive from the merits or deficiencies of the GUI API.

That newsroom GUI could have been written in Swing, MFC, or Aqua and we still would have hated it, because the underlying concept was completely wrong.

Philip makes this point when he quotes the CIO who implies that open-source apps seem to do no usability work, and I think implies that many Java GUI's are developed the same way.

But the comparison to Windows applications is a trap. Don't assume that mimicking existing apps on Windows or any other platform is a valid approach in and of itself. Here's why: I remember a few years ago, I was at a company where a product manager - and apparently this was his entire output for a month of work - did a little five-page document saying how great Microsoft Outlook's GUI was, and how that should be a model for our application.

Problem is, our application wasn't an e-mail client, it was a networked media browser/distributor. Sure, in the broad view there are some concepts that carry over, like seeing items (e-mails or media clips) in some sort of broad view and then getting a detailed view through a double-click or a paned approach. But that's after thinking in the abstract. I think he really wanted it to look and behave as much like Outlook as possible. Even though that didn't really make sense.

It reminded me of the novel The Fountainhead, in which the hero, Howard Roark, is an individualist architect who understands that form follows function, that there's a right way to build things in order to be what they're supposed to be. However, many around him insist on ruining his designs by making unrelated, even dangerous additions, trying to bring in other ideas because those ideas have worked before (and as a means of tearing down Roark's individuality). To them, you put greek columns on a log cabin, simply because many great buildings have greek columns.

You probably see where I'm going. A good GUI has given features if, and only if, that's the right thing for that application. You don't use MDI just because Office does (well, it used to), you use it if you think that's the right way to handle having multiple documents open. You don't do modal dialogs because they're easy, you do them because you absolutely cannot allow anything in the app to continue without getting a response from the user.

In one recent monitoring app, I ditched the simple JTable approach of our prototype in favor of a list with multi-line cell renderers, even though it wasn't easy to code. I got the idea from the download managers of the OmniWeb and Safari browsers, which showed me why the table approach of IE's download manager sucks so much. Like them, I didn't need table columns to vertically line-up the things I was displaying, and using custom list cells, anchored with a colored icon on the left that showed the item's "priority", allowed me to use fonts and size to make the most important fields more readable at a glance, instead of getting buried like they did in the table. Plus, the layout could ensure that the media names didn't get cut off like they did in the table. Did I do this because I like OmniWeb and Safari better than IE? No, I did it because the multi-line list approach made more sense for what I was doing than the table approach did.

Knowing the right way to do a GUI comes from knowing what the app is supposed to do and how it will be used. Without that knowledge, the GUI is doomed.

Maybe you can know it up-front, maybe you'll find out through prototyping and feedback (something that Extreme Programming does well), but you have to own the problem domain if your GUI is going to make any sense at all... or be defensible when someone tells you it has to look like Outlook, or use tabs, or have a slide-out "drawer" like all the cool Mac OS X apps do now.

So Swing isn't the answer, and neither is SWT. Or MFC. Or Aqua.

Learning what your app is supposed to do is the answer.

The End (of Java3D) and the Beginning (of JOGL)?

Anecdotal evidence has been brewing for a while that the Java 3D API has been in a state of decay. Today's events seem to resolve the situation, with a much more promising future for 3D graphics in java than when we woke up this morning, even if that future doesn't seem to include Java3D itself.

Much speculation about Java3D has come from developers on Mac OS X, which has never enjoyed a publicly-available implementation of the API, despite many heated appeals to both Sun and Apple to make it happen.

In June, a thread appeared on the Apple java-dev list entitled "Any mentions of Java3D at WWDC?". In a response, Paul FIsher summarized what he'd heard and seen at JavaOne and the Apple WWDC. He wrote:
This would jive with what seemed to come out of Java One which, to paraphrase, was basically: While Sun isn't getting rid of Java3D they aren't exactly pushing it or particularly supporting it. Since JOGL was mentioned at JavaOne and Java3D wasn't you can reach your own conclusions. As others have stated over the last week or so, Java3D is not particularly likely to show up on OS X (unless Sun all of a sudden decides to simply open-source it ... given that it seems headed for the dust-bin I would settle for a 'port' of the black-down version to OS X ... performance warts and all).

The topic came up again today in a discussion of Java API's that have native-code requirements and, per apparent Sun policy, are not ported to Mac OS X. Norris Weimer connected more of the dots in his message, in which he noted:

• that the chief architect of Java3D, Doug Twilleager, was now re-introducing himself as the chief architect of the Java Games group
• that Twilleager was pointing people to a project providing open-source Java bindings to the OpenGL graphics library
• that none of the developers previously known to be working on Java3D was now known to be working on it

For those who read the tea-leaves, the message was clear: Java3D was done for, and it appeared the preferred alternative would be to use JOGL, hosted right here on java.net. It was all over but for the press releases.

The first one appeared today.

On SGI's website, the press release announces "SGI and Sun Microsystems' Software Platforms to Work Seamlessly Together with Java Bindings to OpenGL... Joint Development Agreement Will Enable Millions of Java Users to Easily Employ OpenGL for Wide Range of Graphics Needs". An identical article appeared on Sun's site, though there has not yet been a mention of the announcement on the JOGL or Java3D page, nor here on java.net.

The reaction is sure to be controversial, especially among those who have invested in Java3D. While that API will presumably continue to work as it does today, developers generally avoid buying into a technology that with no future. On the other hand, supporters of OpenGL, and developers on Java3D-less platforms are sure to be delighted, since this will get them into the 3D-in-java game.

There's also a big picture that merits consideration. The idea of Java3D was to provide an isolation layer between java and an operating system's underlying 3D toolkit - generally meaning DirectX on Windows and OpenGL on other desktop OS's. The fact that that this strategy has been rejected, apparently in favor of getting OpenGL onto Windows machines, raises interesting questions about how practical such an isolation-layer strategy is. Is it too much work to provide the appearance of a happy and fast java 3D API, and easier to just pipe calls to a native API? On the other hand, does this approach make sense for java on hypothetical operating systems that don't use OpenGL, for example game consoles? Will java paint() itself into a three-dimensional corner?

Interesting times... in the Chinese curse sort of way.

Java sightings at MacHack 2003

The idea of the MacHack conference - 48 hours of talking and coding, with an emphasis on doing clever but useless things with code - seems like it would cater exclusively to platform-specific Mac coders. But instead, Java has been a big part of this conference.

Ken Arnold's delightful keynote started with principles of good design, both of end-user applications and of API's offered to other developers. It was somewhat revelatory to note that JButton about 450 methods available. In a re-imagining of this class he showed how you could expose only the kinds of methods most developers will use or care about (setting button text, enabling and disabling, etc.), while not baffling beginning developers with methods that only a LayoutManager would ever call.

Ken also talked about this approach as expressed in jini and its concept of exposing ever-changing java-based services on an ever-changing network.

I gave a session on QuickTime for Java, while java.net editor Daniel Steinberg offered up two sessions: one on tuning Java applications for a more Mac-like experience (with and without code changes, with or without a Mac), and a second on Jini vis-a-vis Rendezvous.

But the real fun is the hack contest, where attendees offer up clever or pointless (preferably both) code hacks. My offering was a screen grabber written in QuickTime for Java, which allowed me to get to the full-screen drawing surface. My code is awful; I have a completely pointless conversion from a QuickTime QDGraphics to an AWT Image and back... but efficient or elegant code is so not the the point at MacHack. Anyways, its one claim to usefulness - which is bad in the MacHack way of thinking - is that it can do screen grabs while playing a DVD, which Apple's Grab.app won't:

Apparently, despite the fact that every copy of Mac OS X comes with Java 1.3.1 (with 1.4.1 a software download that's offered to you immediately after the install), the idea of a Java hack was a curve-ball. Their form for keeping track of the language or API of submitted hacks didn't have "java", so I got filed under "other"

Presumably, so did Ken Arnold's moodring, an exceptionally clever Jini application. The idea of this app is that users join the group and express their mood on a range from "Ecstasy" to "Hell", colored as blue to red respectively. The mood of all participants is averaged for a "group mood". As members change their mood, the change is quickly reflected on all users' desktops:

James Duncan Davidson described the result in a weblog from earlier this morning - audience members were encouraged to grab the app and join the demo. Thanks to Jini discovery, about a dozen people joined the group with no configuration necessary - just click and go. In fact, the bottleneck wasn't Jini, but the number of connections available to Ken's machine to download the app.

Daniel says, and rightly so, that a user shouldn't know or care what language an application is written in, just what it does. Hopefully we'll see more Java-based MacHacking in the future.

This work is licensed under a Creative Commons License.