Monday Jan 07, 2008

Building and Porting the OpenJDK: A Shopping Cart

What is the difference between Building the OpenJDK and Porting it? Certainly porting requires you to build it, but porting can mean much more, and with different levels of porting effort. A different operating system or hardware architecture is certainly a major porting effort. But a different C++ compiler could also be a porting effort, probably to a lesser degree, but don't underestimate it.

The number of OS/Arch/C++ combinations out there is pretty large. Even if you picked Linux/X86/g++, it doesn't mean much, certainly this would either build and work, or build and work after some small degree of porting effort. If the g++ compiler was significantly older or newer or different from what has been successfully used before, then there is a small chance you will encounter some porting effort. If the version of Linux you are using is very old, or newer, you also run the risk of adding some small porting effort. As to whether the changes made to the OpenJDK to make it work should be made permanent, it depends on the changes. Sometimes the porting effort can be a bit like the Whac a mole game, you whack a fix to one OS/Arch/C++ combination and a different broken combination pops up. :\^(

Now I'm not suggesting that every Build of the OpenJDK is a "port", but in a minor way, it is a bit of a port if the specific combination has never been tried before. If you suspect you might be doing a bit of a port and having problems, I'd recommend a little divide and conquer approach to it. Maybe get langtools to build first, then hotspot, then maybe corba, jaxp, and jaxws. Leaving the jdk for last, but the order may depend on what kind of port you are doing.

So here is my Shopping Cart:

  • A C and C++ compiler, plus all the trappings that go with it, like /usr/include files and /usr/lib libraries to support building C++ applications. The risk of problems here includes the same ones any C/C++ project might face, but we have a few extra problems that crop up from time to time.
    • Anything other than the specific compiler versions listed in the OpenJDK Build README runs some risk of not working perfectly. In practice, even when problems arise in this area, the effort level is low to correct it, and the frequency of these problems has gone down over the years. However, a big warning here, the Hotspot VM is built with high C++ optimization levels, and it's not unusual for compiler or VM bugs to manifest themselves when the C++ and Hotspot code mixes it up at runtime. It rarely happens with minor compiler revisions, but major compiler updates or new compilers do pose a risk due to the different compiler vendors approach to the various language and system standards. If you suspect some kind of compiler runtime problem is happening, you will need to selectively turn down the optimization on the suspect C++ sources files, or just turn down the optimization level completely. Keep in mind that the overall performance of your resulting JDK build could suffer by turning down this C++ optimization level.
    • The Hotspot VM is your major hurdle for the C++ compiler, a great deal of code needs to compile. The rest of the OpenJDK contains many C source files, but getting them to compile and work is considered minor compared to the Hotspot C++ source files. The non-Hotspot native code is more likely to encounter issues with the system /usr/include files or /usr/lib libraries.
    • If the hardware architecture isn't X86 or sparc, then you have some assembly code to write for Hotspot, and possibly a small amount for the java launcher code. I don't have details on this, but I think we will probably get these details from the OpenJDK Porters Group. You will definitely want to be connected with this group if you are doing any porting work.
    • If the OS isn't Solaris, Linux, or Windows, you will encounter more problems I'm sure. The differences in the /usr/include files can pose some problems, but if any amount of native C/C++ code has been ported to this OS, the problems should be well known. The C/C++ code in the OpenJDK should follow the C/C++ language standards, however with any project this size, it would be hard to guarantee that 100% of the language/system "undefined behaviors" have been avoided.
  • A boot JDK (at least JDK 1.5) to run javac/javah/javadoc (from langtools) that builds the OpenJDK class files. The boot JDK also provides the jar utility. It's possible that a JDK 6 is required to build either jaxp or jaxws areas of the OpenJDK, but the dependencies are on class files added to JDK 6, some investigation into this needs to be done. Ideally we would like to allow for just a JDK 1.5 boot.
  • The binary plugs (which will go away someday).
  • Other Bits and Pieces: Also needed are the CUPS include files, the X11 include files and ALSA sound files, Windows users also need the Platform SDK and DirectX 9 SDK. All of these are somewhat like the C++ compiler, and are installed once on your system.

I hope this helps in some way.

As Landon Fuller is finding out with his little porting adventure, some platforms are easier than others.



Various blogs on JDK development procedures, including building, build infrastructure, testing, and source maintenance.


« April 2014