Curiosity kills the sheep

Many friends do Java development, write Java code every day, must be inseparable from the Java basic environment: JDK, after all, we write Java code is also run in the JVM VIRTUAL machine.

Generally speaking, the first step before we learn Java is to install the JDK environment. This is easy, we usually directly download the JDK from the official website, after installation, with environment variables can be used happily.

On the other hand, aren’t we curious about the source code for something we use every day?

With this original question, today ready to do a big, their lovely hands, to compile a belongs to their own JDK!

By the way, this article is in the open source project: github.com/hansonwang9… Has been included, including self-study programming route, interview questions set/interviews, and a series of technical articles, etc., resources continue to update…

There’s still a hole to fill

Remember before not out of a “JDK source reading environment” related to the video and article well, careful partners, may find a very practical problem:

We unzip the JDK source code from the src.zip package. After associating it with the source code, we can debug it, but when we comment it, we can only add it at the end of the line without changing the line structure of the original code. In other words, if you add multiple lines of comments across the source code, debugging will cause the current line to run improperly, which is a bit embarrassing.

Of course, in the comments section of the video, a few friends did ask this question:




The reason is also very simple, because the actual support for debugging run code, and not the JDK source code we decompressed, that is only associated with the actual use of the JDK, or the previous system installed the JDK environment.

To solve this problem, you can only use your own modified code to compile and generate your own JDK, and then use it in the project!

So if you say anything, the liver’s gone!

Environment to prepare

The first choice is that the relationship between the software version before compilation is extremely important. When I step on the pit, all kinds of strange problems appear almost all related to this. After the version match, it is very smooth.

Let’s take stock of the environment and tools needed to build a JDK:

1, the boot JDK

If you want to compile JDK, you must have installed a JDK in advance, officially called bootstrap JDK (or boot JDK).

For example, if you want to compile JDK 8, you must have at least a VERSION of JDK 7 or later. If you want to compile JDK 11, you must have JDK 10 or 11 installed on the machine.

So the chicken came and the egg came again…

2. Unix environment

Compiling the JDK requires Unix support!

While this is naturally guaranteed on Linux and macOS, it is a bit more difficult for Windows brothers to simulate using software such as Cygwin or MinGW/MSYS.

Compiling the JDK on Linux usually has the least problems and is easy to succeed. MacOS times; Windows takes a little more effort and may have more problems.

The essential reason is that Windows is not a UNIX-like kernel system, after all, the original compilation of many software is inseparable from Unix Toolkit, so it is relatively troublesome.

Compiler/compiler toolchain

Much of the underlying JDK source code (especially the JVM part) is written in C++/C, so the compiler can’t escape.

A picture is worth a thousand words. The compiler support on each platform is shown in the following table.

4. Other tools

Typical examples are:

  • Autoconf: automatic configuration tool for the software source package
  • Make: compilation build tool
  • freetype: a free rendering library,JDKThe graphical part of your code might use it

JDK 8 and JDK 11 (JDK 11 and JDK 8)

When compiling JDK 8:

  • The operating system: macOS 10.11.6
  • boot JDK: JDK 1.8.0 (build 1.8.0_201-b09)
  • Xcode version: 8.2
  • The compiler: Version 8.0.0 (at /usr/bin/clang)

When compiling JDK 11:

  • The operating system: macOS 10.15.4
  • boot JDK: JDK 11.0.7 (build 11.0.7+ 8-lts)
  • Xcode version: 11.5
  • The compiler: Version 11.0.3 (at /usr/bin/clang)

If you have a lot of problems in the process of compilation, there is a high probability that the software is not installed, or the software version does not match, do not give up easily, need to be patient self-check.

Download JDK source code

There are actually two ways to download JDK source code.

Method 1: Download the file from Mercurial

Mercurial, like Git, is another code management tool that comes with a Mercurial command once installed.


And its source has managed to http://hg.openjdk.java.net/ in advance.

With git Clone, you can do the same with JDK 8:

hg clone http://hg.openjdk.java.net/jdk8/jdk8

Copy the code

Likewise, download JDK 11:

hg clone http://hg.openjdk.java.net/jdk/jdk11

Copy the code

But it doesn’t download very quickly.

Method 2: Directly download the packaged source code package

Download it at https://jdk.java.net/


Select the version you want to download.

Automatic configuration before compilation

Source code package download, put in a local directory (recommended path pure English, avoid unnecessary trouble), decompress it, and then enter the source code root directory, execute:

sh configure

Copy the code

Of course, the default configuration is run here.

This step does a bunch of automatic configuration work, which is usually very quick, and if you get a prompt, you’re lucky enough to have done the pre-compile configuration!

Here’s what I looked like when I configured JDK 11 and JDK 8 respectively:

JDK 8 configuration complete:


JDK 11 configuration complete:


Note: if this step is wrong, it is most likely that a software environment is not installed, or even if installed, but the version does not match, the console print log will generally be reminded.

Errof: GCC compiler is required


This error is reported even though the system already has a compiler. By then modify the JDK source root directory/common/autoconf/generated – configure. Sh file, the relevant configuration through after the two lines of code comments



Now that the configuration is complete, it’s time to do the actual compilation!

The actual compilation action

This is a full compilation of the JDK. You can run the following command in the root directory of the JDK:

make all

Copy the code

This step takes a while to compile, so be patient. If there is an error during the compilation process, the compilation will terminate. If you can see the following two screens, then congratulations, you have passed the compilation of the JDK source code, you can have a cup of coffee to celebrate.

JDK 8 compiled:


JDK 11 compiled:


As you can see from the comparison of these two figures, there is a difference in output when compiling JDK 8 and JDK 11. Much of the difference in timing comes from the much higher compiler configuration in JDK 11.

Verify the results

We can’t wait to see what the JDK source code will produce and output once compiled.

Because the source packages in JDK 8 and JDK 11 are organized differently, the content and location of the output differs. Let’s take inventory one by one.

1. Compilation output of JDK 8

After compiling, a macosx-x86_64-normal-server-release directory is generated in the build directory, where all the compilation results are located.

First, compiled Java executables can be found in the following directory:

JDK root directory /build/macosx-x86_64-normal-server-release/ JDK /bin

After entering the directory, run the./ Java -version command to verify:


Second, compile the generated finished JDK package, which can be in the directory

JDK root directory /build/macosx-x86_64-normal-server-release/images

Copy the code

Find below, as shown in the figure:


Among them:

  • j2sdk-image: Builds the generated JDK
  • j2re-image: Compiles the generated JRE

Enter the J2SDK-Image directory and you will find that the content inside is consistent with the content of the finished JDK we usually download from the network.


2. Compilation output of JDK 11

The source directory of JDK 11 is organized differently from that of JDK 8 itself, and the resulting output differs somewhat, but not significantly, from that of JDK 8 compiled above.

After JDK 11 is compiled, a macosx-x86_64-normal-server-release directory is generated in the build directory, where all the compilation results are located.

Similarly compiled Java executables can be found in directories

JDK root directory /build/macosx-x86_64-normal-server-release/ JDK /bin

After entering the directory, you can also run the./ Java -version command to verify:


Second, compile the generated finished JDK 11 package, which can be in the directory

JDK root directory /build/macosx-x86_64-normal-server-release/images

Copy the code

Find below, as shown in the figure:


The JDK directory is a compilation of the finished JDK 11 suite.

Use your own compiled JDK

Now that we have compiled the finished JDK, we need to use wow.

Create a very basic Java project, such as JdkTest, to use our own compiled JDK.


Let’s click on Project Structure, go to SDKs, add the JDK we just compiled and generated, and select it as the JDK of the Project to see if it works



After clicking OK, we run:


You can see that our own compiled JDK is already in use.

Associate JDK source code and modify it

In the JdkTest Project Structure → SDKs, we will associate the JDK source code with the JDK source code path we downloaded:


This makes it easy for us to read, debug, modify the JDK source code we download, and make notes and annotations in the source code.

For the simplest example, let’s open the underlying source code for system.out.println () :


Let’s make some random changes to it by adding two simple lines like this:


In order for our new line of code to take effect, we have to go back to the JDK source directory and run make Images to recompile the JDK:


Incremental compilation is usually fast when you make it again because it has been fully compiled before.

After recompiling, we can run the JdkTest project again and see the changes:


Problem with multi-line comments

Remember the previous build “JDK source reading environment”, we may find a problem: read the source code, to make some notes or notes to the source code is very common! However, the problem at that time is that the line structure of the code cannot be changed when making comments (only comments at the end of the line, not across the line). Otherwise, the line number may be misplaced during debugging.

The reason is very simple, because we have done the mapping of the source directory, although the actual support running JDK is installed in advance the JDK environment, not according to our modified source code to recompile the build, so here, the solution to this problem is very simple, just like the above to compile the JDK.

In fact, there is a typical problem in the experiment, when adding multiple lines of Chinese comments, recompilation will actually report an error!

For example, using the simplest system.out.println () source code in the above example, we add a few lines of Chinese comment:


When you go to the JDK source directory to compile, you will find a full screen error like this:

Error: Non-mappable character encoding ASCII


It was just a few lines of comment. For us, the source code to write a bit of multi-line Chinese comments is basically necessary, but the compiler error, this can also make people happy to play… I had a chill in my back.

To be honest, I worked on this problem for some time and stayed up very late. Finally, through the following way to solve the problem, by the way to share with friends, if you encounter this problem, you can refer to solve it.

Because from the console error can be clearly seen, must be the character encoding related problems, and all point to the ASCII encoding mode.

So I imported the JDK source from the root directory of Vs Code, and then searched the whole directory for any information about encoding ASCII

The JDK source root directory/make/common/SetupJavaCompilers GMK file two specified ASCII encoding associated:


-encoding (ASCII) -encoding UTF-8


Then execute make Images compilation again and it passes!


And that’s it!

This makes it easy to read, debug, and customize JDK source code.

Postscript: This article is in the open source project: github.com/hansonwang9… Has also been included, including self-taught programming routes, interview questions set/interviews, and a series of technical articles, etc., resources continue to update…

Make a little progress every day

Slower is faster