Living on the Java edge on Mac OS X
In this short note, we will see how to build Mac OS X packages of OpenJDK in a convenient fashion.
While we will focus solely on OpenJDK 7, this applies to the various builds for OpenJDK 8 with Jigsaw, lambda support and so on.
…but why?
Sure, if all you need is a runtime or development kit for Java SE 7, then you may simply go to the Oracle website and download it.
That being said there is a project called OpenJDK that is released under an opensource license. It is perfect for development and experimental usage. There are many benefits in doing so:
- you get the latest performance updates, which is critical for some us (language developers, middleware implementers, academics, …),
- you can enable advanced diagnosis such as printing out the JIT assembly code and advanced GC metrics,
- you can preview
Java.next(.next)before everyone else, - you don’t have to wait on long official release cycles,
- there are people stuck on earlier Mac OS X versions, possibly needing 32 bits JVMs.
- …because you can is a good excuse, too.
In my very own case, I need the latest improvements on the invokedynamic support, and waiting for the official updates is simply not an option. To be honest I don’t have any Oracle JDK on my Mac OS X machines: OpenJDK builds simply do the job.
Introducing obuildfactory
One clear option would be to fetch the source code from the OpenJDK Mecurial repositories, then go ahead and build. You would get a functional build, but there is a better way through the obuildfactory project initiated by Henri Gomez.
Indeed, it produces ready-to-go DMG archives: you get to install your OpenJDK build by a simple drag and drop. You can pass it to your friends and coworkers. Last but not least: the builds that the obuildfactory scripts produce adhere to the framework layout expected for regular JDKs. Tools such as IDEs will love it, and system tools like /usr/libexec/java_home will properly identify it as a JDK.
Let’s build it
Obviously, you can follow Henri’s instructions, but there are a few corner cases that I ran into.
For the record, I am running Mountain Lion.
Start by creating a folder somewhere, then clone the repository:
cd Code
mkdir obuildfactory
cd obuildfactory
git clone git://github.com/hgomez/obuildfactory.git
Next, make sure that you will be using the system-default Ruby environment, not a third-party Ruby 1.9.
I am using the awesome rbenv to manage my Ruby installations, so while in the work folder ensure that you will use the system one:
rbenv local system
You now need to have XQuartz installed and running for Freetype and X11 headers. Starting with Mountain Lion, Apple does not ship X11 anymore, so you will have to download it. Sadly, their installer breaks the paths conventions that the build expects, so you will need to create a symbolic link as follows:
sudo ln -s /usr/X11/include/X11 /usr/include/X11
From there you should be ready to go and build:
XBUILD=true XPACKAGE=true ./obuildfactory/openjdk7/macosx/standalone-job.sh
Wait for the job to complete and your freshly baked packages are in OBF_DROP_DIR/openjdk7.
Warning: the build has issues with the X11 / Freetype dependency. If you need to give the build to somebody else then check Henri’s instructions for embedding it, or wait until someone understands that his proposed patch was actually useful to the wider OpenJDK community.
fastdebug variants
Weird people interested in the low-level JIT and GC diagnosis will want a fastdebug build so that flags such as -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly become available.
All you have to do is pass SKIP_FASTDEBUG_BUILD=false to the build:
XBUILD=true XPACKAGE=true SKIP_FASTDEBUG_BUILD=false obuildfactory/openjdk7/macosx/standalone-job.sh
It is possible that by the time you will be reading this, a new XDEBUG flag will have been added.
System integration
It is easy to check that the system integration works. If you have installed custom OpenJDK builds, you can conveniently list them as part of the system-wide JDKs and grab their home folders:
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (6):
1.6.0_35-b10-428, x86_64: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.6.0_35-b10-428, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.7.0-u10-b09-20121026, x86_64: "OpenJDK 7" /Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home
1.7.0-u10-b06-20120911, x86_64: "OpenJDK 7" /Library/Java/JavaVirtualMachines/1.7.0u-fastdebug.jdk/Contents/Home
1.7.0-b24-20120813, x86_64: "OpenJDK 7" /Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home
1.7.0-b24-20120813, i386: "OpenJDK 7" /Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home
$ /usr/libexec/java_home -v 1.7
/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home
Henri wrote an insightful blog post about the topic.
Conclusion
Thanks to Henri’s phenomenal work, it is possible to live on the edge of Java on Mac OS X by building custom OpenJDK builds for yourself. You don’t need to wait on slow release cycles, and it provides a first-class system integration. You may also have a need for a fastdebug build, too.
One could argue that what you get here is not “an officially / certified supported JDK”. This is true, but we are not talking about putting those VMs on mission-critical production servers. Developers know how to live on the edge, and this is just a natural consequence of pushing some bits under an opensource license.
— Julien Ponge, 26 Oct 2012