The duck and the frog are reborn

The saga began the day I decided to ignore everyone’s advice (what’s new with that?) and attempted to install Java 1.5 on my Powerbook, which, of course, is still running Mac OS X Panther 10.3.9. I don’t do any Java development, but an increasing number of applications that I wanted to run ((Oracle SQL Developer and the latest version of Aqua Data Studio)) were Java 1.5 only, so I was faced with two options – upgrade to Tiger or attempt what I did.

I downloaded the J2SE 5.0 package from Apple’s site and thanks to Pacifist and the helpful forums out there ((I am intentionally not linking to the posts because I do not recommend anyone else do the same – if you are really determined, search for it and you’ll find the instructions)) I had 1.5 up and running in no time at all. All was well v1.0 – or so it seemed.

While Java applets (those nifty little applications that run inside a broswer like the stock ticker at the NSE site) were running fine, the ones that I was really looking forward to refused to run. Turns out there’s a reason why Apple says “No Java 1.5 for you, Panther” and the reason is that the Swing (you know the oh-so-resource-hungry Java UI) implementation of Java 1.5 on the Mac is closely tied to Tiger. That, in an attempt (I guess) towards making the Java apps look and feel more like their non-Java counterparts on the Mac platform instead of aliens from outer space that some of them do.

So that left me with a broken Java implementation. Running Java 1.4.2 installer wasn’t an option, because it wouldn’t allow me a “downgrade”. While I had kept backups of all files/ folders that the Java 1.5 installer had replaced (thanks, again, to Pacifist which allowed me to see where everything in the package would go) I just didn’t feel like going back to each of those folders and manually replacing the files! Yeah, that’s me. I thought I would play around a bit.

So I simply changed the “CurrentJDK” link in /System/Library/Frameworks/JavaVM.framework/Versions folder point back to “1.4.2” instead of “1.5”. And viola! All was well v2.0 – or so it seemed.

Java applets were fine and I could run the “old” version of Aqua Data Studio again, so I went to sleep a happy man, thinking I had saved myself a lot of unnecessary effort, albeith not entirely convinced.

Cut to a few days later, when I tried to run Cyberduck, the freeware FTP client. It refused to startup – bouncing in the dock a couple of times and then going back to sleep, finding enough time to write a crash report in the meanwhile. I was running a beta version at that time, so didn’t think much of it and used the good old “ftp” command instead. A couple of days later, I went back to Cyberduck by instinct and it did the same thing. This time I decided to take some time out and investigate. I started off by downloading the latest stable version from their site, but no cigar. I did the usual stuff like clearing out the preferences file and stuff, but still nothing. This is what the crash report had to say:

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffeff00

Hmm… searched the Cyberduck forums for that error and nothing much came out of it, except someone who suggested that our old friend Java might be an issue especially if typing “java -version” at Terminal gave you a “Segmentation Fault”. Sadly, that wasn’t the case for me, so this wasn’t my problem, but it did enough to convince me that the nifty Java downgrade that I attempted didn’t quite leave things in order.

But I needed further proof. So I tried running Azureus, the Java-based cross-platform, torrent client, and sure enough, it crashed as well with the exact same symptoms.

In my infinite wisdom, I had deleted the backup files I mentioned above so if I wanted a working Java install again it seemed I had no option but to reinstall the OS (*cue horror music*). Needless to say, hat is something I wasn’t exactly looking forward to. I tried all kinds of Java installers from Apple’s site but all of them refused to run saying I “didn’t have the version required for this installer” or something along those lines.

Now that can be easily solved by going into the Package and modifying the Perl script to bypass the checks and that’s what I did. I got the 1.4.2 installer to successfully run on my machine but when I dropped into Terminal to check if all was well, this is what I saw:

kdmac:~ $ java -version
HotSpot not at correct virtual address. Sharing disabled.
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-233)
Java HotSpot(TM) Client VM (build 1.4.2-56, mixed mode)

Clearly, the installer didn’t/ couldn’t replace some 1.5 files. I needed a way to “force reinstall” of all Java 1.4.2 files on my system. I finally found a technique which I got to work with some modifications.

All was well again in the Java land and the duck and the frog lived to see another day!

Note: Some of you may notice the futile nature of the entire exercise i.e. how I broke things and then fixed them up to come back where I started and actually feel happy about it. You, of course, are not nerdy enough.