10.6: Re-enable Java 1.4.2 and Java 1.5 apps in Snow Leopard

Many applications that relied on Java 1.4.2 and Java 1.5 stopped working in Snow Leopard, because Apple removed these Java versions from the system. Upgrading to the lastest versions of many applications usually will solve the problem. However, your favorite application may not have a Snow Leopard compatible upgrade. For these applications, re-installing Java 1.4.2 and/or Java 1.5 is necessary. Sometimes, even this is not enough. As an example, Apple also removed the Cocoa-Java bridge from Snow Leopard, which some Java applications such as PDFLab depended on. Reinstalling the Cocoa-Java bridge along with the proper version of Java is necessary to re-enable these applications on Snow Leopard. For example, getting PDFLab working again in Snow Leopard requires reinstalling Java 1.4.2 and the Cocoa-Java bridge. Read on for a how-to...

Installing Java 1.4.2 and/or Java 1.5 on snow Leopard: 

The following is based on two blog posts: Using Java 1.5 and Java 1.4 on Snow Leopard and Installing Java 1.5 on Snow Leopard:

1. Download the official Java package from Apple: Java for Mac OS X 10.5 Update 4, dated June 15, 2009.
2. Use the excellent shareware utility Pacifist to open the downloaded JavaForMacOSX10.5Update4.pkg file.
3. First use Finder to go to System » Library » Frameworks » JavaVM.framework » Versions and delete the two aliases (symlinks) 1.5 and 1.5.0. Don’t skip this step, because otherwise the extraction will follow the symlinks and overwrite the contents of the 1.6.0 folder, oops!
4. In Pacifist, drill down into Contents » System » Library » Frameworks » JavaVM.framework » Versions.
5. In Pacifist, select 1.5 and 1.5.0, Control-click on the selection, and chose Install to Default Location from the pop-up menu.
6. In the instructions above, the same applies for version 1.4.2.

Installing the Cocoa-Java Bridge: 

This is based on Getting back the Cocoa-Java bridge in Snow Leopard: 

Copy from a working Leopard (10.5) installation the following folders:

1. the com directory in /System/Library/Java
2. the eight files ending with .dylib in /usr/lib/java (four of these are regular files, the other four are symlinks; if you prefer, you can copy just the files and recreate the symlinks by hand).

Mutable Vs. Immutable

Well, there are a couple aspects to this. Number one, mutable objects without reference-identity can cause bugs at odd times. For example, consider a Person bean with an value-based equals method:

Map map = ...
Person p = new Person();
map.put(p, "Hey, there!");

p.setName("Daniel");
map.get(p);       // => null

The Person instance gets "lost" in the map when used as a key because it's hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. Theorists like to harp on this point, but in practice I haven't found it to be too much of an issue.

Another aspect is the logical "reasonability" of your code. This is a hard term to define, encompassing everything from readability to flow. Generically, you should be able to look at a piece of code and easily understand what it does. But more important than that, you should be able to convince yourself that it does what it does correctly. When objects can change independently across different code "domains", it sometimes becomes difficult to keep track of what is where and why ("spooky action at a distance"). This is a more difficult concept to exemplify, but it's something that is often faced in larger, more complex architectures.

Finally, mutable objects are killer in concurrent situations. Whenever you access a mutable object from separate threads, you have to deal with locking. This reduces throughput and makes your codedramatically more difficult to maintain. A sufficiently complicated system blows this problem so far out of proportion that it becomes nearly impossible to maintain (even for concurrency experts).

Immutable objects (and more particularly, immutable collections) avoid all of these problems. Once you get your mind around how they work, your code will develop into something which is easier to read, easier to maintain and less likely to fail in odd and unpredictable ways. Immutable objects are even easier to test, due not only to their easy mockability, but also the code patterns they tend to enforce. In short, they're good practice all around!

With that said, I'm hardly a zealot in this matter. Some problems just don't model nicely when everything is immutable. But I do think that you should try to push as much of your code in that direction as possible, assuming of course that you're using a language which makes this a tenable opinion (C/C++ makes this very difficult, as does Java). In short: the advantages depend somewhat on your problem, but I would tend to prefer immutability.