Duke，Java的吉祥物，也是OpenJDK專案中的一個項目
然而，好景不常，到了2010年甲骨文收購昇陽，同時也接收OpenJDK專案，但是卻又極度冷落這個專案。甚至一直到2018年四月才推出該專案的Windows與MacOS建構，因此若是在這段期間接觸OpenJDK的使用者，便會有OpenJDK什麼都沒有，支援度非常低的錯誤印象。但實際上，這只是Oracle冷落自己的OpenJDK社群，事實上有許多公司與社群使用這些公開的原始碼建立自己的組件，例如曾是最多使用者的AdoptOpenJDK，或是各雲端廠商發布自己的JDK。同時也因為昇陽已開放Java原始碼，因此事實上現在的Oracle Java SE與Oracle OpenJDK都是相同原始碼建構而成的實作參考(Reference Implementation)，只是採用不同的授權而已。
不過在2006年原始碼剛開放之初， Java 7的時期，有些Java程式碼授權是與GPL不相容的，例如，Java Web Start，導致這些不相容的套件不能包含在OpenJDK專案，這可能是江湖謠傳OpenJDK不能取代Java SE的主因。然而山不轉路轉，強大的社群仍實作出這些遺失的額外套件。同時，這些未包含在OpenJDK專案的部分，也逐步從JSR中去除，而不再是Java特性的一部分。如剛才提到的Java Web Start，他有社群製作的IcedTea-Web，能夠完全替代Java Web Start，而Java Web Start也已在Java 11中移除。
那OpenJDK專案缺少了那些套件呢? 分別是Applet Browser Plugin、Java Web Start、JavaFX以及打包於Java SE內的商用授權字型。除了字型之外，這些缺少的特性都已經是Deprecated或Deleted的套件，因此未來再也不會看到這些「不法份子」了。
GPLv2含Classpath Exception與Oracle No-Fee Terms and Conditions
因為OpenJDK專案一開始便是昇陽公開Java SE的原始碼而來，因此與Oracle Java SE之間不存在仿製、侵權、反組譯之類的法律問題，甚至可說是使用相同原始碼來源，以不同授權釋出的建構而已，然而Java使用者要注意不同的授權所相對應的責任問題。Oracle Java SE便採Oracle No-Fee Terms and Conditions商業授權，只允許個人免費使用，若要商業應用便要收費。也因此許多企業紛紛棄用Oracle Java SE，轉向OpenJDK。至於OpenJDK採GPLv2含Classpath Exception，與一般的GPLv2相比，GPLv2含Classpath Exception允許開發者的程式碼靜態與動態連接Java函式庫，而不需要強制遵守GPLv2，這讓許多社群願意使用Java進行開發，例如Apache得以開發許多Java殺手應用，同時以Apache授權釋出。
然而，OpenJDK畢竟是GPLv2為主的授權，就算允許例外，也難保會不會有「誤用」導致所有程式碼全部被GPL污染的狀況，進而被要求公開原始碼。這時小心選用保證不會有汙染，且有賠償的OpenJDK建構便顯得重要。
2019年4月23日，NVD公布編號CVE-2019-2699的Java漏洞，這是一個高達9分的高風險漏洞，達成手法略微複雜，不過一旦成功，便有可能對Java SE與其所有相關套件造成破壞，因此必須要盡快修補。然而這個漏洞的重要性不單只於它本身造成的攻擊，更重要的是時間點。這是Oracle 宣布任何Java SE的商業應用必須收費之後所出現的第一個重大CVE，同時該修補也在第一個收費版本8u212中釋出。因此不願意付費的Java SE使用者企業，只能停留在8u202之前的版本。這對維護資訊安全是極差的決定，最好還是大刀闊斧，轉移到安心可靠，持續維護的OpenJDK還比較安全。
目前Java有兩種版本號碼推進模式，Java 8 之前每一個大版本號碼都是長期支援，相同版號特性會相同，如Java7, Java8，安全更新採整包替換的方式，每季固定推出新的關鍵更新(CPU)，如2022年一月推出的8u321。CPU只更新關鍵組件且有經過完整的回歸功能檢查，因此使用者不需要太多額外回歸測試便可直接替換。Java 9之後版本號碼每半年+1，更新時若沒有注意，可能碰到Java特性變更的問題(如某項功能被Deprecated)，這時就要選擇有LTS的版本，會如同Java 8一樣提供更新，如java 11.0.14，一樣也是採整包替換的方式。
同時，JSR規定不同供應商所提供相同版本號碼(含update小版號)的Java建構特性都必須要一致，基於大家的來源都是OpenJDK專案，甚至不可諱言的原始碼可能有相當程度的重疊，因此出現在Oracle Java SE的漏洞，有可能其他OpenJDK建構也會有，不同供應商所建構的OpenJDK偶而也有自身特有的漏洞，因此供應商是否持續維護是很重要的一個要點。
如果問到使用什麼Java環境，得到的回答是OpenJDK，就好像是問使用什麼作業系統，回答Linux一樣。事實上，Java目前至少有超過8家廠商提供免費的建構，包括Oracle與Azul。既然有這些選擇，為什麼要付費？為什麼不直接部署一個免費OpenJDK就好？使用免費的OpenJDK會有多大風險？
評估一個OpenJDK建構以及其供應商是否可用並不單只做安裝與回歸測試，請多考慮以下幾點：
供應商是否能持續且穩定的提供支援是最重要的首要考量，尤其是GPLv2授權本身即說明了不提供品質保固(見GPLv2 ,章節11, NO WARRANTY)。因此誤用了爹不疼娘不愛的OpenJDK建構，也許部屬階段暫時沒有任何問題，碰到任何異常可是求救無門，而且也可能遇到斷炊，社群不再維護OpenJDK。
其次是Oracle對於Oracle Java SE會每季提供季更新，稱之為“關鍵更新”(CPU, Critical Patch Updates)，同時也讓NVD公開該CPU所修補的CVE漏洞們，因此各廠商維護能力是否有辦法跟上腳步也是一個重要的評鑑要素，例如Oracle自己的OpenJDK就不一定跟上Oracle Java SE的腳步釋出更新。
而提供的OpenJDK是否通過TCK相容測試是技術分析時就應該先檢查的項目，選擇有TCK的建構之後再進行啟動測試與回歸測試。最後，由於目前對於GPL的解釋仍有模糊地帶，因此是否對於授權疑慮有明確解釋或保障，也是評估的要點。
Azul，2002年成立於美國加州，是目前Java供應商中唯一100%專注於Java的公司。Azul的商業授權訂閱確保使用者一定能如期取得經過 JCK 測試的季修補，同時也是唯一提供無授權汙染保證的公司，確保您的智慧財產權不受病毒是授權的汙染。全世界已有數以百萬計的 Java 開發人員、數以億計的設備和世界上最受推崇的企業信任 Azul， 將以卓越的功能、性能、安全性、最經濟實惠的價格和最高等級的支援服務，支持著您的Java應用程式的運行。