Kelly O'Hair's Blog: October 2005 Archive

In my blog at blogs.sun I talked about building the JDK 6.0 but I must confess, most of the effort is in just getting your machine setup, that alone should put you up for a JDK medal of honor. Once a Windows XP machine has the C++ compiler installed and cygwin installed, the rest is fairly easy. Of course that's easy for me to say, I've built it so many times I think I might be going build blind. :^)

First off I would like to thank all the people that have posted forum topics on the build issues, and/or sent me email on some of the problems. If I have missed your posting, please comment on this blog or put a reply on the forum posting asking 'What's up with this?'. I do what I can, but I am only human, or so I'm told. ;^)

Over the past many months we have been trying to simplify both the machine setup and the build procedures, especially on Windows, and we have met with some success. There are limitations in what we can do in terms of re-distribution of some components, but we are investigating all avenues. Expect some updates to the build documentation in the next few months as we gear down on actual makefile changes and concentrate on improving the build documentation. If you have suggestions on improving these documents, please let us know.

Here are the basic Windows build machine requirements we currently have, with some additional words on what is happening in that area:

Visual Studio .NET 2003 Professional (C++ compiler and various components)
- We are trying to make it possible and easier for someone to use a different C++ compiler (which should be considered a significant task by the way, do NOT underestimate this) but we have not finished this setup, there is more work to do in this area. Several people have asked about using different compilers, but I don't know of anyone that has successfully used a different compiler to completely build the JDK, if you have, please let us know. Eventually, the idea would be to create a j2se/make/common/shared/Compiler-XXX.gmk file for every possible compiler that could build the JDK, or at least allow for it. The file j2se/make/common/shared/Compiler.gmk would then control what is the default compiler we expect, and again, this isn't completely setup yet, be kind. Keep in mind we (Sun) cannot possible guarantee every compiler setup this way will be able to build and work all the time, that would be pretty impossible for us to do, we would need your help. As to what default compiler we choose, that's a performance, quality of code, and availability issue that would be decided after some pretty long testing and measurement investigations. Don't expect any major changes on this front.
- Money, is one word that many people have pointed out is a problem with this C++ compiler issue, 'Why do they have to BUY a compiler'? Or another question is 'Why do I need a C++ compiler at all?', which is a perfectly understandable question. I have been experimenting with a way to build the JDK without having a C++ compiler, the basic idea was to be able to do something like: make IMPORT_NATIVE_BINARIES=true when building, and all the DLL or .so shared libraries would be copied in from a pre-built JDK 6.0 (of the same vintage, e.g. same build number) designated with ALT_JDK_IMPORT_PATH. Currently this is commonly done with the Hotspot VM files JVM.DLL or libjvm.so, when building the JDK, avoiding the building the VM's. This idea just takes it a step further and tries to apply it to all the native libraries. This feature isn't working quite yet, and it won't help anyone changing native code or native interfaces, so it will have limitations as to what you could change in the JDK.
DirectX SDK Version 9
- We really haven't a choice on this one, you must get it from the Microsoft Site and follow the install instructions.
MSLU (UNICOWS.dll) is needed, but not used on Windows XP.
- This is needed to create 32bit builds for older Windows machines, but really isn't necessary when building on Windows XP for Windows XP and newer, so we may try and relax this requirement when it is obvious that your build isn't targeted at Windows 98/2000, which as I understand it is the only place that requires this library. Since we have some code that actually makes calls to the functions in this library, this is probably more than simple makefile work to limit this dependency.
- We are restricted from re-distributing this UNICOWS.DLL except in our binary downloads, but that brings up an interesting point. The JDK 5.0 download does include this file, and an alternative to downloading this file from the website would be to just use the one in the JDK 5.0 tree. Unfortunately, it's a slightly older version, but seems to be sufficient in many cases, especially on Windows XP which doesn't need it anyway. Better is just downloading the pre-built JDK 6.0 that matches the sources you are trying to build, it has the UNICOWS.DLL you need. This goes along with the ALT_JDK_IMPORT_PATH discussion above, maybe IMPORT_NATIVE_BINARIES=true should trigger this file coming from ALT_JDK_IMPORT_PATH area and then the MSLU download isn't necessary.
CYGWIN or Unix utilities are needed (MKS can be used but is no longer required).
- A current problem right now is knowing what parts of CYGWIN are needed. We need cpio, zip, unzip, make, etc, but trying to figure this out during the cygwin install is difficult. I've just been lazy and installed everything, but this takes a very long time. We will try and provide better documentation on this. On our list of potential simplifications on the build machine setup is investigating creating a bundle of the necessary cygwin packages for re-distribution so that these steps could be easier. But it would need to be a separate download bundle to make sure we follow all the cygwin requirements on re-distribution. If you think this is a good idea, please let us know, or if you think it's a waste of time, please make your voice heard. This is probably one of the lower priority build issues for us, part of me says that just referring to the CYGWIN site is fine.
JDK 5.0 is needed to build JDK 6.0.
- This is called the BOOTDIR JDK, and actually, the latest pre-built JDK 6.0 could be used as the BOOTDIR. It's not a standard practice, but will work, if it didn't we'd have a P1 bug against JDK 6.0 real quick. ;^) So this download could be optional ALT_BOOTDIR and ALT_JDK_IMPORT_PATH could point at the same JDK 6.0 build.

So what about simplification of the actual build? Well last time I tried I needed to:

Download the pre-built JDK 6.0 and install it.
Download the Mozilla Headers File bundle and un-jar it.
Download the two JDK 6.0 source bundles and un-jar them into the same directory.
Make sure it's all positioned properly or the ALT variables are set.
- We have been trying to minimize the number of ALT variables that need to be set. Currently the makefiles should be able to find many components automatically, e.g. the compilers, Direct X 9, CYGWIN, and even the formally installed JDK's should be found automatically now. Since my original blog, we have tried to remove the need to set ALT_BOOTDIR and ALT_DEVTOOLS_DIR when CYGWIN is used.
Use: cd control/make && make dev-sanity
to verify everything is ok (extra points if you get it right the first time),
And: cd control/make && make dev
- Or perhaps someday you can skip the C++ compiler install completely and just make IMPORT_NATIVE_BINARIES=true .

Once a JDK has been completely built, depending on the area you may be concentrating on, there are shortcuts and alternatives to the makefiles when incrementally re-building portions of the workspace. I'll try and blog on that in the future.

A short note on dependencies and major build re-structuring. Several people have suggested complete re-writes of the makefiles, or conversion to other build tools. I don't really expect this to happen, the many dependencies on the installed components and the cross dependencies of all the makefiles upon each other make this extremely risky and labor intensive. These JDK makefiles are unique, as is the build process necessary to create the JDK. The mixture of the native code, the Java code, the Java compiler bootstrap, the builds of the JNI libraries, and the creation of all the different install bundles for all the flavors of Windows, Solaris, and Linux, just make this an extremely unique build process. We have and will continue to improve the existing system, and perhaps evolve portions of the build to enable other ways to build the JDK, but don't expect a wholesale re-write. This will be an evolutionary process, not a revolutionary one. Just making sure people's expectations are set appropriately.

Hopefully you have found this informative, and once again, please let us know what problems you are having with the builds.

Powered by
Movable Type 3.01D

java.net RSS Feeds