Actually Apple OS Java 1.5.x and 1.6.x is already a combined 32/64 bit install.
See :**External links are only visible to Support Staff** and "http://www.java.com/en/download/manual.jsp"
Snow Leopard defaults to 32 bit mode on start up.
You have to explicitly tell it to run in 64 bit mode either by holding down keys on startup ( "6" & "4" ??) or manually setting a preference.
Snow Leopard runs 32-bit system software and applications on 32-bit Intel machines, and 64-bit system software and 32-bit and 64-bit applications on 64-bit Intel machines.
The desktop version of Snow Leopard by default boots a 32-bit kernel for reasons of kext and driver compatibility, but all user space runs 64-bit. this has to be changed manually to boot to 64 bit. In doing so one may need to still run some items in 32 bit mode for some compatibility issues.
Mac OS X Server boots into a 64-bit kernel. Core 2 Duo is a 64-bit machine.
Try $ sysctl hw.cpu64bit_capable or sysctl hw.optional.x86_64 to verify that you have a 64-bit cpu. arch will always show i386 on Intel hardware in both Leopard and Snow Leopard.
The app I pointed out in an earlier post also helps determine wether one in Snow Leopard is actually booting or is switchable from 32 bit to 64 boot up mode without having to get into terminal. Note this app only runs in Snow Leopard and above.
That being said JD seems to run better in 32 bit versus 64 bit in OS X. There are still a few other apps also wether they be Java or not that still atm tend to run better in the 32 bit mode selectable by the get info and run in 32 bit mode selection.
Some apps also tend to run better in the Rosetta mode although they will run under Snow Leopard in native mode. Usually if an app is needed to be put into either the Rosetta or 32 bit run mode it is because the app or some underlying process has not been properly built to begin with to fully take on the full native mode environment.
Now as for the permissions noted regarding such as (was lrwxr-xr-x, should be -rw-r--r--) or (was lrwxr-xr-x, should be -rwxr-xr-?) the "l" is noting that this relationship is actually a symbolic link for pointing to the correct/current versions of components to run properly.
Files that aren't installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked for permissions.
For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn't created. This is expected. Some applications are designed to be installed in one of those ways.
Unless something has been installed to change some permissions that are different from the symbolic link (usually it is an install that is not set properly in the first place to change the dbase of installed permissions for the file when it is actually installed in the first place.
Also, certain files whose permissions can be changed during normal usage without affecting their function are intentionally not checked.
One can manually change such through terminal but it is recommended to not mess with something regarding permissions at the root level unless you really know what is what as if you allow or change the permissions incorrectly you could do one of two things.
1. You could break the true functionality and the effectiveness of the app calling such.
2. You could open the doors to an outside influence that could allow full root access leading to a possible trojan/virus or other attack.
Most of the times such permission errors can be ignored as pointed out here > "**External links are only visible to Support Staff** and you may wish to also review this article > "**External links are only visible to Support Staff**
I'm sure I'm forgetting something but getting tired and so will leave it here and quit writing a min novel.
Hopefully this will help clarify for some the issues they may be confused with.