編譯openjdk8
❶ openjdk-8-jdk-headless 什麼版本
OpenJDK8是JDK的開放源碼版本，以GPL（General Public License，通用性公開許可證）協議的形式放出。因為授權協議的原因，Sun公司實現的JDK的一部分源碼因為產權的問題無法開放OpenJDK使用。因此相比於JDK，OpenJDK的源碼只包含了最精簡的JDK。
openjdk是jdk的開放原始碼版本，以GPL協議的形式放出。在JDK7的時候，openjdk已經成為jdk7的主幹開發，sun jdk7是在openjdk7的基礎上發布的，其大部分原始碼都相同。
只有少部分原始碼被替換掉。使用JRL(javaResearch License，Java研究授權協議)發布。
至於openjdk6則更是有其復雜的一面，首先是openjdk6是jdk7的一個分支，並且盡量去除Java SE7的新特性，使其盡量的符合Java6的標准。
(1)編譯openjdk8擴展閱讀：
DK和OpenJDK的區別，可以歸納為以下幾點：
1、授權協議的不同
openjdk採用GPL V2協議放出，而JDK則採用JRL放出。兩者協議雖然都是開放源代碼的，但是在使用上的不同在於GPL V2允許在商業上使用。
而JRL只允許個人研究使用。OpenJDK不包含Deployment（部署）功能。
部署的功能包括：Browser Plugin、Java Web Start、以及Java控制面板，這些功能在Openjdk中是找不到的。
2、OpenJDK源代碼不完整
這個很容易想到，在採用GPL協議的Openjdk中，sun jdk的一部分源代碼因為產權的問題無法開放openjdk使用，其中最主要的部份就是JMX中的可選元件SNMP部份的代碼。
因此這些不能開放的源代碼將它作成plug，以供OpenJDK編譯時使用，你也可以選擇不要使用plug。
而Icedtea則為這些不完整的部分開發了相同功能的源代碼(OpenJDK6)，促使OpenJDK更加完整。
3、部分源代碼用開源代碼替換
由於產權的問題，很多產權不是SUN的源代碼被替換成一些功能相同的開源代碼，比如說字體柵格化引擎，使用Free Type代替。
4、openjdk只包含最精簡的JDK
OpenJDK不包含其他的軟體包，比如Rhino Java DB JAXP……，並且可以分離的軟體包也都是盡量的分離，但是這大多數都是自由軟體，你可以自己下載加入。
5、不能使用Java商標
這個很容易理解，在安裝openjdk的機器上，輸入「java -version」顯示的是openjdk，但是如果是使用Icedtea補丁的openjdk，顯示的是java。（未驗證）
總之，在Java體系中，還是有很多不自由的成分，源代碼的開發不夠徹底，希望Oracle能夠讓JCP更自由開放一些，這也是所有Java社區所希望的。
❷ 編譯openjdk8怎麼解決這兩個問題
rm -f libjvm.so.1; ln -s libjvm.so libjvm.so.1; \
[ -f libjvm.so ] || { ln -s libjvm.so libjvm.so; ln -s libjvm.so.1 libjvm.so.1; }; \
if [ \"\" = \"\" ] ; then \
if [ -x /usr/sbin/selinuxenabled ] ; then \
/usr/sbin/selinuxenabled; \
if [ $? = 0 ] ; then \
/usr/bin/chcon -t textrel_shlib_t libjvm.so; \
if [ $? != 0 ]; then \
echo "ERROR: Cannot chcon libjvm.so"; \
fi \
❸ ubuntu16.04編譯openjdk8需要安裝什麼軟體
請確保你下載的JDK版本與操作系統相對應。 2.轉到你下載路徑，對下載後的文件解壓縮，比如我下載的文件名為jdk-7u7-linux-i586.tar.gz cd xxx(你的下載路徑) sudo tar zxvf jdk-7u7-linux-i586.tar.gz 3.要將解壓縮出來的文件夾拷貝到/usr/lib/j
❹ openjdk和oraclejdk有什麼區別嗎
首先要先明確之間，以及OpenJDK 6、OpenJDK 7、OpenJDK 7u和OpenJDK 8等項目之間是什麼關系，這有助於確定接下來編譯要使用的JDK版本和源碼分支。
從前面介紹的Java發展史中我們了解到OpenJDK是Sun在2006年末把Java開源而形成的項目，這里的「開源」是通常意義上的源碼開放形式，即源碼是可被復用的，例如IcedTea、UltraViolet都是從OpenJDK源碼衍生出的發行版。但如果僅從「開源」字面意義（開放可閱讀的源碼）上看，其實Sun自JDK 1.5之後就開始以Java Research License（JRL）的形式公布過Java源碼，主要用於研究人員閱讀（JRL許可證的開放源碼至JDK 1.6 Update 23為止）。把這些JRL許可證形式的Sun/OracleJDK源碼和對應版本的OpenJDK源碼進行比較，發現除了文件頭的版權注釋之外，其餘代碼基本上都是相同的，只有字體渲染部分存在一點差異，Oracle JDK採用了商業實現，而OpenJDK使用的是開源的FreeType。當然，「相同」是建立在兩者共有的組件基礎上的，Oracle JDK中還會存在一些Open JDK沒有的、商用閉源的功能，例如從JRockit移植改造而來的Java Flight Recorder。預計以後JRockit的MissionControl移植到HotSpot之後，也會以Oracle JDK專有、閉源的形式提供。
Oracle的項目發布經理Joe Darcy在OSCON 2011上對兩者關系的介紹也證實了OpenJDK 7和Oracle JDK 7在程序上是非常接近的，兩者共用了大量相同的代碼（如下圖，注意圖中提示了兩者共同代碼的佔比要遠高於圖形上看到的比例），所以我們編譯的OpenJDK，基本上可以認為性能、功能和執行邏輯上都和官方的Oracle JDK是一致的。
Dalvik 與java虛擬機:
1.java虛擬機基於棧。 基於棧的機器必須使用指令來載入和操作棧上數據，所需指令更多更多 .
而dalvik虛擬機是基於寄存器的：java虛擬機運行的是java位元組碼。
(java類會被編譯成一個或多個位元組碼.class文件，打包到.jar文件中，java虛擬機從相應的.class文件和.jar文件中獲取相應的位元組碼）2.Dalvik和Java之間的另外一大區別就是運行環境——Dalvik經過優化，允許在有限的內存中同時運行多個虛擬機的實例OpenJDK :
[root@localhost ~]# java -version
java version "1.6.0_39"
OpenJDK Runtime Environment (IcedTea6 1.13.11) (rhel-1.13.11.0.el5_11-x86_64)OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)oracle jdk:
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)OpenJDK下載：
http://openjdk.java.net/install/index.htmlJDK 8：yum install java-1.8.0-openjdk
JDK 7：
yum install java-1.7.0-openjdk
JDK 6:yum install java-1.6.0-openjdk
1. HotSpot歷史
SUN的JDK版本從1.3.1開始運用HotSpot虛擬機， 2006年底開源，主要使用C++實現，JNI介面部分用C實現。
HotSpot是較新的Java虛擬機，用來代替JIT(Just in Time)，可以大大提高Java運行的性能。
Java原先是把源代碼編譯為位元組碼在虛擬機執行，這樣執行速度較慢。而HotSpot將常用的部分代碼編譯為本地(原生，native)代碼，這樣顯著提高了性能。
HotSpot JVM 參數可以分為規則參數(standard options)和非規則參數(non-standard options)。
規則參數相對穩定，在JDK未來的版本里不會有太大的改動。
非規則參數則有因升級JDK而改動的可能。
規則和非規則參數這里不做介紹了，網上資料很多。
2.HotSpot基礎知識
HotSpot包括一個解釋器和兩個編譯器（client 和 server，二選一的），解釋與編譯混合執行模式，默認啟動解釋執行。
編譯器：java源代碼被編譯器編譯成class文件（位元組碼），java位元組碼在運行時可以被動態編譯（JIT）成本地代碼(前提是解釋與編譯混合執行模式且虛擬機不是剛啟動時)。
解釋器： 解釋器用來解釋class文件（位元組碼），java是解釋語言（書上這么說的）。
server啟動慢，佔用內存多，執行效率高，適用於伺服器端應用；client啟動快，佔用內存小，執行效率沒有server快，默認情況下不進行動態編譯，適用於桌面應用程序。
由-XX:+RewriteFrequentPairs參數控制 client模式默認關閉，server模式默認開啟在jre安裝目錄下的lib/i386/jvm.cfg 文件下。
java -version
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)mixed mode 解釋與編譯 混合的執行模式 默認使用這種模式java -Xint -version
Java HotSpot(TM) Client VM (build 14.3-b01, interpreted mode, sharing)interpreted 純解釋模式 禁用JIT編譯
java -Xcomp -version
Java HotSpot(TM) Client VM (build 14.3-b01, compiled mode, sharing)compiled 純編譯模式（如果方法無法編譯，則回退到解釋模式執行無法編譯的方法）3.動態編譯
動態編譯(compile ring run-time)，英文稱Dynamic compilation；Just In Time也是這個意思。
HotSpot對bytecode的編譯不是在程序運行前編譯的，而是在程序運行過程中編譯的。
HotSpot里運行著一個監視器（Profile Monitor），用來監視程序的運行狀況。
java位元組碼（class文件）是以解釋的方式被載入到虛擬機中(默認啟動時解釋執行)。 程序運行過程中，那一部分運用頻率大，那些對程序的性能影響重要。對程序運行效率影響大的代碼，稱為熱點（hotspot），HotSpot會把這些熱點動態地編譯成機器碼（native code），同時對機器碼進行優化，從而提高運行效率。對那些較少運行的代碼，HotSpot就不會把他們編譯。
HotSpot對位元組碼有三層處理：不編譯(位元組碼載入到虛擬機中時的狀態。也就是當虛擬機執行的時候再編譯)，編譯(把位元組碼編譯成本地代碼。虛擬機執行的時候已經編譯好了，不要再編譯了)，編譯並優化（不但把位元組碼編譯成本地代碼，而且還進行了優化）。
至於那些程序那些不編譯，那些編譯，那些優化，則是由監視器（Profile Monitor）決定。
4.為什麼不靜態編譯那？
為什麼位元組碼在裝載到虛擬機之前就編譯成本地代碼那？
動態編譯器也在許多方面比靜態編譯器優越。靜態編譯器通常很難准確預知程序運行過程中究竟什麼部分最需要優化。
函數調用都是很浪費系統時間的，因為有許多進棧出棧操作。因此有一種優化辦法，就是把原來的函數調用，通過編譯器的編譯，改成非函數調用，把函數代碼直接嵌到調用出，變成順序執行。
面向對象的語言支持多態，靜態編譯無效確定程序調用哪個方法，因為多態是在程序運行中確定調用哪個方法。
jdk 1.9 等價JDK9 J2SE9 JAVA9
jdk 1.8 等價JDK8 J2SE8 JAVA8
jdk 1.7 等價JDK7 J2SE7 JAVA7
jdk 1.6 等價JDK6 J2SE6 JAVA6
jdk 1.5 等價JDK5 J2SE5 JAVA5
jdk 1.4 等價J2SE1.4
jdk 1.3 等價J2SE1.3
jdk 1.2 等價J2SE1.2
jdk 1.1
openjdk源碼下載：
Oracle JDK只發布二進制安裝包，而OpenJDK只發布源碼復制代碼
獲取OpenJDK源碼有兩種方式：
第一種方式：
下載OpenJDK7u的源代碼：
hg clone http://hg.openjdk.java.net/jdk7u/jdk7u-devcd jdk7u-dev
chmod 755 get_source.sh
./get_source.sh
下載OpenJDK8u的源代碼：
hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-devcd jdk8u-dev
./get_source.sh
注意：這是最直接的方式，從版本管理中看變更軌跡比看Release Note效果更好。但不足之處是速度太慢，雖然代碼總容量只有300 MB左右，但是文件數量太多，在筆者的網路下全部復制到本地需要數小時。
第二種方式，即直接下載官方打包好的源碼包
讀者可以從Source Bundle Releases頁面（地址：http://jdk7.java.net/source.html）取得打包好的源碼，到本地直接解壓即可。
一般來說，源碼包大概一至兩個月左右會更新一次，雖然不夠及時，但比起從Mercurial復制代碼的確方便和快捷許多。
筆者下載的是OpenJDK 7 Update 6 Build b21版源碼包，2012年8月28日發布，大概99MB，解壓後約為339MB。
備註：推薦在linux平台或者mac平台上面編譯jdk
❺ 自己可以編譯安卓源碼嗎
用最新的Ubuntu 16.04,請首先確保自己已經安裝了Git.沒安裝的同學可以通過以下命令進行安裝:
sudo apt-get install git git config –global user.email 「[email protected]」 git config –global user.name 「test」
其中[email protected]為你自己的郵箱.
簡要說明
android源碼編譯的四個流程:1.源碼下載;2.構建編譯環境;3.編譯源碼;4運行.下文也將按照該流程講述.
源碼下載
由於某牆的原因,這里我們採用國內的鏡像源進行下載.
目前,可用的鏡像源一般是科大和清華的,具體使用差不多,這里我選擇清華大學鏡像進行說明.(參考:科大源,清華源)
repo工具下載及安裝
通過執行以下命令實現repo工具的下載和安裝
mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo
補充說明
這里,我來簡單的介紹下repo工具,我們知道AOSP項目由不同的子項目組成,為了方便進行管理,Google採用Git對AOSP項目進行多倉庫管理.在聊repo工具之前,我先帶你來聊聊多倉庫項目:
我們有個非常龐大的項目Pre,該項目由很多個子項目R1,R2,...Rn等組成,為了方便管理和協同開發,我們為每個子項目創立自己的倉庫,整個項目的結構如下:
這里寫圖片描述
執行完該命令後,再使用make命令繼續編譯.某些情況下,當你執行jack-admin kill-server時可能提示你命令不存在,此時去你去out/host/linux-x86/bin/目錄下會發現不存在jack-admin文件.如果我是你,我就會重新repo sync下,然後從頭來過.
錯誤三:使用emulator時,虛擬機停在黑屏界面,點擊無任何響應.此時,可能是kerner內核問題,解決方法如下:
執行如下命令:
通過使用kernel-qemu-armv7內核 解決模擬器等待黑屏問題.而-partition-size 1024 則是解決警告: system partion siez adjusted to match image file (163 MB >66 MB)
如果你一開始編譯的版本是aosp_arm-eng,使用上述命令仍然不能解決等待黑屏問題時,不妨編譯aosp_arm64-eng試試.
結束吧
到現在為止,你已經了解了整個android編譯的流程.除此之外,我也簡單的說明android源碼的多倉庫管理機制.下面,不妨自己動手嘗試一下.
❻ 聽說openjdk的性能很爛，是真的嗎
首先要先明確OpenJDK和Sun/OracleJDK之間，以及OpenJDK 6、OpenJDK 7、OpenJDK 7u和OpenJDK 8等項目之間是什麼關系，這有助於確定接下來編譯要使用的JDK版本和源碼分支。
❼ 運行環境是openjdk 1.8，我可以用oracle jdk 1.8開發嗎
用jdbc么
oracle8/8i/9i資料庫（thin模式）
載入驅動：
class.forname("oracle.jdbc.driver.oracledriver").newinstance();
設置參數
string
url="jdbc:oracle:thin:@localhost:1521:orcl";
//orcl為資料庫的sid
string
user="test";
string
password="test";
嘗試連接：
connection
conn=
drivermanager.getconnection(url,user,password);
❽ 如何交叉編譯openjdk 使之能在arm-Linux中運行
直接下載OpenJDK8源碼肯定不通過。有一個專門的移植工程：
hg clone http://hg.openjdk.java.net/aarch64-port/jdk8/
hg clone http://hg.openjdk.java.net/aarch64-port/jdk8u/
這個有時無法下載，使用：
https://github.com/AdoptOpenJDK/openjdk-aarch64-jdk8u
關於OpenJDK的編譯，這個博客記錄最為詳細，所有問題都有解決辦法：
網頁鏈接
❾ 如何用jdk8編譯出能在jre7上跑的軟體，我直接編譯的放了openjdk7上不能跑。
只有兩種方式
一，降低jdk的版本
二，將jdk8中特殊的用法刪除