好奇害死羊
很多小夥伴們做Java
開發,天天寫Java
代碼,肯定離不開Java
基礎環境:JDK
,畢竟我們寫好的Java
代碼也是跑在JVM
虛擬機上。
一般來說,我們學Java
之前,第一步就是安裝JDK
環境。這個簡單啊,我們一般直接把JDK
從官網下載下來,安裝完成,配個環境變量就可以愉快地使用了。
不過話說回來,對於這個天天使用的東西,我們難道不好奇這玩意兒它到底是怎麼由源碼編譯出來的嗎?
帶着這個原始的疑問,今天準備大幹一場,自己動動呆萌的小手,來編譯一個屬於自己的JDK
吧!
還有個待填的坑
記得之前不是出過一期關於《JDK源碼閱讀環境搭建》相關的視頻以及文章嘛,細心的小夥伴,可能會發現一個很實際的問題:
我們將
src.zip
包裏的JDK
源碼解壓出來,關聯到這份源碼之後,調試時是可以進,但是我們在加註釋的時候卻只能在行尾添加,並不能改變原代碼的行結構。換句話說,如果在源碼中加了跨行的多行註釋,則debug
調試的時候就會出現當前行的運行錯位問題,這個有點尷尬了。
當然那個視頻的評論區,的確也有幾個小夥伴提了這個問題:
原因也很簡單,因爲實際支撐調試運行的代碼,並不是我們解壓出來的那份JDK
源碼,那個僅僅是做關聯用,實際運行用到的JDK
,還是之前系統安裝好的那個JDK
環境。
要想解決這個問題,那就只能使用自己修改過的代碼來自行編譯生成自己的JDK
,然後用到項目中去!
所以什麼都憋說了,肝就完了!
環境準備
首選說在前面的是,編譯前的軟件版本關係極其重要,自己在踩坑時,所出現的各種奇奇怪怪的問題幾乎都和這個有關,後來版本匹配之後,就非常順利了。
我們來盤點和梳理一下編譯一個JDK需要哪些環境和工具:
1、boot JDK
我們要想編譯JDK
,首先自己本機必須提前已經安裝有一個JDK
,官方稱之爲bootstrap JDK
(或者稱爲boot JDK
)。
比如想編譯JDK 8
,那本機必須最起碼得有一個JDK 7
或者更新一點的版本;你想編譯JDK 11
,那就要求本機必須裝有JDK 10
或者11
。
所以雞生蛋、蛋生雞又來了...
2、Unix環境
編譯JDK
需要Unix
環境的支持!
這一點在Linux
操作系統和macOS
操作系統上已經天然的保證了,而對於Windows
兄弟來說稍微麻煩一點,需要通過使用Cygwin
或者MinGW/MSYS
這種軟件來模擬。
就像官方所說:在Linux
平臺編譯JDK
一般問題最少,容易成功;macOS
次之;Windows
上則需要稍微多花點精力,問題可能也多一些。
究其本質原因,還是因爲Windows
畢竟不是一個Unix-Like
內核的系統,畢竟很多軟件的原始編譯都離不開Unix Toolkit
,所以相對肯定要麻煩一些。
3、編譯器/編譯工具鏈
JDK
底層源碼(尤其JVM
虛擬機部分)很多都是C++/C
寫的,所以相關編譯器也跑不掉。
一圖勝千言,各平臺上的編譯器支持如下表所示,按平臺選擇即可:
4、其他工具
典型的比如:
Autoconf
:軟件源碼包的自動配置工具Make
:編譯構建工具freetype
:一個免費的渲染庫,JDK
圖形化部分的代碼可能會用它
好,環境盤點就到這裏,接下來具體列一下我在編譯JDK 8
和JDK 11
時分別用到的軟件詳細版本信息:
編譯JDK 8時:
操作系統
:macOS 10.11.6boot JDK
:JDK 1.8.0 (build 1.8.0_201-b09)Xcode版本
:8.2編譯器
:Version 8.0.0 (at /usr/bin/clang)
編譯JDK 11時:
操作系統
:macOS 10.15.4boot JDK
:JDK 11.0.7 (build 11.0.7+8-LTS)Xcode版本
:11.5編譯器
:Version 11.0.3 (at /usr/bin/clang)
大家在編譯時如果過程中有很多問題,大概率少軟件沒裝,或者軟件版本不匹配,不要輕易放棄,需要耐心自查一下。
下載JDK源碼
下載JDK
源碼其實有兩種方式。
方式一:通過Mercurial工具下載
Mercurial
可以理解爲和Git
一樣,是另外一種代碼管理工具,安裝好之後就有一個hg
命令可用。
而OpenJDK
的源碼已經提前託管到http://hg.openjdk.java.net/
。
因此,比如下載JDK 8
,可直接hg clone
一下就行,和git clone
一樣:
hg clone http://hg.openjdk.java.net/jdk8/jdk8
同理,下載JDK 11
:
hg clone http://hg.openjdk.java.net/jdk/jdk11
但是這種方式下載速度不是很快。
方式二:直接下載打包好的源碼包
下載地址:https://jdk.java.net/
選擇你想要的版本下載即可。
編譯前的自動配置
源碼包下載好,放到本地某個目錄(建議路徑純英文,避免不必要的麻煩),解壓之,然後進入源碼根目錄,執行:
sh configure
當然這裏運行的是默認配置項。
這一步會進行一系列的自動配置工作,時間一般很快,最終如果能出現一下提示,那麼很幸運,編譯前的配置工作就完成了!
這裏我給出我自己分別在配置JDK 11
和JDK 8
時候完成時的樣子:
配置JDK 8完成:
配置JDK 11完成:
注: 如果這一步出錯,大概率是某個軟件環境未裝,或者即使裝了,但版本不匹配,控制檯打印日誌裏一般是會提醒的。
比如我在配置JDK 8
的時候,就遇到了一個errof:GCC compiler is required
的問題:
明明系統裏已經有編譯器,但還是報這個錯誤。通過後來修改 jdk源碼根目錄/common/autoconf/generated-configure.sh
文件,將相關的兩行代碼註釋後就配置通過了
配置完成,接下來開始執行真正的編譯動作了!
真正的編譯動作
我們這裏進行的是全量編譯,直接在我們下載的JDK
源碼根目錄下執行如下命令即可:
make all
這一步編譯需要一點時間,耐心等待一下即可。編譯過程如果有錯誤,會終止編譯,如果能看到如下兩個畫面,那麼則恭喜你,自己編譯JDK
源碼就已經通過了,可以搞一杯咖啡慶祝一下了。
JDK 8編譯完成:
JDK 11編譯完成:
從兩張圖的對比可以看出,編譯JDK 8
和JDK 11
完成時在輸出上還是有區別的。時間上的區別很大程度上來源於JDK 11
的編譯機配置要高不少。
驗證成果
JDK
源碼編譯完成之後肯定會產生和輸出很多產物,這也是我們所迫不及待想看到的。
由於JDK 8
和JDK 11
的源碼包組織結構並不一樣,所以輸出東西的內容和位置也有區別。我們一一來盤點一下。
1、JDK 8的編譯輸出
編譯完成,build
目錄下會生成一個macosx-x86_64-normal-server-release
目錄,所有的編譯成果均位於其中。
首先,編譯出來的Java
可執行程序可以在如下目錄裏找到:
jdk源碼根目錄/build/macosx-x86_64-normal-server-release/jdk/bin
進入該目錄後,可以輸入./java -version
命令驗證:
其次,編譯生成的成品JDK
套裝,可以在目錄
jdk源碼根目錄/build/macosx-x86_64-normal-server-release/images
下找到,如圖所示:
其中:
j2sdk-image
:編譯生成的JDKj2re-image
:編譯生成的JRE
進入j2sdk-image
目錄會發現,裏面的內容和我們平時從網絡上下載的成品JDK
內容一致。
2、JDK 11的編譯輸出
JDK 11的源碼目錄組織方式和JDK 8本身就有區別,編譯生成的產物和上面編譯JDK 8的輸出有一定區別,但也不大。
JDK 11
編譯完成,同樣在build
目錄下會生成一個macosx-x86_64-normal-server-release
目錄,所有的編譯成果均位於其中。
同樣編譯出來的Java可執行程序可以在目錄
JDK源碼根目錄/build/macosx-x86_64-normal-server-release/jdk/bin
下看到,進入該目錄後,也可以輸入./java -version
命令驗證:
其次,編譯生成的成品JDK 11
套裝,可以在目錄
JDK源碼根目錄/build/macosx-x86_64-normal-server-release/images
下找到,如圖所示:
其中jdk
目錄就是編譯生成的成品JDK 11
套裝。
使用自己編譯的JDK
既然我們已經動手編譯出了JDK
成品,接下來我們得用上哇。
新建一個最最基本的Java
工程,比如命名爲JdkTest
,目的是把我們自己編譯出的JDK
給用上。
我們點開Project Structure
,選到SDKs
選項,新添加上自己剛剛編譯生成的JDK,並選爲項目的JDK,看看是否能正常工作
點擊確定之後,我們運行之:
可以看到我們自己編譯出的JDK已經用上了。
關聯JDK源碼並修改
我們繼續在上一步JdkTest
項目的Project Structure
→ SDKs
裏將JDK
源碼關聯到自行下載的JDK源碼路徑上:
這樣方便我們對自己下載的JDK源碼
進行閱讀、調試、修改、以及在源碼裏隨意做筆記和加註釋。
舉個最簡單的例子,比如我們打開System.out.println()
這個函數的底層源碼:
我們隨便給它修改一下,加兩行簡單的標記,像這樣:
爲了使我們新加的代碼行生效,我們必須要重新去JDK源碼的根目錄中再次執行 make images
重新編譯生成JDK方可生效:
因爲之前已經全量編譯過了,所以再次make
的時候增量編譯一般很快。
重新編譯之後,我們再次運行JdkTest
項目,就可以看到改動的效果了:
多行註釋的問題
記得之前搭建《JDK源碼閱讀環境》時,大家可能發現了一個問題:閱讀源碼嘛,給源代碼做點註釋或筆記很常見!但那時候有個問題就是做註釋時不可改變代碼的行結構(只能行尾註釋,不能跨行註釋),否則debug調試時會出現行號錯位的問題。
原因很簡單,因爲我們雖然做了源代碼目錄的映射,但是實際支撐運行的JDK
還是預先安裝好的那個JDK環境,並不是根據我們修改後的源碼來重新編譯構建的,所以看到這裏,解決這個問題就很簡單,就像上面一樣自行編譯一下JDK
即可。
實際在實驗時,還有一個很典型的問題是,當添加了多行的中文註釋後,再編譯居然會報錯!
比如,還是以上面例子中最簡單的System.out.println()
源碼爲例,我們添加幾行中文註釋:
這時候我們去JDK源碼目錄下編譯會發現滿屏類似這樣的報錯:
錯誤: 編碼 ascii 的不可映射字符
頓時有點懵,畢竟僅僅是加了幾行註釋。對於我們來說,源碼裏寫點多行的中文註釋基本是剛需,然而編譯竟會報錯,這還能不能讓人愉快的玩耍了... 當時後背有點發涼。
實不相瞞,就這個問題排查了一段時間,熬到了很晚。最終折騰了一番,通過如下這種方式解決了,順便分享給小夥伴們,大家如果遇到了這個問題,可以參考着解決一下。
因爲從控制檯的報錯可以很明顯的看出,肯定是字符編碼相關的問題導致的,而且都指向了ascii
這種編碼方式。
於是將JDK的源碼從根目錄導入了Vs Code,然後全目錄查找encoding ascii
相關的內容,看看有沒有什麼端倪,結果發現
jdk源碼根目錄/make/common/SetupJavaCompilers.gmk
文件中有兩處指定了ascii
相關的編碼方式:
於是嘗試將這兩處-encoding ascii
的均替換成-encoding utf-8
:
然後再次執行make images
編譯,編譯順利通過!
至此大功告成!
這樣後面不管是閱讀、調試還是定製JDK
源碼都非常方便了。
這次分享就到這裏吧,小夥伴們下篇見!
每天進步一點點
慢一點才能更快