Skip to main content

Building the JDK 6.0 on Windows XP

Posted by kellyohair on October 12, 2005 at 1:14 PM PDT

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, 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?

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
  • 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.

Related Topics >>