In Which I Think About Java Again, But Only For A Moment
It’s amusing how Steve Jobs’ remarks disparaging the idea of Java on the iPhone have ignited controversy. His point was, obviously, that the iPhone’s browser won’t support Java applets; which is a no-brainer because applets were killed dead-dead-dead by Flash and Ajax. But this seems to have riled up everyone who still cares about non-server-based Java, leading to the weird situation of seeing “Java” and “Mac” in the same sentence again*. Apparently some people still cling to the glorious dream of writing cross-platform GUI applications, waving tattered “Write Once Run Anywhere!” banners and clutching ‘Little’ Red Books with Duke’s picture on the front.
Flashback
Me, I defected long ago. I’m another of those Apple Java engineers who dropped out. I spent five years as a raving Java fanboy, but I gave up after optimizing AWT, implementing drag and drop, and trying to make 1,200 pages of crappy APIs do the right thing on the Mac. Then I took a one-week Cocoa training course, and wrote the first prototype of iChat.
Desktop Java never worked because Sun tried to build their own OS on top of the real OS, duplicating every API and feature. This led to terrible bloat, making every app as heavyweight to launch as Photoshop. Worse, the GUI portions of the Java platform are awful, because Sun is a server company with no core competency at GUIs. The APIs are too clumsy to code to, and compared to any decent Mac app, the results look like a Soviet tractor built on a Monday.
Why Cocoa Pwnx0rz
That Cocoa training class was, as I’ve said before, one of the biggest eye-openers of my career. It was so damn easy to build beautiful, functional applications that I walked out feeling like I’d climbed into some giant mecha robot and could now lift huge girders with a wave of my pinky.
Three important things you need to be able to make apps with great human interfaces:
- You need to lay out the user interface components visually, by hand, with total control over where they go. Automated LayoutManagers don’t cut it. A corollary of this is that you can’t move a UI layout from one platform to another and have the computer make everything fit. Computers don’t lay out interfaces by themselves any better than they can translate French to English by themselves.
- You need to be able to change the UI around really easily during development — after user testing, or a Steve Jobs encounter session — even after you’ve attached a lot of code to it. That means no RAD tools that write code for you, because once their code mingles with your code, it gets hard to disentangle. Instead, the UI should be described with data, like an Interface Builder “.nib” file.
- Changing the UI around also requires being able to change your own UI code easily. As the Ruby and Agile Programming zealots always point out, strict type checking can really get in the way of this. Writing endless Listeners and Adapters and inner classes was one of my least favorite parts of Java programming. Objective-C and AppKit have a good approach, letting you use type-checking where it’s important but leaving looser connections at the UI level so you can plug and re-plug connections easily.
My Theory
My theory is that Java desktop apps succeed only in niches where UI design and usability don’t matter: development tools and enterprise software. Programmers expect things to be crude and complicated: anyone who’ll voluntarily use ‘vi’ in the 21st century will put up with anything**. And the poor users of enterprise software don’t have a choice: they have to run the damn app no matter how awful it is, because it was selected by an MIS department that could care less about usability.
Footnotes
- Not that this controversy has anything to do with the Mac. The iPhone is not a Mac, the Mac still runs Java, and no one is talking about taking it away.
** And that goes for ‘emacs’ too (with apologies to my boss). I thought emacs was really cool, in 1986. That’s when it was really cool to have a DEC VT220 terminal in my dorm room with a 9600 baud connection to a VAX running BSD 4.3. Also, I listened to Depeche Mode.
January 22nd, 2007 at 6:24 AM
“When your GUI is all rounded and aquay, everything that’s more sober and edgy and maybe gray looks a bit out of place…”
There’s nothing that says a Java app can’t be rounded and aquay on the Mac, as long as Apple provide ways to access Mac-specific features from Java. They are doing some work in that area, but not nearly enough. For example, when I wanted to add a proxy icon to my window title bar I had to jump through all sorts of hoops to get it working. Solaris and MS Windows have no equivalent concept, so of course there’s nothing comparable in the Java API, but if Apple themselves provided a simple way to do this and similar things from Java then developers would use it, and you’d see far fewer “ugly” Java apps. You almost feel Apple know they need to support Java, but don’t want to make it too easy to write nice apps because they don’t want to threaten Cocoa.
January 22nd, 2007 at 7:37 AM
Rolf, the point is that the minute you start using these speculative API handles, you have to use their (speculative) equivalent on Windows and on Linux too. Soon enough you’re just using Java as a big GUI toolkit, and there are better GUI toolkits out there.
Java apps aren’t “ugly” because Java apps are functionally inferior with regards to things like proxy icons, they are “ugly” because they are Java and thus multiplatform.
Multiplatform, great, true-to-your-specific-platform - choose two.
January 22nd, 2007 at 7:57 AM
Rolf said—
“There’s nothing that says a Java app can’t be rounded and aquay on the Mac, as long as Apple provide ways to access Mac-specific features from Java.”
But doesn’t that fly in the face of the whole Write Once, Run Anywhere mantra?
M$ did exactly that with J++and their JVM and got ripped by Sun, right?
January 22nd, 2007 at 8:05 AM
In my experience, it’s not Java or the tools that makes a bad GUI app, it’s the programmer/designer.
It’s perfectly possible to write a good Java desktop app with Swing. It’s also possible to write one with SWT (although I’m not a fan of it).
Those programmers that can’t seem to write good desktop Java apps probably don’t know their Swing (or SWT) very well, or generally don’t have a clue about writing good UIs.
January 22nd, 2007 at 8:11 AM
Eclipse is a good example of a good UI written in Java.
Unfortunately so often DEVELOPERS write and not UI DESIGNERS.
It’s easier to find a good UI Designer for Mac, Web, more difficult for Swing.
Why? Swing is difficult to use, to obtain good results you must be a good DEV and a good UI Designer.
January 22nd, 2007 at 8:18 AM
M$ got into trouble not because they extended the capabilities of Java by writing new APIs but by changing the existing core language and API in direct contravention of the license they had.
Jesper, I’m not sure what you mean when you say you have to a speculative equivalent API on Windows and Linux.
In my code I have a method that sets the window proxy icon and filename when running on a Mac and a stub implementation that does nothing under Windows. This means I can write the code once and run on Mac and Windows. The Windows version will be missing one particular feature, but you can certainly use the app without it (indeed, vast numbers of Mac users don’t even know that you can Command-click on the title bar icon, but that’s ok).
It’s also pretty easy to ensure that a Java app uses the system wide menu the way you’d expect on the Mac, that the Preferences command appears under the app menu on the Mac and the Tools menu on Windows, and so on. I really don’t see the problem here.
January 22nd, 2007 at 9:55 AM
Java. Amen.
As for Mac GUI look at nib4j.
January 22nd, 2007 at 10:13 AM
I learned to write Cocoa apps in about a month a few years back and loved it…have written a couple of Java apps this past year (had to run on both win and mac). I have no problem with Java as a language, but the Swing/ANT APIs remind me of the complexity of the Classic Mac OS compared to Cocoa. I can write apps in both Cocoa and Swing, but I find Cocoa much easier.
Glad that I can use Xcode for Java development, though, and not have to pay a nickel to develop stuff.
January 22nd, 2007 at 10:16 AM
A few points from someone who is currently (and rather successfully) building Java applications which follow the look and feel on MacOS X, and on Windows and Linux.
First, I will agree with you regarding the bloat of Java on version 1.2 and earlier. Java 1.2 is basically worthless for development purposes. Java 1.3 is barely useable—and it’s only when we get into Java 1.4 do we have a managed environment with any performance whatsoever. The fact that Apple is shipping Java with MacOS X makes the Macintosh the ideal environment for developing and deploying Java applications, and the startup time for a Java application on modern shipping Macintosh systems is roughly half a doc icon bounce longer than a comprable Cocoa or Carbon application. (And I’ve written applications in both Cocoa and Carbon.)
Second I agree with you that writing an UI based Java application in AWT is a useless and worthless exercise. That’s why Sun introduced the Swing API. Writing a Java application in Swing is much easier—and with a few minor tricks documented on Apple’s Java web site, it is easy to create a Java application which places the Swing menu in the menu bar where it belongs, and to use the Aqua look and feel.
Of course the trick of getting your application to look correct is heavy use of custom LayoutManager objects—the default layout managers are worthless for development. But you really only need a few: a custom DialogLayoutManager to put the dialog buttons in the right place and a custom DialogControlLayoutManager are absolutely essential.
As to the Java Swing API verses the Java Cocoa API—both suffer the fundamental problem of placing the burden on event management on the user when it is possible to shift some of the burden on the framework. Both require that you explicitly tie every menu item and control to the receiver of the activation event, which can be extremely tedious. Far easier to use a ‘Chain of Command’ design model to allow the menu events to “percolate” up from the current focus holder through the hierarchy of controls in the current window through to the top level application object. This makes it far easier to handle the menu event depending upon the context in which it is used. (Much easier than the First Responder in Cocoa.) And while Cocoa’s visual layout tools are excellent, the underlying code which handles laying out the Cocoa elements is basically no more powerful than the SpringLayout class in the Java Swing API.
Where Java falls down is that the Sun engineers have confused “giving the user tons of options” with “powerful API”, making it easy for someone to feel lost. Java developers tend to come from the Linux UI school of thought, which seems to be “standards? we don’t need no stinkin’ UI standards!” This is made worse by the fact that Sun advertises Java as “write once, run everywhere,” which is interpreted as “…and no testing required.” The latter part is a lie: any good Java UI application will have a ton of special case code depending on the OS the application is running on, in order to handle the various quirks that come up. (Do scroll bars go away when they’re not needed or do they just go inactive? Does the OK button go to the right or to the left of the Cancel button?)
Because most Java programmers don’t bother with these details, most Java applications look like crap. But it has nothing to do with Java Swing—only with poor programmers.
I’m sorry that your experience with Java was limited to Java AWT and v1.2 or v1.3. But things are significantly better today, and I would place the Java Swing API on par with the Cocoa API for building UI based applications—both have their advantages and disadvantages.
For me, if I had to pick an API to build a UI application in, I’d pick Java Swing if I had to create something that was cross-platform, and Cocoa if I needed to build something MacOS X specific.
January 22nd, 2007 at 10:17 AM
…not to say that there aren’t other free IDEs for Java other than Xcode! I meant I don’t have to pay $XXX for any M$ IDEs to get an app running on windows.
January 22nd, 2007 at 10:39 AM
Try http://www.squeak.org if you really need cross plattform (including the UI).
It’s a free Smalltalk implementation, where the Virtual machine is easy to port since
it is written in itself.
At the first look it’s not so shiny like other UI’s since it was especially created for
kids. But others try to invent the (UI) future with it (see http://opencroquet.org).
January 22nd, 2007 at 10:49 AM
I totally agree with your opinions. Java is heading towards more of a data-retrieval-web service provider language/framework.
Especially with the whole new SOA practices in place, it’s just too convenient to abandon java all together.
I personally am in the middle of a project that utilizes ASP.NET as a front-end that consumes java web services.
As far as the windows desktop goes, it is definitely not a competition when it is compared to XAML, although it is a very new technology. In at most a year, it will take over 90% of new windows application development. More on this on my web site.
Regards.
January 22nd, 2007 at 10:58 AM
So when are they going to release your optimized AWT?
…
Michael Tsai’s comment is insightful. There are many layout tasks where automated layout managers save a lot of work relative to springs/struts/handcoding resize behavior.
January 22nd, 2007 at 11:55 AM
Hey, hold on about “vi”. Vi rules. I don’t agree it is so difficult to learn, but even if it is it is worth it. Vi/gvim are power editors.
January 22nd, 2007 at 12:39 PM
Worse, the GUI portions of the Java platform are awful, because Sun is a server company with no core competency at GUIs. The APIs are too clumsy to code to, and compared to any decent Mac app, the results look like a Soviet tractor built on a Monday.
My initial reaction to Java’s GUI was more or less WTF? No one who had done much GUI work would ever do things the way they did.
January 22nd, 2007 at 2:23 PM
Actually, what you list sounds to me like entirely problems with Java’s APIs, not with the programmers. How is it the programmers’ faults that Sun decided to put so much into the API?
Blaming the end programmers when an API is bad is exactly the same as blaming the end users when a UI is bad.
I’m pretty sure Jens’s entire point revolves around the fact that Cocoa is a well-designed and powerful API. He starts out with the vi/emacs analogy for a reason…
January 22nd, 2007 at 2:44 PM
There were 8 MILLION Opera Mini users just last month before they added SSL and RSS support which should have exploded user numbers. That is J2ME 2.0 App for you which “bells and whistles” “hi fi” version is 98 kb (yes kilobyte)
Azureus became the standard in bittorrent community which is entirely (latest and greatest) java. That app is running for MONTHS in some situations.
Why Apple doesn’t want java? It is open, standard, zero tolerance to monopolies and force of direction where language goes. E.g. you may see Ericcson and Nokia work on same JSR.
They don’t want a general developer profile work freely on their machine, it is their choice and opting to buy a symbian 60 or embedded linux based device is our choice.
If I had a iPhone now I wouldn’t be able to login to my bank since their password generator uses J2ME.
They assume every phone has MIDP 1.1 java in 2007.
January 22nd, 2007 at 2:54 PM
Some are crazy enough to claim J2ME is dead. On sites like getjar.com, 400.000 downloads are common. Just because Steve Jobs doesn’t want J2ME unlike ANY manufacturer on Earth, it doesn’t make it dead. 2 billion devices are capable of running java and some uses them for real life purposes, some for cell phone games which are larger than you can imagine.
In fact, lets talk again when you need to contact a MSN messenger using person and iChat [of course] can’t do it. I had such situation and I simply installed a freeware, open source J2ME messenger. That is what Apple doesn’t allow you and you can defend this decision.
January 22nd, 2007 at 4:10 PM
I am more or less with one of the commenters on that page who said it’s largely up to Apple to make Java work well on the Mac and to give developers access to the few unique mac features so they can make their apps look like native mac apps. Why didn’t Apple come up with something like Nib4J? The Apple Java implementation was pathetic for a very long time.
In an ideal world, we would have IB + Java for Cocoa app development… I sometimes get annoyed with Java’s strict typing but I can’t imagine how large-scale refactoring could work without it.
I can’t get too excited about the iPhone’s missing features until it’s out but “no 3rd party apps” and “no Java” certainly go hand in hand. I don’t know why you would not want 3rd party apps on the phone - it’s weird. We will have to wait and see whether that is nonsensical, or Apple just wants to control all apps like Sony controls all PS games, or what other secret taking-over-the-world plan is behind it.
January 22nd, 2007 at 4:16 PM
“Azureus became the standard in bittorrent community”
Azureus, powerful as it is, has one the WORST UIs ever designed by man. You couldn’t pay potential iPhone customers to use it, if it were possible to load it on an iPhone. The iPhone is not targeting the “bittorrent community.” If I wanted to use the Java crap on all these phones out there, I’d buy one of those instead of the iPhone. The fluidity of the iPhone UI promises so much more. I expect more.
Why should the iPhone user experience be severely diluted by UIs designed for the lowest common denominator? If Apple allowed non-Java apps on the iPod with a 100 million userbase would developers simply ignore it because they couldn’t sell the same app on some $69 PlaysforSure monstrosity?