Wed 5 Feb 2014
When Sun’s (now Oracle’s) Java implementation was released as Free Software in 2006/7, starting the OpenJDK project, it already had over ten years of proprietary software development behind it. As a result, its codebase and build system are littered with assumptions and defaults designed for producing a binary blob that works on as many systems as possible. This is a very different design impetus from that of software which is developed in the open from the start, and the IcedTea project started as a way to adapt OpenJDK to this new world, and this remains one of its roles today.
Oracle still don’t provide binaries built solely from the OpenJDK codebase. Instead, their builds are based on a combination of the OpenJDK trees and their own internal proprietary trees. These have the same requirements as before, in depending on as little as possible being present on the target system. To achieve this on a GNU/Linux system, the C++ library is incorporated into the JDK binaries rather than being linked against, and the source trees include their own copies of the compression library, zlib, and imaging libraries (libjpeg, giflib, libpng, LCMS) which are then built as part of the JDK. This means that the binary will work on the target system without these libraries being present or in the required versions. For things that aren’t essential to the JDK, but provide optional extra features, the JDK will try to open the library at runtime and fail (usually silently) if it can’t be found. Examples of this include the Gtk+ look and feel and various system calls for the new NIO2 libraries in 1.7.
Such binary packages are the norm on Windows, Mac and mobile platforms, as is bringing everything you need with you. However, traditionally, GNU/Linux systems have a notion of distributions, which exist between the individual packages and the end user. You can think of choosing a GNU/Linux distribution as analogous to choosing which store you buy your groceries from. The same staples of the Linux kernel and a C library are provided by all distributions, in the same way all grocery stores stock bread and milk, but they distinguish themselves by how they package their products, what branding they apply and, as you reach more optional components, what software is included. Distributions like Fedora and Gentoo try to bring new versions of packages to their users as soon as possible, whereas others like Debian and Red Hat Enterprise Linux (RHEL) cater to those who want a more stable environment.
Access to these packages is through the package manager, which far predates the store concept that is coming of age on Windows, Mac and mobile platforms, and differs from these in that the software is usually available gratis. In including a package like OpenJDK in the package manager, distributions have very different aims to those described above. Critically, they know what packages are available and in what versions (i.e. the others provided by the package manager), so there is no need for the OpenJDK package to bundle its own copies. In fact, doing so creates problems as it increases the footprint of OpenJDK and, most importantly, prevents it from picking up on security updates made to the system copies of these libraries. For this reason, it is against the rules of a number of distributions to perform such bundling.
Since its inception, IcedTea has fixed the most problematic issues by building against the system C++, compression and imaging libraries. More recently, the IcedTea build even deletes the in-tree copies of these libraries to ensure the system version is being used. Thus, if a library like libjpeg is patched due to a security issue, the OpenJDK package will immediately benefit without having to be patched and re-built itself. With IcedTea 2.x, we went further and addressed the optional cases, where the JDK probes for libraries at runtime. In the IcedTea 2.x forests, support is provided to instead compile against these libraries. This ensures both that the code still works against the system installation of the library, and introduces a link between the JDK library and the system library which automated dependency tools can then detect.
Just this week, we’ve introduced support for compile-time building with the libpcsclite library. While this is primarily for testing (as the library needs to be interchangeable at run-time), it does mean that some basic checking of this code can be done by the compiler in development builds.
The result of all this is that someone new to IcedTea may think that it has many more dependencies than OpenJDK. However, most of these dependencies are taken from the OpenJDK codebase and are just not explicit when building it independently. Although this means it’s slightly harder to complete an IcedTea build, by the time you’ve done so, you know that all the libraries the JDK may need are present and have been compiled against, which gives a greater guarantee of runtime success than if, for example, you wait until someone fires up a graphical application using the Gtk+ look and feel and it fails. With the latest 1.13.0 release, all these options are now configurable on both 6 & 7, so you are free to make your own choices as to whether to go with a bundled or linked solution on a per-library basis.