It's customary to give the option.
Real questions, not rhetorical!
If I look at http://www.chromium.org/getting-involved/dev-channel , they list a Windows 32-bit channel and separate 64-bit channel, but only one Mac channel. I'm not sure if this means anything about their release intentions, or if the page may still be updated.
Oddly enough, chrome didn't want to auto-update to this, it was "up-to-date" at 38.x, even quitting and relaunching applied no change. Downloading a fresh `dmg` archive from https://www.google.com/chrome/browser/ applied the 64-bit update.
(Chrome startup is so slow on my machine that this might be negligible anyway).
https://www.java.com/en/download/faq/chrome.xml
For those of us that still need to access legacy systems (routers, switches, etc.) that have Java interfaces, this is a pretty major upgrade.
(FWIW, Firefox has been 64-bit on OS X and Linux since 4.0, but we're still working on Win64 support. Of course, Microsoft kicked everyone's ass when they released Windows XP Professional x64 Edition in 2005, which included a 64-bit version of IE6.)
The problem is that, while the Unix-based world went the LP64 way (int is 32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to behave as if "long" was the largest native type ("long long" on 32-bit uses a pair of registers). They have to scrub their whole code base for things like assuming an object's size or array index will always fit on a "long".
For software originally developed for Windows, LLP64 was supposed to make porting easier, since unlike on the Unix world (where "long" could be 32-bit or 64-bit), a lot of Windows programs assumed a LONG was always 32-bit, and that assumption was baked into file formats and IPC protocols.
Newly developed software has it easier; programmers nowadays keep in mind that there are relevant systems where sizeof(long) < sizeof(size_t), and since the C99 standard they have the stdint.h types to help (even on Windows with its pre-C99 compilers, since it's easy to find a working stdint.h for them).
----
As for Mac OS X, the porting problem is Carbon. If the code base is old enough, it'll be using Carbon, which AFAIK is not available for 64-bit.
http://javatester.org/version.html Gives an error - Java needs your permission to run, but I've already allowed in Java control panel. Ideas?
Failing that, go to java.com and see what their check says.
#73 mark@chromium.org
This was released to the stable channel today in version 39.0.2171.65.
Thanks for your patience, everyone.
Status: Fixed5 years and 3 months after the issue was opened...
64-bit was important on Linux because the system libraries that Chrome uses were increasingly unavailable in 32-bit versions on 64-bit systems.
On other platforms, while there are advantages to 64-bit binaries, those advantages haven't outweighed the other useful things you could be spending engineering time on.
damurdock$ file /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O executable i386
damurdock$ file /Volumes/Google\ Chrome/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
/Volumes/Google Chrome/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O 64-bit executable x86_64