A work in progress.
Builds done on 32bit machines, or creating 32bit native code object files, libraries, and executables. A 32bit JDK build always includes a complete JDK image.
Release name for OpenJDK 6.
Builds done on 64bit capable machine and creating 64bit native code object files, libraries, and executables.
On Linux 64bit and Windows 64bit, a 64bit build is a complete JDK build, and although
a 32bit build could be done on a 64bit Linux or Windows machines, it's not common practice.
On Solaris, a 64bit build is just the native code object files, libraries, and executables,
which means that a Solaris 64bit build needs to be 'added on' to a Solaris 32bit build.
Only on Solaris can you run one JDK and ask for either a 32bit execution (-d32) or a
64bit execution (-d64).
Makefile variable setting that determines if it is a 32 or 64 bit build. Set to 32 or 64.
Makefile variable naming convention
used in JDK Makefiles to select alternative paths, locations, or settings.
Location of OpenJDK binary plugs.
Location of JDK used to build the JDK, usually the previously released JDK.
Alternative location for the native compiler to use.
The location of the corba "dist" directory to get the corba files from.
Location of the CUPS include files.
Location of Platform SDK installation (Windows only).
Location of DirectX 9 SDK installation (Windows only).
Location of the freetype native include files.
Location of the freetype native libraries.
The location of the jaxp "dist" directory to get the jaxp files from.
The location of the jaxws "dist" directory to get the jaxws files from.
The location of the JDK import image.
This is used to fill in the gaps when doing partial builds of the jdk.
This should be a recent build of the same version of the JDK you are building.
The location of the langtools "dist" directory to get the javac files from.
On Linux and Solaris, the parallel build feature of GNU make is used to build all
the object files for a library in parallel, based on this setting.
Depending on the number of CPUs you have, this number should be set to something
between nCPUS+1 and nCPUS*2.
Each system is different and some experimentation may be required.
When doing a full control build, one of the last steps is to compare the JDK image
you just created with a previous JDK image. This is the image you will compare with.
Often this is the previous JDK release, and could be the same as ALT_BOOTDIR.
Many of the default paths for the various ALT_* settings are rooted at the path
"/java/" or "J:/" on Windows. This variable allows you to change that root in case
you have created an exact copy of the "/java/" area in a local disk area or faster
Unfortunately, this layout isn't completely documented and may need to be deduced
from the output of 'gnumake sanity' output.
See Change Request.
See Change Request.
JDK compatibility process for developers. TBD for OpenJDK.
See Change Request.
A Change Request or CR (also referred to as a bug, rfe, or bugid) is an entry in the
Sun bug tracking system. These can be seen partially from http://bugs.sun.com.
The OpenJDK bug tracking system is TBD, but for now CR's will have to do.
A CR number is a 7 digit number, and one of these is required for every change made
to the JDK sources.
If you see the 7 character pattern "NoBugID" used, it means that no official CR was
created for this change, you should rarely if ever see them.
A subset of the JDK is considered to be the
<a href="http://openjdk.java.net/groups/core-libs/" >Core Libraries</a>.
Distributed Source Code Management (SCM) system.
Some examples are TeamWare, Mercurial, and git.
Users can 'clone' or create child repositories or workspaces that are complete
copies allowing for distributed development that can optionally be merged back
into the primary branch of development or not.
CVS and SubVersion are not distributed, there is only one instance of a repository.
An internal Sun testing grid system used to test JDK promotions and releases.
The JDK VM or JVM.
There are various implementations of the HotSpot VM: client, server, tiered, and kernel.
An environment variable used to trigger the 'java' found in your PATH to use a different
JDK image. Unfortunately, not all 'java' startup scripts obey this env variable.
It's also used by many java tool startup scripts to determine what 'java' to run, bypassing
the 'java' found in the PATH setting.
Setting this variable during a JDK build is a bad idea, don't do it.
An internal Sun build system that was created from the hotspot specific PRT build system.
The name given to the primary or master copy of the sources for a release.
It is the MASTER sources that JDK promotion builds are built from.
See Change Request.
A formal testing process that integrators are required to go thorough prior to integrating
their source changes into the MASTER area.
Also spelled "PlatformSDK" or just 'PSDK".
This is a Platforms specific SDK kit that must be installed on Windows systems
in order to build the JDK.
With Windows 32bit, the Visual Studio 2003 compiler installation may include at least
a partial PlatformSDK
image, but the full Windows Platform SDK may also need to be installed on 32bit systems.
On Windows 64bit systems, the PlatformSDK is critical because the native compiler for 64bit
will come from this SDK.
The specific version of the PlatformSDK you install is critical, and depends on the
version of the JDK you are building.
See Platform SDK.
See Change Request.
Source Code Control System. Unix per-file source code change system.
Used by TeamWare to manage the changes to individual files.
A pattern of a '%' uppercase letter and another '%', e.g. %W%, that when used in a
source file controlled by SCCS would get expanded on a 'sccs get' operation and
not expanded during the edit of a source file.
Lots of different types of keywords were available, e.g.
version numbers of files, dates of changes, etc.
The commit of a change to an SCCS file creates an SCCS rev for that file.
Software Development Kit. A horribly overused term which means a big bag of stuff
that is usually associated with helping you develop some kind of software that uses
a particular API or platform.
Version 8 of the Sun Studio native compilers and tools.
This version was used in the jdk5 release.
Version 9 of the Sun Studio native compilers and tools.
This version was never used for any jdk releases.
Version 10 of the Sun Studio native compilers and tools.
This version was used for the Solaris X64 bits of jdk5, and for the
initial builds of jdk6 before it was released.
Version 11 of the Sun Studio native compilers and tools.
This version was used for the jdk6 release, and what is being used now
for the jdk7 builds.
Version 12 of the Sun Studio native compilers and tools.
Most recent release, and will probably be one used to build jdk7.
This release also has Linux X86 compilers, use of the Linux release
is being investigated.
The old Microsoft C/C++ compilers and tools used to build jdk5 on Windows 2000 32bit.
Visual Studio 2003 .NET. Used to build jdk6 on Windows 2000 32bit.
Visual Studio 2005 .NET. Some kind of preliminary VS2005 64bit version was part of the
PlatformSDK used to build jdk6 and jdk7 Windows 2003 64bit builds.
Build tool used by some parts of the jdk7 sources.
Term used to indicate either approval of a webrev by a fellow engineer, or higher level
approval by a group that indicates the changes have been approved for putback or integration.
The missing parts of the JDK whose source is not available in the OpenJDK.
These are quickly being replaced with open source versions, so the hope is that some
day we would talk about these in the past tense, e.g. "Remember when we had those painful binary plugs?". :^)
TeamWare action of pulling changes from one workspace to another.
Conflicts are allowed and would have to be resolved.
Usually "product", "debug", or "fastdebug", and reflects how the source code was
compiled. The product build flavor is usually optimized code with no assert type
checking left in the product and little debugging information.
The debug build is usually not optimized at all, has
all assert checking in place and complete debug information.
The fastdebug build is a debug build but with as much optimization of the code as feasible.
Mercurial term used to describe a complete change. Can include file changes, file deletes,
file renames, and file additions.
See webrev and review.
Mercurial action that actually creates a formal changeset.
When separate changes are made to the same file and they have to be resolved or merged.
The name of the jdk workspace that controls the complete jdk build.
Using the control workspace to build the jdk.
The jdk workspace that contains all the corba contributions to jdk7.
Windows open source software than can be used to build the jdk.
The jdk workspace that contains the plugins and java webstart.
Mercurial term for adding functionality, e.g. the "forest extension".
Software that can be used to find common bug patterns in classfiles and Java sources.
The GNU C compiler, sometimes also refers to the GNU C++ compiler g++.
See include files.
The Mercurial command name.
Mercurial resource file. Users have a ~/.hgrc file, repositories have a .hg/hgrc file, and the
installation of Mercurial has a etc/mercurial/hgrc file.
Mercurial feature that allows repository actions to be checked or monitored.
After building a jdk, the Makefile target "images" is used to create the actual jdk and jre
Native code files that contain global type, variable and/or function declarations and prototypes.
The name of a closed workspace that creates the official install bundles, but also a general
term for the act of installing something. DUH.
The actual jdk disk image that represents what the end user would see after an install.
Typically contains the following directories: bin, lib, include, man, and demos.
The act of doing the putback or push of the changes into a shared team or MASTER source tree area.
The javah tool is run over class files to create header or include files that can be
used with the native code to implement the "native" java methods.
Java 2 Standard Edition. Old name, don't use it anymore. Use jdk.
Never let marketing control your version numbers or product name. ;^)
This is also the name of the primary jdk workspace that built most of the
jdk classes and jni support libraries (minus hotspot and the plugins).
The jdk workspace that contains the JAXP team contribution to jdk7.
In jdk6 and jdk5, these sources were part of the j2se workspace.
The jdk workspace that contains the JAX-WS team contribution to jdk7.
Contains JAXB and JAF classes too.
Java Development Kit or Jim's Designer Kitchen.
The 1.5 release of the jdk, also jdk 1.5, jdk 1.5.0, or just jdk 5.
Update release of jdk5. DUH.
The 6 release of the jdk, also jdk 1.6.0, or just jdk 6.
Update release of jdk6. DUH.
The current jdk release.
Sun internal tool used for jdk planning.
Tool available on OpenJDK site, used to run the regression tests in the OpenJDK sources.
A command script over the JavaTest framework.
The jdk workspace that contains the javac team contribution to jdk7.
In jdk6 and jdk5, these sources were part of the j2se workspace.
Mercurial DSCM. DUH.
Mercurial term used to merge changesets. With Mercurial there needs to be one
changeset that represents the state of the entire repository, so when changesets
mix, a merge changeset needs to be created so we have one changeset again.
Unix tools for Windows than can be used instead of cygwin for building the jdk.
A former jdk workspace that is no longer needed in jdk7.
C, C++, or assembly code that creates native object files, libraries, or executables.
Header files or include files are also considered native code.
Original open source of the jdk.
The 6-open release of the OpenJDK.
The original OpenJDK release that will be used to create jdk7.
Any build of a jdk that doesn't include the complete set of jdk sources.
A partial build will typically rely on a JDK_IMPORT_PATH setting to import the non-built parts
of the jdk.
Building on a particular platform. The current platforms that the jdk7 is built on regularly
are: Solaris 10 X86, Solaris 10 X64, Solaris 10 SPARC, Solaris 10 SPARCV9, Windows 2000 X86,
Windows 2003 X64, Linux RedHat 2.1AS X86, and Linux SuSE SLES-8.1 X84.
But jdk7 is buildable on many more platforms than these.
Source of jdk documents. Currently not "open".
Mercurial command that pulls changesets from one Mercurial repository to another repository.
Mercurial command that pushes changesets from one Mercurial repository to another repository.
TeamWare command that pushes changed SCCS files from one TeamWare workspace to another workspace.
In the jdk, tests that are in the source tree test directory.
Policy dictates that any bug fix should have an associated regression test to verify that the fix
The term Mercurial uses for a managed source tree.
TeamWare command used to resolve conflicts in file changes between different SCCS revisions.
The action of doing a code review, usually using a webrev.
Source Code Management system.
Horribly overused term that in this case indicates a machine that holds the files of a
workspace or repository.
Integrations into MASTER are treated special. Integrators into the MASTER area are
given a time "slot", usually a AM or PM time slot where they have putback or push
rights to the MASTER area reserved.
During this time the integrator would be expected to sync, build, and test prior
to integrating his changes into the MASTER sources.
A zip or tarball of a source tree.
The sources that are managed by a SCM, minus any SCM support files or directories.
The name for a closed jdk workspace.
Secure shell. A more secure and better way to access machines on a network.
Replaces things like telnet, rsh and rlogin.
The basic way ssh works is with keys. Run ssh-keygen to create your ssh key.
Sun's JDK, available from http://java.sun.com.
The action of pulling the latest changes from a MASTER or
team integration area into your own changes and merging it all together.
TeamWare is a distributed source code management system. A Sun product.
A script or tool that creates browsable pages for a change to a managed source tree.
Also used to describe these browsable pages, e.g. using webrev to create a webrev.
Used for all code reviews, and all code changes must be reviewed.
With Mercurial, browsing a changeset is very similar to browsing a webrev.
TeamWare term for s managed source tree.