Apple just killed their implementation of Java on the Mac – which just happens to be the only really usable implementation of Java on the Mac. There’s no other way to say it: Java developers on the Mac have relied on Apple’s implementation, and that implementation is not moving forward with Mac OS, period. I’m going to say what I think here, because it seems the message is important, and usually when I say what I think, if people feel what I think is wrong or incomplete, they tell me, and I learn something. (It’s the beauty of the Internet, or of conversation.)
This matters to digital artists, too, because we need tools we can share, tools to teach, tools that are expressive, and tools that give us the freedom to work on the variety of devices in the world. When the tech world shifts, we need to adapt to keep our medium vibrant.
Updated: A conversation guide for your Java-hating friends.
Friend: “Ha! Java? Who uses Java. It’s an inferior user experience. I only ever use native Mac ap–”
You: “It’s what Minecraft runs on.”
Friend: “Nooooooooooooooooooooo….”
Fortunately, there is an alternative — and it just got a lot more critical.
“That Java was our only hope.”
“No. There is another.”
This is significant news for people using Java. There are actually a number of great projects out there, but of course on this site I’m naturally thinking about Processing.
If you think I’m going to launch into an anti-Apple rant here, you’re very, very wrong. Apple maintaining a separate implementation of Java hasn’t made sense in years. (Note, too, that since Sun – now Oracle – licenses Java technology to Apple, it’s possible there was a breakdown in the relationship with Oracle. There’s no way to say for sure.) The only real question is, what will replace it?
Here’s what Apple says:
Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes
As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.
Apple is, however, obviously assuming a third-party Java implementation will take the place of their own. Look at the passage just below the deprecation announcement, and you’ll see that Apple has even reorganized a little spot for third-party implementations to go. (It’s not entirely dissimilar from the way Linux distributions handle multiple JVMs.) From the same document:
The location of the Java SE 6 runtime home has changed to /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home. JDK bundles provided via the Developer package, developer previews, and 3rd party JVMs should be installed in /Library/Java/JavaVirtualMachines or ~/Library/Java/JavaVirtualMachines. Developer previews of Java can now be installed and uninstalled without affecting the system JVM(s).
So, what happens next?
Oracle does a Java implementation for Apple. Next, Larry Ellison personally announces he’s calling off the Google lawsuit, releasing all Java intellectual property as patent-free and free and open source, dropping all Oracle database development to focus on MySQL, and giving up sailing. He then extends silken, gossamer wings that sparkle in the sun, and flies to Mars, singing in a golden baritone the complete score to Brigadoon. No. Not going to happen. (Unless you think I’m just crazy, Oracle also had a big announcement talking about the roadmap for Java SE, and there was no mention of the Mac.)
Okay, other possibility:
OpenJDK is the future of Mac Java development. This is far, far more likely. Oracle is maintaining support for OpenJDK, with 2011 and 2012 OpenJDK releases coinciding with Oracle JDK 7 and JDK 8.
OpenJDK is the one and only future for open source Java, not least because IBM announced this month it’s giving up on a more fully-open Harmony implementation and working with Oracle. The problem remains that Oracle, like Sun, doesn’t allow free development of Java on mobile, choosing instead to protect a lucrative mobile licensing stream. (I’m wildly, wildly over-simplifying an ugly issue here, but if you want to know more, ask Google about the Android Java lawsuit.)
Not being able to do open source Java development on mobile is bad news, but at least OpenJDK is a rapidly-maturing Java that’s in near-lockstep with the standard Oracle JDK. That much is a good thing.
Projects like Processing, free and open source software that depend on deep integration with the JDK, should use OpenJDK. And that means Processing in particular will need help, help from people willing to research how to fix things that don’t work on OpenJDK but do work on the old Sun JDK. My own cursory tests reveal that the situation on OpenJDK isn’t so bad, and this is a doable task for someone who knows what they’re doing. (That may or may not be me personally, but I’m happy to help anyone interested and we can do some experiments.)
The bad news is, when I last looked at OpenJDK’s Mac port (aka the “BSD” port), it was in shabby shape. It’s going to need some love if Java is going to survive on the platform. And that work will have to happen to OpenJDK first.
Of course, if Java developers wanted motivation, I think you just got it.
Developers consider platforms other than Java. Well, duh. Java — even open source Java — is far from doomed. Oracle, IBM, and Google each have a deep investment in it, and thanks to the forward progress on OpenJDK, on desktop, at least, you can expect Java to continue to thrive. But you never want as your only option a platform controlled by one vendor. And that means things like Python will be really important. I also expect some developers will choose to do with JavaScript what they might once have done with Java, even though these languages – despite four letters in their name – are very different.
In fact, again, Processing is a perfect example. By designing a consistent API, you can do the same things with Processing on JavaScript, Java, and Android using similar, elegant code, even as these platforms are complex and varied behind the scenes.
Consistent APIs, readable code, standards like OpenGL, portable native code, and code that interoperates well with humans are the real future of creative development. They endure no matter what crazy political antics break out between giant tech companies. In other words, the best platform out there remains your brain. Use it, and things will go well. Don’t, and be afraid.
Photo (CC-BY) Jun Ohwada.
Updated: Jobs speaks.
Missing from that explanation: the fact that Apple originally took it upon themselves to ship their own Java, that Apple’s Java relies on integration with the OS to behave in a native fashion, that while Apple’s releases have indeed been out of sync with Sun’s in the past, the problem wasn’t “release schedules.” Java 10.5 Update 1, for instance, shipped Java 6 revision 5 support in May 2008. Java 6 was released by Sun in December 2006. Apple’s own Mac OS X Tiger shipped at the end of October 2007, delayed by the development of the iPhone. In other words, it wasn’t Sun’s release schedule that was late – it was Apple’s. And Apple’s Java implementation still lacks JavaSound fixes dating back to the 2002 release of Java.
As I said, I don’t even necessarily disagree with the decision, but the explanation is distorted, and there’s no replacement.