Hadoop, Java7 and OSX or "what is it about JAVA_HOME"

The imminent End of Life for Java6 prompted me to move my OSX laptop up from Apple Java6 to Oracle Java7.

I've just conclude that this was a mistake and am trying to roll back.

Summary: because Oracle have managed to move things around in the way the build tools don't expect, you should stay on Java6



Key points

1. Apple will no longer support Java on OSX themselves; they are delegating this to Oracle.
2. Oracle stick things up in different place
3. Some of the JARs appear to have changed too
4. This breaks the classpath that Hadoop uses to generate its annotations
5. It also breaks the jspc compiler

Where things moved
Before: /System/Library/Frameworks/JavaVM.framework/Versions contained links to a JDKs found at /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents
After: /System/Library/Frameworks/JavaVM.framework/Versions doesn't get updated any more; things live in /Library/Java/JavaVirtualMachines/


Choosing which JDK/Java version to run

The Applications/Utilities/Java Preferences applet gets removed, and replaced by something in System Preferences -something that doesn't seem to pick up any of the existing JDKs, and so only gives you the option of choosing a java7+ version.

You can reinstall that applet, and so get hold of the full option set.

However, that doesn't seem to trickle down to /usr/libexec/java_home, which still defaults to 1.7 (at least for me)

Fixing JSPC

see HADOOP-9350 for a workaround

Fixing Hadoop-annotations to compile

There were lots of errors about com.sun.javadoc imports failing.

That's clearly a classpath problem.

At this point I gave up, fixing my .profile to pick up

export JAVA_HOME=`/usr/libexec/java_home  -v 1.6`

this sets it to
/Library/Java/JavaVirtualMachines/1.6/Contents/Home

This is close enough to a functional JDK6 that things would build and test again.

One of the recurrent pains of all Java based console apps is finding the JDK location. It's in some directory with spaces on Windows; in different places on Linux on ubuntu and RHEL, and now this: Oracle coming up with a layout on OSX that may make sense for them, but seems to break builds downstream.

It shouldn't have to be this complex. Every OS could have some standard locations where things end up -and these would be constant over time. It doesn't matter whether the old Apple layout here was wrong, and the new Oracle filesystem layout was "better", the issue we have here is that they are different, incompatible, and harder to switch between than you'd expect.

This leads to a followon problem: I'm not prepared to waste any more time upgrading to Java7 on my laptop for some months, even though it isn't getting security updates any more.

The changes to the Java installation on  OS/X provide a disincentive for Java developers to upgrade, which ensures that not only are those machines vulnerable security-wise (if they are naive enough not to disable the java plugin), but means that those developers aren't coding for Java7 -or even testing on it.

Macs may be minuscule compared to the Windows enterprise development world, never a place that server-side code runs, but are now a significant fraction of the Open Source developer community -at any of the ApacheCon events, Windows laptops are in the minority, this in a place where a Linux laptop doesn't raise an eyebrow.

By doing things that seem designed to make developing Java7 code on Macs near-impossible, the conclusion is that either Oracle don't want people to code on Macs, or they don't want Java7 code. Well, that's what they are going to get -at least from me.

[Photo: Anonymous, Easton]