Symphonious

I’ve had my old powerbook lying around for a fair while now not doing anything so I thought it was time to put Linux back on my desktop. I’ve pulled the laptop back off the shelf, booted it and found Debian is already installed and running okay. So I officially have Linux running on the desktop!

Now what?

Martin Pool gives an informative pros and cons list of Ubuntu Linux versus a number of other OSes. I’d like to jump off on a tangent. Martin gave a plus ot Ubuntu for:

+ Less Macintosh historical baggage. Mac apps can be in the wierd state of running but having no windows open: GNOME designers just know this is silly. OS X suffers some friction between the Mac and Unix parts, in e.g. case sensitivity or resource forks.

While there is definitely some historical baggage in Mac OS X (not much mind you - Apple were pretty ruthless with cutting things out), the ability for an application to be running without any windows open is actually a design feature and not historical baggage. When described as “the wierd state of running but having no windows open” it sounds downright stupid, but if you describe it as “the ability for the menubar to not disappear suddenly when closing a window” it makes a lot more sense.

The Macintosh menubar is placed at the top of the screen because it’s significantly faster to access the menus when it’s placed there (plenty of research backs this up - essentially the sides of the screen have infinite depth so they’re easy to hit). Since the menus are at the top of the screen and not in the window, it makes no sense for the menubar to change when you close a window. Thus, when closing a window in an application the application continues running allowing you to open a new document, adjust preferences etc etc. That’s not the only reason though. Think of someone using pen and paper who has two tasks to complete. They start the first task by getting out a clean sheet of paper and writing on it until they are finished. Then they file that piece of paper away. Finally they start the second task by getting out another clean sheet of paper and starting writing again.

In other words, the life cycle is:

1. Create a new document.
2. Work on document.
3. Save and close document (filing both saves the paper and removes it from the workbench)
4. Create a new document.

If you were using Gnome, Windows or pretty much any OS other than Mac OS, step 3 would suddenly cause your pen to jump back into the drawer. You’d actually have to rethink the order you do things in to open a new document before you close the previous one.

Now you might argue that people typically work on more than one thing at a time and they are likely to have both documents open anyway. They might indeed but in that case there is another subtle benefit. When they decide they’ve had enough of work and want to put it all away and play a game, they simply hit command-Q and all of the documents in that application close. It’s like having a bulldozer that can file things neatly.

The disadvantage to the Mac OS way of doing things was that on OS 9, you didn’t realize the application was still running and either ran out of RAM or got really confused when you next double clicked on the application and nothing happened (in fact the menubar changed but noone seems to notice that). OS X (and the magic of modern computing) solves both these problems. Firstly, you won’t run out of RAM anymore because OS X has virtual memory and the ability to move things around in RAM (OS 9 loaded things in order and fragmented memory effectively couldn’t be reclaimed - plus the virtual memory was really bad). You could leave every application on your system open in OS X and it just wouldn’t matter because the unused applications would be paged out to virtual memory. Note that because they are unused they wouldn’t constantly have to be paged back in either so no hard drive thrashing.

The second problem is solved in two ways. Firstly there is a reasonably obvious indicator that an application is open (the icon appears in the dock if it wasn’t already there and a black triangle appears under the icon). This helps a little, but not a lot. The biggest improvement is the Aqua Human Interface Guidelines change which now requires that when the user clicks on an application in the dock or double clicks it in the Finder (the same actions used for opening it) the application will bring it’s existing windows to the front if it has any, or create a new window if not.

If you combine the effects of these two changes, the result is that the “weird state” of an application being open but with no windows effectively ceases to exist. The user can be completely unaware that the application is running and continue to go about their work without ever noticing. When they try to open the application again it behaves exactly as it would have when first opened and displays a new window. There is no noticeable impact on resources because the RAM can be swapped out to disk and made available to other applications and modern hard drives have plenty of space to cater for this. The user is now able to operate in their logical order without menubars unexpectedly changing on them.

So as it turns out it’s the GNOME developers who got the UI design wrong predominately by putting the menubar in the window instead of at the top of the screen. Once they’d made a mess of that behavior, it wasn’t really an option to avoid the disappearing menubar problem because the menu is so inextricably linked to the window.

My Queen CDs are here! Yay! I ordered “Queen - Greatest Hits I, II & III” a week or so ago after getting hooked on both We Will Rock You and A Night At The Hip Hopera and it’s finally arrived.

I’m in the process of dumping into iTunes now (Apple lossless encoding so even the purists should be happy) and will then commence burning a copy of the CDs to listen to in the car (CDs don’t tend to like the extremely high temperatures cars get to around here). I don’t particularly care if that illegal in Australia - I want my Queen in an accessible format and I don’t want the CDs to get wrecked.

Besides, since I bought it from the US I get the same rights as if I were in the US right? I like that logic anyway. Besides, I just deserve it, I’ve earnt it - it’s my precious.

A little while back I said duplicate code was the biggest codesmell I knew of. I was wrong.

There is a level of smelly code that goes well beyond duplicated code, in fact it goes well beyond anything a professional programmer would ever do. That is the smell of code that doesn’t have JavaDoc comments. From time to time every programmer will get lazy and not bother to add a comment for something but every so often you come across a code base that seems to have a systematic policy of removing any JavaDoc comments that might prove useful.

Sadly, I was reminded of this when attempting to use BCEL. Vast swaths of that project are completely devoid of JavaDoc comments. Maybe the functionality of those methods are completely obvious to anyone who’s ever touched the codebase, but I’m trying to work out how to use the library so I need to at the very least be told “this method is not for you - go away”.

In the end I gave up and used ASM which is still fairly light on JavaDocs at times and quite often the JavaDocs that are there are too abrupt to be particularly useful but at least there’s something. All the same, the process of using ASM is essential a case of trial and error unfortunately.

So if you ever teach anyone Java, beat into them how useful, powerful and important JavaDoc comments are. It doesn’t matter how neatly laid out your code is or how obvious the functionality may be - most people who go to reuse the code are going to look only at the JavaDocs either through the generated HTML or through their IDE. Make sure the information there is useful.

It appears the java.net crowd picked up on my labeling some of them wingers - the response has been much more polite than I would have expected (or deserved really). The most well reasoned response so far is from Chris Adamson who points out the history of Java releases lagging behind on Mac as a reason for people to be worried.

Before I go into Chris’s comments, let me point out that there are two main groups of people:

1. Those that are concerned that Apple will take too long porting the JVM and they will have problems working on their projects that move to Java 1.5. These are the people Chris seems to have in mind.
2. Those that are complaining that Apple doesn’t have a JVM out right now. These people are expecting way too much and were mostly who I was directing my whingers comment at.

To be clear, I was directing my wingers comment at both groups because I’m sick to death of hearing “when is Apple going to release X?” where X is anything Apple may or may not ever release. The answer is always “Apple doesn’t comment on future products unless it suits their purposes”. I’ve known that since I was 7 (in that case it was related to the ill-fated HyperCard - the best anyone’s gotten in the 15 years or so since that they’ve been pestering Apple is a comment about drinking Clorox) so I don’t think it should be too hard for people to work it out. It also shouldn’t be hard to work out that the question has been asked a million times on the Apple Java-Dev list nor should it be hard to work out that the Apple Java-Dev list is not an official feedback channel (it says so in the list description).

In fact, anyone who’s been dealing with Apple should know by now that the only way to get Apple engineering to get anything done is to log a bug. Apple judge the priority of issues based on the number of times they are reported. This applies both for actual bugs as well as feature requests. Apple also has an official contact page on their web site - it’s much more effective than your blog for getting Apple’s attention.

All up, people who find themselves complaining that Apple doesn’t already have a version of Java 1.5 publicly available hasn’t done their homework. If you follow Java development on Mac these repeatedly misdirected complaints about Apple’s Java support become extremely annoying and hence should be labeled whinging.

To provide some examples of the second group of people, let’s take some of the comments from my last entry:

If you install Tiger (java) on Tiger (OS X) then copy the binaries onto OS X (Panther) it works fine.

So Apple totally could have released Java 5 (beta) for Panther a very long time ago. Sigh. — James Strachan

No James, it won’t run perfectly - in fact it won’t run anything that uses Swing or AWT at all. I imagine it would be somewhat difficult to pass the JCK if you didn’t have any support for GUIs. Furthermore, as far as I’m aware noone has done any comprehensive testing of the Java 5 prerelease on Panther at all so it’s quite possible that even what has been implemented doesn’t actually work in all cases. It’s fairly unlikely that the entire JRE suddenly became dependent on Tiger, but it is quite possible that some part might be and that that part simply hasn’t been discovered by someone running it on Panther yet.

The real idiocy however comes from “Gili”. He said:

Again, had Apple made this a priority they could have released a port of JDK 1.5 GA within a month of Sun’s release.

which might have been reasonable if a month had actually passed since JDK 1.5 was released. It hadn’t. In fact, it was less than 72 hours afterwards (some of which was the weekend). From statements by some of Apple’s Java engineers on the Apple Java-Dev list, you can’t even run Apple’s full suite of tests for their Java runtime in 72 hours because the stress testing involves running a Java process for insanely long periods of time. Sun in fact ran servers for 5 weeks prior to releasing their JVM:

The QA team runs some heavy-duty stress tests, where the “pass” criteria is that the systems stay up for a certain number of days. Well, at this point all those tests systems have been running for five weeks and they look like staying up until we decide to pull the power cord. — Graham Hamilton

So anyone complaining that Apple hasn’t released Java 1.5 prior to at least 5 weeks after Sun released theirs (ie: early November) is asking Apple to do less testing than Sun did. Personally, I’d prefer to get a stable JVM even a year later than to get a half-baked implementation now. Sure I’d prefer it if I could get a stable JVM before then (6 months is probably the best I’d expect), but if it took a year then so be it.

And now back to the main point: Cris Adamson’s comments. Chris provides a very informative table in his entry, here’s a slightly different way of looking at it:

Version	Released	Mac version	Lag	Excuse
1.0	Jan 1996	May 1996	4 months	Sun didn’t give a damn about supporting MacOS and produced a very poorly integrated JVM. 4 months however is a pretty good turn around time and this was mostly achieved by not taking advantage of or accomodating Mac specific features (like the screen menubar).
1.1	Feb 1997	Dec 1997	10 months	Development of the JVM changed organisations. Moving a product between organizations never helps the product schedule. 10 months is still okay though (within the 1 year I said I’d be happy with). Still no integration with the OS like screen menubars or a native look and feel (AWT used native widgets though I think).
1.2	Dec 1998	never	N/A	Wrote a new OS. This was down right annoying and if I’d had a blog then I would have been whinging about it. Apple didn’t put much effort into non-core technologies on OS 9 around this time anyway because they were focusing on getting OS X out the door so I don’t think I’d put this down to a lack of focus on Java - in fact it was in this time period that Apple actually made a big deal about the Java support OS X would have.
1.3	May 2000	March 2001	11 months	See above. With the delay of Mac OS X, could jump straight to 1.3.1. (Didn’t Mac OS X 10.0.0 ship with Java 1.3.0 though and not long after it was updated to 1.3.1?)
1.4	May 2001	March 2003	23 months	Discovered major design flaws in the JVM port as the AWT threading model just didn’t fit well with the Carbon thread model. Rewrote AWT to use Cocoa instead. This was annoying and the results were pretty poor as well (Java 1.4 on Mac is still much slower than Java 1.3 for GUI work).
Note that 1.0 and 1.1 were only available on Mac OS (System 7.5 - 9.2), while 1.3 and beyond were only on Mac OS X

So what I see from looking at the history is two things:

1. Sun didn’t take Java on Mac seriously. Looking at how often the Java APIs conflict with the way things are done on Mac OS says to me that people at Sun didn’t really consider the Mac when designing the APIs or at least did so very poorly. I’m not sure I’d like to see Sun writing the Mac JVM even if it did mean it came out at the same time as the Windows JVM unless Sun started to show more of an interest in working well on Mac OS (as an example of Sun not caring recently, try running the demo CD they gave out at Java One on a Mac: you can’t).
2. Apple don’t have enough resources in the Java team and they seem to be having a really hard time making Java run well on Mac - particularly in terms of the GUI (there have been two rewrites of the windowing code and a rewrite of the OS).

Chris also mentioned that the number of Java developers mightn’t justify Apple’s effort in Java. Glen Fisher (a regular on the Java-Dev list) has pointed out time and time again that if Java were a really important feature for getting users to OS X, it would be mentioned an awful lot more in at least WWDC keynotes if not MacWorld keynotes. The reality though is that it barely gets mentioned if at all in keynotes. Let’s be honest here, Java doesn’t justify people buying a particular OS - Java is designed to make the OS irrelevant. Frankly, I don’t care what OS I develop Java on - Eclipse, NetBeans and IDEA all run cross platform anyway. Maybe you bought a Mac just because of it’s Java support (silly you) and maybe even a thousand other developers you’ve heard from did. Who cares, there’s millions of Mac users out there and most of them have no idea what Java is let alone why they would want it.

Finally, Chris really hits gold when he talks about Windows Bigot Java Programmers:

The Windows Bigot Java Programmer seems like it should be a contradiction in terms - if you like Windows so much, why not program in Active X or .NET or whatever Redmond’s flavor of the month is - but in reality, I think this actually accounts for a massive percentage of Java programmers.

Absolutely. If you’re a long time Mac user who’s used to things being Mac-like and then try and run most Java applications you’ll realize just how bad Java programmers are at writing cross-platform code. Most of the time the code does run, but it’s very rare to find a program that looks and feels like a Mac program. It’s not the fault of the look and feel either, most Java programmers don’t even do simple things like make sure the OK and Cancel buttons are in the right order.

Even GUI guru Karsten Lentzsch falls into the trap of creating Windows looking GUIs, for example his log in screen example is a replica of the Windows login screen. Looks fantastic on Windows, okay on Linux - very out of place on Mac.

More commonly though, people fall into traps that don’t even require special coding, like using new BufferedImage(…); instead of createCompatibleImage(…) - using new BufferedImage makes an assumption that the type you pick will perform acceptably on all platforms, but depending on the windowing system it may actually perform very badly. createCompatibleImage on the other hand creates an image type that is guaranteed to be the best representation for the current platform.

So if you’re in a development team that’s madly rushing to find all the bugs in Java 5 as soon as possible by betting their project on it and thus you run the risk of not being able to use your Mac to develop, I pity you but I still don’t want to hear another whine about Apple not having released Java 1.5.

For those like me who are sick and tired of hearing the complaints, the news is all bad. Even if Apple ship Java 5 tomorrow, the complaints will just move on to the next thing that developers just absolutely have to have and can’t live without (despite the fact that they have done so for ages) but before that you’ll have to put up with the barrage of complaints about all the bugs in Apple’s Java 5 implementation first. Oh and if for any reason people run out of things to complain about, they’ll start up the complaints about the Java-Dev list archives again or maybe the fact that Apple doesn’t publicly list reported bugs…

Of course, people like me won’t be whinging about any of that, we’ll be whinging about all the whinging that’s going on.