Java

README: JDK Builds

JavaTM Platform, Standard Edition Development Kit (JDK)

v6u105 fcs

             

Introduction
This README file contains build instructions for the JavaTM Platform, Standard Edition Development Kit v6u105 (JDK 6u105) Community Source Release. Building the source code for the JDK requires a high level of technical expertise. Sun provides the source code primarily for technical experts who want to conduct research, port the platform to new operating systems and hardware, or add enhancements that require access to platform internals. If you are not a technical professional in one of these categories, this release is probably not for you.

Contents

Source Directory Structure
The source code for the JDK is delivered in N sibling directories, three primary ones are: hotspot, j2se and control. The hotspot directory contains the source code and make files for building the Java(tm) Hotspot Virtual Machine. The j2se directory contains the source code and make files for building the JDK runtime libraries, tools and demos. The control directory contains make files to build the complete JDK release including building the hotspot VM, staging the VM binaries, and building the JDK runtime libraries, tools and demos. Building using the control workspace is the recommended manner of building the JDK.

Building
Building the JDK is done with a GNU make command line and various environment or make variable settings that direct the make rules to where various components have been installed. Where possible the makefiles will attempt to located the various components in the default locations or any component specific variable settings. When the normal defaults fail or components cannot be found, the various ALT_* variables (alternates) can be used to help the makefiles locate components.

GNUmake
The Makefiles in the JDK are only valid when used with the GNU version of the utility command make (GNUmake). Information on GNU make, and access to ftp download sites, are available on the GNU make web site. The latest source to GNU make is available at http://ftp.gnu.org/pub/gnu/make/. A few notes about GNU make:

Windows System Setup

i586 only: The official 32-bit build platform for the JDK 6u105 is Windows Professional 2000 with Service Pack 4. The minimum recommended hardware for building Windows-i586 version is an Pentium class processor or better, at least 512 MB of RAM, and approximately 600 MB of free disk space. NOTE: The Windows 2000 build machines need to use the file system NTFS. Build machines formatted to FAT32 will not work because FAT32 doesn't support case-sensitivity in file names.

amd64 only: The official 64-bit (amd64) build platform for the amd64 Windows JDK 6u105 is Windows Server 2003 - Enterprise x64 Edition. The minimum recommended hardware for building the Windows-amd64 version is an AMD Opteron class processor, at least 1 GB of RAM, and approximately 10 GB of free disk space.

Windows Paths
Windows: Note that GNU make is a historic utility and is based very heavily on shell scripting, so it does not tolerate the Windows habit of having spaces in pathnames or the use of the \ characters in pathnames. Luckily on most Windows systems, you can use / instead of \, and there is always a 'short' pathname without spaces for any path that contains spaces. Unfortunately, this short pathname can be somewhat dynamic and the formula is difficult to explain. The MKS utility dosname has a -s option that will provide the translation for you. And CYGWIN has a cygpath -s -m utility that will do the same. So the JDK makefiles will try to translate any pathnames supplied to it into the MKS style or so called CYGWIN 'mixed' style of C:/no-spaces-path.

Note that use of CYGWIN creates a unique problem with regards to setting PATH. Normally on Windows and with MKS, the PATH variable contains directories separated with the ";" character (Solaris and Linux uses ":"). With CYGWIN, it uses ":", but that means that paths like "C:/path" cannot be placed in the CYGWIN version of PATH and instead CYGWIN uses something like /cygdrive/c/path which CYGWIN understands, but only CYGWIN understands. So be careful with paths on Windows.

Windows Check List
  1. Install or check OS version.
  2. Install MKS or CYGWIN. If MKS, you will need a GNU make, zip, and unzip.
  3. Install the Bootstrap JDK.
  4. Install Microsoft Visual Studio .NET 2003 and/or Microsoft Platform SDK.
  5. Setup all environment variables for compilers (see compilers).
  6. Install Microsoft DirectX SDK.
  7. i586 only:
    1. Install Microsoft Layer for Unicode (MSLU).
    2. plugin only: Get the Mozilla Headers.
    3. If creating install bundles, install Microsoft MsiVal2 Microsoft Msidb Microsoft Msicert Microsoft Msitran Microsoft Cabinet Software Development kit cabarc

Linux System Setup
i586 only: The official build platform for the JDK 6u105 is Redhat Enterprise Advanced Server 2.1 update 2. Formerly known as RedHat Advanced Server 2.1 update 2.

The minimum recommended hardware for building the Linux version is a Pentium class processor or better, at least 256 MB of RAM, and approximately 1.5 GB of free disk space.

amd64 only: The official build platform for the amd 64-bit version of JDK 6u105 is Suse 8 Enterprise Server - AMD64 Edition. The minimum recommended hardware for building the Linux-amd64 version is a AMD opteron class processor, at least 512 MB of RAM, and approximately 4 GB of free disk space.

The build uses the tools contained in /bin and /usr/bin of a standard installation of the Linux operating environment. You should ensure that these directories are on your PATH.

Note that some Linux systems have a habit of pre-populating your environment variables for you, for example JAVA_HOME might get pre-defined for you to refer to the JDK installed on your Linux system. You need to unset JAVA_HOME. It's a good idea to run env and verify the environment variables you are getting from the default system settings.

Linux Check List
  1. Install or check OS version.
  2. Install Bootstrap JDK.
  3. Install ALSA packages.
  4. Install CUPS files.
  5. i586 only:

Solaris System Setup
The official build platform for the 32-bit version of JDK 6u105 is Solaris 8.

The minimum recommended hardware for building the Solaris SPARC version is an UltraSPARC with 512 MB of RAM. For building the Solaris x86 version, a Pentium class processor or better and at least 128 MB of RAM are recommended. Approximately 1.4 GB of free disk space is needed for a 32-bit build.

sparcv9 only: The official build platform for the SPARC 64-bit version of JDK 6u105 is a 64-bit installation of Solaris 8 SPARC/SPARCV9.

amd64 only: The official build platform for the AMD64 64-bit version of JDK 6u105 is a 64-bit installation of Solaris 10 X86/AMD64.

You may run the command "isainfo -v" to verify that you have a 64-bit installation. An additional 7 GB of free disk space is needed for a 64-bit build.

The build uses the tools contained in /usr/ccs/bin and /usr/bin of a standard developer or full installation of the Solaris operating environment.

Minimum patch revisions are given in the tables below, though later patch revisions are expected to work also. Patches may be downloaded from the JDK download page. All the runtime patches should be installed to ensure proper behavior of all JDK functionality after the build is completed. You should ensure that the latest patch cluster for your version of the Solaris operating environment has been installed prior to installing these patches. The JDK patch clusters are available for download on the SunSolve web site.

The term "required" means the patch is required for non-international build.

#include /net/sca00egj.us.oracle.com/n/mustang/jdk6_105/licenseebundles/b06-2015-07-20/tmp/readme/solaris_os_patches.html

Solaris Check List
  1. Install or check OS version.
  2. Install Bootstrap JDK.
  3. Install Solaris system patches.
  4. Install Sun Studio 11 Compilers.
  5. Install Compiler Patches.
  6. Install DTrace Package.
  7. Install CUPS files.
  8. Install JDBC ODBC Files.
  9. plugin only: Get the Mozilla Headers.

Build Dependencies
Depending on the platform, the JDK build process has some basic dependencies on components not part of the JDK sources. Some of these are specific to a platform, some even specific to an architecture. Each dependency will have a set of ALT variables that can be set to tell the makefiles where to locate files. In most cases setting these ALT variables may not be necessary and the makefiles will find defaults on the system in standard install locations or through component specific variables.

Bootstrap JDK
All JDK builds require access to the previously released JDK 5.0, this is often called a bootstrap JDK. The JDK 5.0 binaries can be downloaded from Sun's JDK 5.0 download site. For build performance reasons is very important that this JDK be made available on the local disk of the machine doing the build. You should always set ALT_BOOTDIR to point to the location of the bootstrap JDK installation, this is the directory pathname that contains a bin, lib, and include It's also a good idea to also place its bin directory in the PATH environment variable, although it's not required.

Note that the Bootstrap JDK can be a newer JDK, and in fact you could make the Bootstrap JDK and the Import JDK (described below) the same. There is some risk in this approach if the Bootstrap JDK you choose happens to be unstable.

Import JDK
When building just portions of the JDK, you will need what is called an import JDK. If you plan on building the entire JDK, this JDK installation isn't necessary. This should be the same JDK version (JDK 6u105) as the source you are building, and ideally a very recent build, one that matches fairly well the sources you are building. Download the JDK Binary snapshot from http://www.java.net/download/jdk6 install the JDK and make sure you set ALT_JDK_IMPORT_PATH.

Note that the Import JDK can also be a source of some of the dependencies described in this section, for example, some of the Windows DLL files like UNICOWS.DLL and MSVCRT.DLL.

Certificate Authority File (cacert)
See http://en.wikipedia.org/wiki/CAcert for a better understanding of the Certificate Authority (CA). A certificates file named "cacerts" represents a system-wide keystore with CA certificates. In JDK and JRE binary bundles, the "cacerts" file contains root CA certificates from several public CAs (e.g., VeriSign, Thawte, and Baltimore). The source bundles contain a cacerts file without CA root certificates. Formal JDK builders will need to secure permission from each public CA and include the certificates into their own custom cacerts file. Failure to provide a populated cacerts file will result in verification errors of a certificate chain during runtime. The variable ALT_CACERTS_FILE can be used to override the default location of the cacerts file that will get placed in your build. By default an empty cacerts file is provided and that should be fine for most JDK developers.

zip and unzip

Version 2.2 (November 3rd 1997) or newer of the zip utility and version 5.12 or newer of the unzip utility is needed to build the JDK. With Solaris, Linux, and Windows CYGWIN, the zip and unzip utilities installed on the system should be fine.

Windows with MKS: If you are using MKS Toolkit, then you need MKS built versions of ZIP.EXE and UNZIP.EXE installed in ALT_DEVTOOLS_PATH. Information and the source code for ZIP.EXE and UNZIP.EXE is available on the info-zip web site.

Solaris only: unzipsfx is required for creation of Solaris installation bundles only.

Compilers
Windows i586: Microsoft Visual Studio .NET 2003
The 32-bit JDK Windows build requires Microsoft Visual Studio .NET 2003 (VS2003) Professional Edition compiler. The compiler and other tools are expected to reside in the location defined by the variable VS71COMNTOOLS which is set by the Microsoft Visual Studio .NET installer.

Once the compiler is installed, it is recommended that you run VCVARS32.BAT to set the compiler environment variables MSVCDIR, INCLUDE, LIB, and PATH prior to building the JDK. The above environment variables MUST be set. If your compiler resides in a place other than the default, you will need to set ALT_COMPILER_PATH.

Windows: Microsoft Platform SDK April 2005
On amd64, the Microsoft Platform Software Development Kit (SDK), April 2005 Edition compiler, is required for building the JDK because it contains the amd64 compiler. You will need to minimally install the Core SDK and the MDAC SDK features of this compiler. But for i586 portions of this Platform SDK is also needed. To complicate matters the Visual Studio .NET 2003 installation also contains a PlatformSDK directory that contains portions of the Platform SDK and can satisfy some of the Platform SDK needs for building on i586, for example it contains the needed UNICOWS.LIB library.

amd64 only: Once the Platform SDK is installed, it is recommended that you run SetEnv.Cmd /X64 to set the compiler environment variables MSSDK, MSTOOLS, INCLUDE, LIB, and PATH prior to building the JDK. The above environment variables MUST be set. If your compiler resides in a place other than the default, you will need to set ALT_COMPILER_PATH.

Linux gcc/binutils (i586 only)
i586 only: The binutils package 2.11.93.0.2-11 or later is required. You can obtain this binutils package from Redhat web site. You need to remove the default binutils package shipped with Redhat Enterprise Advanced Server 2.1 update 2 and install the binutils package 2.11.93.0.2-11 or later into the default location on the system.

i586 only: A GNU gcc compiler version 3.2.2 is required or gcc 3.2.1-7 built with the latest binutils package, version 2.13. This requirement is needed due to the presence of gcc assembler bugs in early versions. You need to remove the default compiler shipped with Redhat Enterprise Advanced Server 2.1 update 2 which is 2.96. However if you have a new video card driver, like Geforce 4 it is best to use the same compiler as the kernel was used to build the new module, so either build the modules now or rebuild the kernel using gcc 3.x.

The compiler resides in the /usr/bin directory. If the compiler resides in a different directory on your machine, then set ALT_COMPILER_PATH to point to the location of the gcc compiler binaries. The GCC compiler binaries must also be in the PATH.

Solaris Sun Studio 11 Compilers
Sun Studio 11, Compiler Collection (containing version 5.8 of the C and C++ compilers) is required, with patches as defined below. You can download these compilers from the Sun Studio Developer Tools web site.

Set ALT_COMPILER_PATH to point to the location of the compiler binaries, and place this location in the PATH. The necessary Sun Studio patches are available for download on the SunSolve web site.

#include /net/sca00egj.us.oracle.com/n/mustang/jdk6_105/licenseebundles/b06-2015-07-20/tmp/readme/solaris_compiler_patches.html

Mozilla Header Dependencies (for the 32-bit plugin only)
32-bit plugin only: The Mozilla plugin is currently only built for the 32-bit platforms. These files are only required for building the Java Plug-in. If you do not need to build Java Plug-in, the headers and libraries are not required.

Since Netscape 7 has been widely adopted, we decided to stop building OJI plugin for Netscape 6.x in JDK release. As a result, the JDK build requires set of header files as shown below. Download the Mozilla Header files from http://www.java.net/download/jdk6. To unpack the jar file do not run jar on it, just execute it with java -jar file.jar then place the headers and libraries into a directory similar to the one shown below. Finally, set the ALT_MOZILLA_HEADERS_PATH variable to the absolute path of the plugin directory.

Mozilla Plugin Needs gcc 2.9 Compiler
plugin only:

Solaris 32-bit only: GNU gcc version 2.95.2 is required for building the Mozilla Plug-in on Solaris. The source code for gcc is available from http://www.gnu.org/software/gcc/, and some pre-built binaries are available from sunfreeware.com. Set ALT_GCC_COMPILER_PATH to point to the location of the gcc bin directory.

Linux 32-bit only: To support Mozilla compiled with GCC egcs 2.91.66 on Linux platform, you MUST build the OJI Plug-in library using GNU gcc/g++ compiler version egcs 2.91.66. Unfortunately you have to do this without causing anything else to be built with this compiler, so this is tricky. If you can avoid building the plugin, you need not worry about this. If someone already has this compiler on a system, you should probably just set ALT_GCC29_COMPILER_PATH otherwise there are two ways to do this:

Common UNIX Printing System (CUPS) Headers (Solaris & Linux)
Solaris & Linux only: CUPS header files are required for building the JDK on Solaris and Linux. The CUPS header files may be downloaded from http://www.cups.org. The Solaris header files may also be obtained by installing the package SFWcups from the Solaris Software Companion CD/DVD. The variable ALT_CUPS_HEADERS_PATH can be used to override the default location of the CUPS Header files.

Windows Specific Dependencies

Unix Command Tools
The JDK requires access to a set of command tools on Windows supplied by MKS Toolkit or CYGWIN. Note that the build environment must be pure MKS or pure CYGWIN. An MKS build cannot use CYGWIN binaries and a CYGWIN build cannot use the MKS Shell, binaries or GNU Make built for MKS.

CYGWIN:
The JDK build requires CYGWIN version 1.5.12 or later. Information about CYGWIN can be obtained from the CYGWIN website at http://www.cygwin.com. If the binaries are not installed in /bin, set the ALT_UNIXCOMMAND_PATH variable to their location. It comes complete with GNU Make version 3.80 (as make instead of gnumake).
By default CYGWIN doesn't install all the tools required for building jdk product. Along with the default installation, you need to install the following tools.
Binary Name Package Description
ar.exe Devel binutils: The GNU assembler, linker and binary utilities
make.exe Devel make: The GNU version of the 'make' utility
m4.exe Interpreters m4: GNU implementation of the traditional Unix macro processor
cpio.exe Utils cpio: A program to manage archives of files
file.exe Utils file: Determines file type using 'magic' numbers

MKS Toolkit:
The 32-bit JDK build requires MKS Toolkit version 8.7 or later, older versions of MKS may work but they are not recommended. Information about the MKS Toolkit can be obtained from the MKS website at http://www.mks.com. If the binaries are not installed in %SYSTEMDRIVE%\mksnt\ for 32-bit and %SYSTEMDRIVE%\mksnt\mksnt for 64-bit, set the ALT_UNIXCOMMAND_PATH variable to their location.

If MKS is installed into a Path that contains spaces, it will be necessary to set ALT_UNIXCOMMAND_PATH to identify that location using Microsoft Mangled Path Name conventions. For example, if the MKS command are located in %SYSTEMDRIVE%\Program Files\MKS Toolkit\mksnt, then ALT_UNIXCOMMAND_PATH should be set to %SYSTEMDRIVE%\Progra~1\MKSToo~1\mksnt (or whatever mangled name setting is appropriate for your installation). You can use the DOS command DIR /x as an aide in determining the mangled path and file names.

Microsoft DirectX 9.0 SDK header files and libraries
Microsoft DirectX 9.0 SDK (Summer 2004) headers are required for building both 32-bit and 64-bit (amd64) JDK. This SDK can be downloaded from Microsoft DirectX 9.0 SDK (Summer 2004). If the link above becomes obsolete, the SDK can be found from http://download.microsoft.com (search with "DirectX 9.0 SDK Update Summer 2004"). The location of this SDK can be set with ALT_DXSDK_PATH but it's normally found via the DirectX environment variable DXSDK_DIR.
Microsoft Layer for Unicode on Windows 95, 98 and Me Systems libraries
i586 only: Microsoft Layer for Unicode on Windows 95, 98 and Me Systems (MSLU) libraries are required for building the JDK. The MSLU libraries consist of two files. One is the runtime binary (UNICOWS.DLL) and the other is the static library (UNICOWS.LIB). The runtime binary can be downloaded from http://go.microsoft.com/fwlink/?LinkId=14851, and the static library is included in the Microsoft Platform SDK that comes with the Microsoft Visual Studio Compiler. The version of the runtime binary DLL should be: 1.1.3790.
You can specify the locations of these files by setting the ALT_UNICOWS_DLL_PATH and the ALT_UNICOWS_LIB_PATH variables.
MSVCRT.DLL
i586 only: The JDK build requires access to a recent MSVCRT.DLL (at least version 6.00.8337.0 or newer) which is usually supplied by the Microsoft Visual Studio compiler in the redist directory. If the MSVCRT.DLL is not installed in $(J2SE_TOPDIR)\make\redist\i586, set the ALT_MSVCRT_DLL_PATH variable to their location.

amd64 only: The JDK build requires access to MSVCRT.DLL version 7.0.3790.0 and (version that we use ) supplied by The Microsoft Platform Software Development Kit (SDK), April 2005 Edition compiler (usually found in %SYSTEMDRIVE%\Program Files\Microsoft SDK\redist\win64\AMD64). If the MSVCRT.DLL is not installed in $(J2SE_TOPDIR)\make\redist\amd64, set the ALT_MSVCRT_DLL_PATH variable to their location.

MSVCR71.DLL
i586 only: If you are building with VS.NET 2003 compiler then the JDK build requires access to msvcr71 version 7.10.3052.4 (version that we use ) supplied by Microsoft Visual Studio.NET 2003 Professional Edition compiler (usually found in %SYSTEMDRIVE%\Program Files\Microsoft Visual Studio .NET 2003\ Visual Studio .NET Professional 2003 - English). If the MSVCR71.DLL is not installed in $(J2SE_TOPDIR)\make\redist\i586, set the ALT_MSVCR71_DLL_PATH variable to their location.
Microsoft MsiVal2
Only needed if creating install bundles: The MsiVal2 is only available in the Windows SDK Components for Windows Installer Developer which is included in the Microsoft Windows Software Development Kit(SDK). To obtain MsiVal2 files, you must double click on the MsiVal2.msi in the bin directory of the Platform SDK. Select "Custom" install type, and install into the %SYSTEMDRIVE%/Program Files/MsiVal2 directory.
Microsoft Msidb
Only needed if creating install bundles: The Msidb is only available in the Windows SDK Components for Windows Installer Developer which is included in the Microsoft Windows Software Development Kit(SDK). The file should be in the SDK bin directory after installing SDK. The msidb.exe should be copied into the ALT_DEVTOOLS_PATH.
Microsoft Msicert
Only needed if creating install bundles: The Msicert is only available in the Windows SDK Components for Windows Installer Developer which is included in the Microsoft Windows Software Development Kit(SDK). The file should be in the SDK bin directory after installing SDK. The msicert.exe should be copied into the ALT_DEVTOOLS_PATH.
Microsoft Msitran
Only needed if creating install bundles: The Msitran is only available in the Windows SDK Components for Windows Installer Developer which is included in the Microsoft Windows Software Development Kit(SDK). The file should be in the SDK bin directory after installing SDK. The msitran.exe should be copied into the ALT_DEVTOOLS_PATH.
Microsoft Cabarc
Only needed if creating install bundles: The CABARC is included in the Microsoft Cabinet Software Development Kit. The file should be in the SDK bin directory after installing SDK. The cabarc.exe should be copied into the ALT_DEVTOOLS_PATH.

Motif Headers and Libraries (Solaris & Linux only)
Linux
Motif version 2.1 headers and libraries are required for building the Linux JDK. NOTE: (Motif 2.2 headers will not work.)

As a convenience, the source bundles include an archive of motif workspace that incorporate a number of JDK-related bug fixes. The control workspace target gnumake dev would automatically take care of building our motif workspace and generate motif headers and libraries and use them when it required in the build. 

                +- $(OUTPUTDIR)/
                +- motif/   (Automatically ALT_MOTIF_DIR will get set to this directory.)
                +- include/
                +- lib/
Solaris
Motif version 2.1 headers and libraries are required for building the JDK.

Create a Motif library and header area that contains header files and libraries for Motif 2.1. Use the ALT_MOTIF_DIR variable to point to absolute path of the Motif directory. The top level of the directory must contain directory named motif21, which must have subdirectories include and lib with contents as shown here: 

                +- motif_area/  (set ALT_MOTIF_DIR to this level)                 
                +- motif21/
                +- include/
                |  +- Xm/  (from /usr/include/Xm)
                |     +- <many files>
                |    
                +- lib/    (from /usr/dt/lib/) 
                +- libXm.so (symbolic link to libXm.so.4)
                +- libXm.so.4
                +- sparcv9/    (64-bit Motif library)
                +- libXm.so (symbolic link to libXm.so.4)
                +- libXm.so.4
In the example above, the name of the top-level directory is not significant; it is not required to be named motif_area.

Advanced Linux Sound Architecture (ALSA) (Linux only)
Linux only: Advanced Linux Sound Architecture version 0.9.1 or later is required for building the JDK on Linux.

Redhat AS 2.1 U2, and SuSE 8.1 do not include a sufficiently recent ALSA distribution. Most modern Linux distributions ship with ALSA. On rpm-based systems, you can see if ALSA is installed by running this command:
rpm -qa | grep alsa
Both alsa and alsa-devel packages are needed.

If your distribution does not come with ALSA, you can install pre-built ALSA rpm packages, for example from Fresh RPMs.

Note that installing a newer ALSA could break sound output if an older version of ALSA is installed on the system, but it will enable J2SE compilation.
Installation: execute as root
[i586]: rpm -Uv --force alsa-lib-devel-0.9.1-rh61.i386.rpm
[amd64]: rpm -Uv --force alsa-lib-devel-0.9.8-amd64.x86_64.rpm
Uninstallation:
[i586]: rpm -ev alsa-lib-devel-0.9.1-rh61
[amd64]:rpm -ev alsa-lib-devel-0.9.8-amd64
Make sure that you do not link to the static library (libasound.a), by verifying that the dynamic library (libasound.so) is correctly installed in /usr/lib.

If you are unable to find a pre-built ALSA package, you need to build it from the source distribution: Download driver and library source tarballs from ALSA's homepage. As root, execute the following commands (you may need to adapt the version number): 

            
                $ tar xjf alsa-driver-0.9.1.tar.bz2
                $ cd alsa-driver-0.9.1
                $ ./configure
                $ make install
                $ cd ..
                $ tar xjf alsa-lib-0.9.1.tar.bz2
                $ cd alsa-lib-0.9.1
                $ ./configure
                $ make install

Should one of the above steps fail, refer to the documentation on ALSA's home page. Note that this is a minimum install that enables building the JDK platform. To actually use ALSA sound drivers, more steps are necessary as outlined in the documentation on ALSA's homepage.

ALSA can be uninstalled by executing make uninstall first in the alsa-lib-0.9.1 directory and then in alsa-driver-0.9.1.

There is no ALT* variable to change the assumed locations of ALSA, the makefiles will expect to find the ALSA include files and library at: /usr/include/alsa and /usr/lib/libasound.so.

JDBC-ODBC Bridge (Solaris only)
Solaris only: The DataDirect Connect ODBC 2.11 driver is needed for building the JDBC-ODBC Bridge. A copy of the driver is on the Desktop 1.1.1 Solaris CD-ROM, which is part of older Solaris distributions.

Set up the following directory structure for the ODBC driver, and set the ALT_ODBCDIR variable to point to it. 

            +- odbc/            (set ALT_ODBCDIR to this level)
            +- ISLIodbc/
            +- 2.11/       
            +- odbc files and directories (lib/, include/, etc.)
On SPARC systems you may use the DataDirect ODBC 3.7 driver in place of the 2.11 driver: use the directory structure above (including the 2.11 directory) if doing so.

An alternative to using a DataDirect driver is to build a dummy driver of your own. Create and then "cd" to the directory $(ALT_ODBCDIR)/ISLIodbc/2.11/lib, copy over the source file j2se/make/sun/jdbc/dummyodbc.c, and then compile as follows using the Sun C compiler: 

            cc -G -h libodbc.so -o libodbc.so dummyodbc.c
            cc -G -h libodbcinst.so -o libodbcinst.so dummyodbc.c

DTrace Availability (Solaris only)
Solaris only: To create a hotspot build that has all the DTrace probes requires access to a DTrace compiler (dtrace), not the DTrace runtime support, on the Solaris system doing the build. This means that sparc, sparcv9, and i586 Solaris build machines need access to a special informal DTrace compiler built for Solaris 8. This Solaris 8 SUNWdtrd package is currently not publicly available. The Solaris amd64 builds are done on Solaris 10, which has a dtrace utility, and any builds done on Solaris 10 or newer will also have dtrace and will create hotspot versions with the DTrace probes.

The DTrace probes are created by running the *.d files through the DTrace compiler to generate *.o files that get linked into hotspot shared library libjvm.so.

The official JDK build platform for sparc, sparcv9, and i586 is Solaris 8. You can build the JDK using a more recent version of Solaris (such as Solaris 10 or Solaris Express), and it will work fine on that version or any later version.

Creating the Build

Once a machine is setup to build the JDK, the steps to create the build are fairly simple. The various ALT settings can either be made into variables or can be supplied on the GNUmake command.

  1. cd into the control/make directory.
  2. Use the dev-sanity rule to double check all the ALT settings:
    GNUmake dev-sanity [ARCH_DATA_MODEL=32 or 64] [ALT_OUTPUTDIR=output_directory] [MILESTONE=milestone_name] [BUILD_NUMBER=build_number] [other "ALT_" overrides]
  3. Start the build with the command:
    GNUmake dev [ARCH_DATA_MODEL=32 or 64] [ALT_OUTPUTDIR=output_directory] [MILESTONE=milestone_name] [BUILD_NUMBER=build_number] [other "ALT_" overrides]

Solaris: Note that ARCH_DATA_MODEL is really only needed on Solaris to indicate you want to built the 64-bit version. And before the Solaris 64-bit binaries can be used, they must be merged with the binaries from a separate 32-bit build. The merged binaries may then be used in either 32-bit or 64-bit mode, with the selection occurring at runtime.

Testing the Build
When the build is completed, you should see the generated binaries and associated files in the j2sdk-image directory in the output directory. The default output directory is control/build/platform, where platform is one of "solaris-{sparc,sparcv9,i586,amd64}", "linux-{i586,amd64}", or "windows-{i586,amd64}" . In particular, the control/build/platform/j2sdk-image/bin directory should contain executables for the JDK tools and utilities.

You can test that the build completed properly by using the build to run the various demos that you will find in the control/build/platform/j2sdk-image/demo directory. For example to run the Java 2DTM technology demo, change directories to control/build/platform/j2sdk-image/demo/jfc/Java2D and launch the demo with this command:

../../../bin/java -jar Java2Demo.jar -runs=1

The demo application should run and cycle through all the Java2Demo tests.

Environment/Make Variables

The environment or make variables (just called variables in this document) that can impact the build are:

PATH
Typically you want to set the PATH to include:
  • The location of the GNU make binary
  • The location of the JDK 5.0 java (see Bootstrap JDK)
  • The location of the C/C++ compilers (see compilers)
  • The location or locations for the Unix command utilities (see ALT_UNIXCOMMAND_PATH)
ARCH_DATA_MODEL
The ARCH_DATA_MODEL variable is used to specify whether the build is to generate 32-bit or 64-bit binaries. The Solaris build supports either 32-bit or 64-bit builds, but Windows and Linux will support only one, depending on the specific OS being used. Normally, setting this variable is only necessary on Solaris. Set ARCH_DATA_MODEL to 32 for generating 32-bit binaries, or to 64 for generating 64-bit binaries.
MILESTONE
The milestone name for the build (e.g."beta"). The default value is "internal".
BUILD_NUMBER
The build number for the build (e.g. "b27"). The default value is "b00".
ALT_BOOTDIR
The location of the bootstrap JDK installation. See Bootstrap JDK for more information. The first default will be %SYSTEMDRIVE%/jdk1.5.0 on Windows, and $(ALT_SLASH_JAVA)/re/j2se/1.5.0/archive/fcs/binaries/platform on Solaris and Linux. If the first default does not exist, then the second default is /opt/java/jdk1.5.0 on Linux, /usr/jdk/instances/jdk1.5.0 on Solaris, and %SYSTEMDRIVE%/Program Files/Java/jdk1.5.0 on Windows. However, it's a good idea to install your own Bootstrap JDK and always set ALT_BOOTDIR explicitly.
ALT_OUTPUTDIR
An override for specifying the (absolute) path of where the build output is to go. The default output directory will be control/platform.
ALT_UNIXCOMMAND_PATH
An override for specifying where the Unix command set are located. The default location varies depending on the platform, "%SYSTEMDRIVE%/MKSNT" or $(ROOTDIR) on Windows with MKS, otherwise it's "/bin" or /usr/bin.
ALT_UNIXCCS_PATH
Solaris only: An override for specifying where the Unix CCS command set are located. The default location is /usr/ccs/bin
ALT_USRBIN_PATH
An override for specifying where the Unix /usr/bin commands are located. You usually do not need to set this variable: the default location is /usr/bin)
ALT_COMPILER_PATH
The location of the C/C++ compiler. The default varies depending on the platform.
ALT_CACERTS_FILE
The location of the cacerts file. The default will refer to j2se/src/share/lib/security/cacerts if it exists, otherwise it will use j2se/src/share/lib/security/cacerts.internal.
ALT_SLASHJAVA
The default root location for many of the ALT path locations of the following ALT variables. The default value is "/java" on Solaris and Linux, "J:" on Windows.
ALT_JDK_DEVTOOLS_PATH
The default root location of the devtools. The default value is $(ALT_SLASH_JAVA)/devtools.
ALT_DEVTOOLS_PATH
The location of tools like the zip and unzip binaries, but might also contain the GNU make utility (gnumake). So this area is a bit of a grab bag, especially on Windows. The default value depends on the platform and Unix Commands being used. On Linux the default will be $(ALT_JDK_DEVTOOLS_PATH)/linux/bin, on Solaris $(ALT_JDK_DEVTOOLS_PATH)/{sparc,i386}/bin, on Windows with MKS %SYSTEMDRIVE%/UTILS, and on Windows with CYGWIN /usr/bin. These tools are also needed for building install workspace install_msidb, install_msicert, install_cabarc and install_msitran.
ALT_JDK_IMPORT_PATH
The location of the import JDK installation. See Import JDK for more information. The default value is $(ALT_SLASH_JAVA)/re/j2se/1.6.0/promoted/latest/binaries/platform.
ALT_CUPS_HEADERS_PATH
The location of the CUPS header files. See CUPS information for more information. The default value is $(ALT_JDK_DEVTOOLS_PATH)/shared/cups. If this path does not exist the fallback path is /usr/include.
ALT_MOZILLA_HEADERS_PATH
plugin only: The location of the Mozilla Header files. See Mozilla Headers for more information. The default location is $(ALT_JDK_DEVTOOLS_PATH)/share/plugin
ALT_MOTIF_DIR
The location of the Motif 2.1 headers and libraries. See Motif for details.
ALT_ODBCDIR
The location of the ODBC driver. See JDBC-ODBC Bridge for details.
ALT_GCC_COMPILER_PATH
plugin only: The location of the GNU C compiler and tools, for building the Plug-in. See Mozilla Plugin Needs gcc 2.9 Compiler for details.
ALT_GCC29_COMPILER_PATH
plugin only: An override for specifying the location of the GCC 2.9 compiler. See Mozilla Plugin Needs gcc 2.9 Compiler for details.
ALT_GCC29_PLUGIN_LIB_PATH
plugin only: An override for specifying the location of the OJI Plug-in library compiled with GCC 2.9. See Mozilla Plugin Needs gcc 2.9 Compiler for details.
Windows specific:
ALT_MSDEVTOOLS_PATH
The location of the Microsoft Visual Studio .NET 2003 tools 'bin' directory. The default is usually derived from ALT_COMPILER_PATH.
ALT_DXSDK_PATH
The location of the Microsoft DirectX SDK. The default will be to try and use the DirectX environment variable DXSDK_DIR, failing that, look in %SYSTEMDRIVE%/DXSDK.
ALT_INSTALL_MSIVAL2
Only needed if creating install bundles: The location of the Microsoft MsiVal2. The default will be to look in %SYSTEMDRIVE%/Program Files/MsiVal2.
ALT_MSVCRT_DLL_PATH
The location of the MSVCRT.DLL.
ALT_MSVCR71_DLL_PATH
i586 only: The location of the MSVCR71.DLL.
ALT_UNICOWS_DLL_PATH
i586 only: The location of the Microsoft Layer for Unicode runtime binary path. The default value is %SYSTEMDRIVE%/MSLU if it exists, or $(ALT_JDK_DEVTOOLS_PATH)/windows/MSLU.
ALT_UNICOWS_LIB_PATH
i586 only: The location of the Microsoft Layer for Unicode static library path. The default value is %SYSTEMDRIVE%/MSLU if it exists, or $(ALT_JDK_DEVTOOLS_PATH)/windows/MSLU.
SECURITY_BASELINE_131
The version corresponding to the latest publicly available JRE 1.3.1 update release (e.g. "1.3.1_20"). This environment variable is for the windows platform only and will be used to generate the PluginVersion.h file. The value will be used in the ssv.dll.
SECURITY_BASELINE_142
The version corresponding to the latest publicly available JRE 1.4.2 update release (e.g. "1.4.2_10"). This environment variable is for the windows platform only and will be used to generate the PluginVersion.h file. The value will be used in the ssv.dll.
SECURITY_BASELINE_150
The version corresponding to the latest publicly available JRE 1.5.0 update release (e.g. "1.5.0_07"). This environment variable is for the windows platform only and will be used to generate the PluginVersion.h file. The value will be used in the ssv.dll.
Java SE Embedded specific:
JAVASE_EMBEDDED
If defined, indicates that this is a build of the Java SE Embedded product. It enables the rules and targets that are specific to Java SE Embedded.
BUILD_CLIENT_ONLY
If defined, indicates that only the "client" version of the Hotspot Virtual Machine is to be built. This affects the libraries placed into the JRE, and aliases the "-server" option to the "-client" option. It should only be defined when JAVASE_EMBEDDED is defined.
BUILD_HEADLESS_ONLY
If defined, indicates that only a headless JRE should be built. This option is used for environments where there is no support for any headful functionality. It should only be defined when JAVASE_EMBEDDED is defined.
MINIMIZE_RAM_USAGE
If defined, causes the building of the Hotspot Virtual Machine to incorporate functional changes that reduce the memory consumption of the VM. It should only be defined when JAVASE_EMBEDDED is defined.
USE_ONLY_BOOTDIR_TOOLS
If defined, indicates the build tools (e.g. javac) should be executed from the BOOTDIR only. In a normal build the tools built in one phase will then be used to build other parts of the system, however that won't work in a cross-compilation environment. This variable should always be defined when CROSS_COMPILE_ARCH is defined.
CROSS_COMPILE_ARCH
The target architecture for a cross-compilation build. If this is defined then you must also set the ALT_COMPILER_PATH to point to a suitable cross-compiler, and set the USE_ONLY_BOOTDIR_TOOLS variable. Cross-compilation is only currently supported within a Java SE Embedded build.

Building Just the JRE
It is possible to build the Java 2 Runtime Enviroment instead of the full JDK. To peform a JRE only build, set the variable J2RE_ONLY to any value, such as 'true'. This tells the build that only JRE sources are to be built.

The only targets supported for the JRE builds are 'all' and 'clobber'.

Troubleshooting

A build can fail for any number of reasons. Most failures are a result of trying to build in an environment in which all the pre-build requirements have not been met. The first step in troubleshooting a build failure is to recheck that you have satisfied all the pre-build requirements for your platform.

You can validate your build environment by using the dev-sanity target from the control/make directory. Any errors listed will stop the build from starting, and any warnings may result in a flawed product build. We strongly encourage you to evaluate every sanity check warning and fix it if required, before you proceed further with your build.

Some of the more common problems with builds are briefly descibed below, with suggestions for remedies.

Copyright (c) 2006, Oracle and/or its affiliates. All rights reserved.