無支援Java 的暗藏風險

自從 Oracle 要求使用者必須訂閱以獲得 Java 8 及 Java 11（也就是目前最常用的兩個版本）支援的授權以來，已經過了兩年。在這兩年的調整過程中，有些企業的 Java 是由 Oracle 或其它廠商支援，有些企業則採用免費版本的 Java。如今企業對不受支援的 OpenJDK 版本、昂貴原廠 Oracle 版本， 或其他廠商的OpenJDK 版本都已經有些許經驗，因此企業也應當了解無支援 OpenJDK 所存在的風險。

在本篇白皮書中，會討論到：

• 免費版本 Java 很吸引人，這是理所當然的
• 無支援 OpenJDK 所存在的風險，可能會重創公司
• 如何選擇最好的 Java 支援
• Azul 如何量身貼合各種企業需求

免費的Java 真的很吸引人

誰不喜歡免費的東西？這完全是人之常情。我們都樂得坐享其成，尤其當我們已經習慣使用免費版本多年。自從 Oracle 引進訂閱制度，開始要求企業為商用 Java 支付授權費後，全球公司都不得不做出以下選擇：

1. 為了維持現狀，支付高昂的Oracle 授權費。

2. 使用其它廠商的 OpenJDK 並訂閱其支援服務。

3. 使用免費的 OpenJDK，從開源社群下載更新及修正檔，但無法獲得任何支援。在您決定採取省事的對策，繼續或轉向使用免費版本之前，請您務必慎重衡量預期利益及風險成本。免費版本最直接的好處就是不需要花錢，但其中暗藏的非預期成本卻可能非常高昂。

無支援 OpenJDK 的風險

免費、但沒有支援的 OpenJDK 的風險，與以下幾點有關：

• 安全性
• 合規性
• 智慧財產權問題

當然，這些問題都將影響營運，最終衝擊到公司本身。

那麼，您能承擔多少以下風險呢 ?

您在徹底理解這些風險後，才能確實評估免費的 OpenJDK 會給公司帶來什麼影響。我們來談談關於沒有支援的 OpenJDK 所暗藏的四大風險，以及如何減輕這些風險。

風險 #1 有軟體一樣，免費的 OpenJDK 也存在程式漏洞

OpenJDK 平台迄今已包含超過 800 萬行的複雜程式碼。隨著平台持續快速發展，新程式碼帶來許多新穎功能的程式版本。但由於新程式碼是由人編寫，而人無論如何都會犯錯，因此平台總會有新錯誤出現。

每版 Java 都會出現新的安全問題

最為重要且影響資安的程式漏洞，會在CVE（通用漏洞揭露計畫）被指出。CVE是一系列免費公開的協作列表，收集各種資安弱點及漏洞並給予編號，以便任何人查詢。CVE 上每個已識別的漏洞，都有通用漏洞評分系統（CVSS）分數，以0-10的等級評定嚴重性。評分為0 則表示沒有風險。

人們能直覺看出分數越高，風險越大，但實際上的風險程度則是呈指數上升—就像芮氏地震規模一樣。7-8.9 分表示高風險漏洞，9 分或 10 分表示重大漏洞。這份資安漏洞風險評分的協作列表，可幫助資訊部門、資訊安全長、安全團隊和開發維運團隊，來決定資安工作優先順序與修復軟體漏洞的對策。雖然這些評分如同地震量級，可以指出問題的嚴重性，但我們也必須仔細探討攻擊的來源，才能真正理解軟體系統受到影響的方式。

整體而言，攻擊來源才是威脅公司資安的主因，也是決定公司如何應對的關鍵。循著如此脈絡，讓我們回顧一下 Java 近期的開發史，特別是 Java 8，該版本至今在所有 Java 應用中仍佔有大部分。

看看下表，您注意到什麼了嗎？

幾乎每個版本都有錯誤，高風險及重大風險漏洞總是層出不窮。

一旦有高風險與重大漏洞被公諸於世，這些漏洞立刻就會成為駭客手中的利刃。這種情況發生時，您的營運將會面臨諸多問題：服務中斷、交易失敗、以及資料外洩，都還只是冰山一角而已。

若您無法及時取得 Java 安全修正檔來修復漏洞的話，會發生甚麼事？

如果沒有及時更新，您的企業就會暴露在生機蓬勃的無國界駭客社群眼前。駭客們會迅速地利用高風險漏洞，畢竟他們有如此能力，也有相當的動機。您的營運團隊是否能亡羊補牢，及時防止更多損失?

OpenJDK 季度更新需要大量測試以確保安全性

OpenJDK 免費的版本，都只提供修正包更新(Patch Set Update，PSU) 的二進制檔案。修正包更新版的版本會包含最新的安全更新，相當方便。然而裡面也包含OpenJDK 社群在過去 90 天內新增的所有內容。這包括:

• 新功能
• ( 不影響安全性的) 非關鍵錯誤修復

隨著功能的增加，您需要確保每個新的PSU 二進制檔案都不會破壞您應用程式的穩定性。且為了確保應用程式正常運作，各個 PSU 版本都需要經過完整回歸測試。

不過您有另一種選擇是僅限安全性季度更新， 又稱為重大修正檔更新（CriticalPatch Update，CPU）。與 PSU 一樣，重大 修 正 檔 會 在1 月、4 月、7 月和10 月最接近 17 號的星期二發表。

這些重要更新包含最近的安全性或 CVE 更新，也會加入上一季 PSU 的功能和修復。此版本至此終於可被視為穩定版。

幸運的是，他們 (CPU) 是為了快速佈署而設計的。這意味著使用重大修正檔，您的營運團隊可以快速地解決安全問題，並擁有完全信心能進行佈署，以確保穩定性並降低運營風險。然而，僅少數 OpenJDK廠商發行僅限安全性更新（Security OnlyUpdates），這些更新也無法免費取得――因此，真正穩定的版本，依然只能透過訂閱制取得。

此外，在安全修正檔準備好之前，會有段危險的時間差。若使用無支援OpenJDK，公司必須密切注意時間差：從漏洞被公布（讓駭客知道漏洞在哪），到 OpenJDK 免費的修正檔公開前，有段危險的空窗期。這段時期將延續數日，在某些情況下甚至可能需要幾週時間。

請留意， 此危險期每季度都會發生一次。使用免費、未受支援或支援不佳的OpenJDK 版本，您的系統可能會在每個季度面臨數天（甚至數週）的風險。這些都增加了不斷重複發生且不可預測的風險。

在每季度重複發生的危險時間差中，任何災難都可能發生。企業的軟體漏洞暴露在光天化日下，不懷好意的駭客則日夜嘗試突破防線，而營運團隊只能深呼吸，祈求這季的受害者不會是自己……這一切真的值得冒險嗎？

僅限安全性更新檔有多重要?

2020 年7 月季度更新修正包 (PSU)，包含一個重大的回溯， 據推測是一個「修復」。在未經測試的情況下，原本的更新破壞了許多常見的應用程式，例如 Apache Hadoop clusters、 ApacheLucene 和 Apache Solr 等。

然而穩定安全性更新檔，因為不包含這個「修復」而免於受難。於是在超過兩週的時間中，這些無法使用穩定安全性更新檔的 OpenJDK 免費版本使用者們都不得不在安全性和穩定性之間做出決擇。於此期間，許多關鍵的任務系統都被迫減低性能，以降低系統風險。

風險 #2 支援的 OpenJDK 版本無法保衛您的智慧財產

要理解未受支援的 OpenJDK 為何無法保衛您的智慧財產，則需要先理解開源軟體和閉源軟體之間的授權區別。

概述如下：

1. OpenJDK 的授權，是基於一系列的開源授權：

• GPLv2 適用於大部分Java 虛擬機(JVM)。
• GPLv2 加上Classpath Exception(CPE)適用於部分的 Java 開發套件(JDK) 與部分的虛擬機。CPE 使得 class 路徑或模組路徑可不受 GPLv2 著作權感染特性的影響。
• 其他適用JDK 的開源授權(Apache2.0、LGPL、MIT、BSD 等)。

2. Oracle Java SE (Hotspot)， 也就是Oracle JDK，等同於Oracle 提供閉源版OpenJDK。

3. OpenJDK 社群的技術相容測試工具(TCK) 並非開源。相反地， 它是根據OpenJDK 開源社群TCK 授權條款(OCTLA) 授權給基於 OpenJDK 之Java SE 應用。迄今為止，只有 3 家公司簽署了 Java 版本 7、8 和 9+ ( 包括11 和 17) 的授權條款。

考慮到這點，當軟體的首版最初在通用公共授權條款(GPL) 之下發佈時，它會被認定是開源發佈的。當其他人修改該版本並釋出時，此舉將被視為重新開源發佈。從授權的角度來看，「重新開源發佈」和 「發佈」之間沒有區別，都只是重複 「發佈」而已。

因此，重新發佈 OpenJDK 時，也必須維持先前版本中原始程式碼所提供的服務。更具體地說，GPLv2 第三款中，針對來源程式碼訂立指引，也明確定義重新發佈任何 GPLv2 二進制檔案的責任。重新發佈者必須支援原始程式碼 3 年以上。

對於軟體廠商( 例如軟體開發公司)、 代工廠商，或任何公司而言，只要有使用免費OpenJDK 版本並重新發佈 Java 應用程式，就可能會違反 GPLv2 的要求。若您運氣夠好，您只會收到停終信函。運氣差的話，您可能需要公開您的應用程式，這意味著您可能必須停止銷售它們，也代表著重大的法律風險和成本、 營運中止，和鉅額的收入損失。

什麼是 Copyleft ?

Copyleft 保障使用者可以有權自由發佈、修改他人作品。而被修改、發佈後的作品，也必須允許其他人保有相同的權利。

永遠對軟體授權保持警戒

2021 年3 月，一名軟體函式庫的維護者，給了正在從該函式庫中結合程式碼的另一個 Ruby 函式庫的維護者晴天霹靂的壞消息：後者的發佈是在無法兼容的軟體授權下進行的。

第一個函式庫雖在 GPLv2 下獲得授權，但第二個函式庫被錯誤地列在 MIT 授權條款下的計畫。這個授權錯誤因而迫使第二個函式庫必須停止發佈某些版本。這原本是一個完全可以預防的授權錯誤，卻影響了數十萬個專案。

開源授權污染的風險非常迫切

一旦授權被污染，將強制要求您自家開發的應用程式智慧財產權必須完全開源，或迫使您從其他第三方購買昂貴的軟體授權。

下圖比較兩個應用程式在 Java 虛擬機內串API 運作時，OpenJDK 的實際情況。

如果不仔細驗證 OpenJDK 每個版本中，每個模組的每一段代碼，則可能存在危及您智慧財產(IP) 的風險。沒有擔保條款，您就無法管理這種風險。

此外，若使用未繼承完整 Java 智慧財產權的 OpenJDK 程式碼所發布的JDK 二進制檔案， 並試圖通過 Oracle 授權的OpenJDK 技術相容測試工具(TCK) 測試時，會有法律上的風險。很不幸的是，並非每個免費的OpenJDK 二進制檔案，完整擁有這些智慧財產權。

有些 OpenJDK 版本甚至完全無法使用TCK。

什麼是擔保條款?

擔保條款會保護您應用程式中相關的智慧財產。這意味著您的組織使用特定OpenJDK 版本是有經正式認證以及驗證的。它確保您的應用程式或產品，在：

1. 程式引用 (include)

2. 嵌入 (embed) 和 / 或

3. 發佈

您的應用程式或產品中所使用的 OpenJDK，不會汙染應用程式的智慧財產或程式碼，造成授權要求( 包括但不限於 GPLv2 中的來源程式碼與公開要求 )。

而即使發布者遵守授權並嘗試通過 TCK，TCK 也不一定用在每個二進制的版本。因此不只是 Oracle，任何 Java 專利持有人都有權對未通過 TCK 測試的版本發起訴訟。任何 Java 專利持有者，都可能是專利流氓。

因此，當您評估無支援 Java 的好處和風險時， 或許該捫心自問：

• 在您開發的應用程式中，是否有嵌入或重新發佈且未經驗證的二進制檔案，而這些二進制檔案是否有智慧財產權的訴訟風險?
• 您的公司能否負擔法律訴訟?
• 您能否接受客戶強烈反對那些重新發佈、不受智慧財產權保護的二進制檔案?

風險 #3合規問題可能會導致昂貴的法律費用、 罰款、品牌損害和收入損失

在營運關鍵軟體上運行沒有明確定義支援服務的 OpenJDK 版本，絕非明智的商業決定。當您的業務依賴 OpenJDK 風險就會更高，例如您的產品是基於 Java 服務推出 SaaS 產品，而當您的客戶和監管機構可能檢視生產環境應用程式內容時。

一旦客戶或監管機構發現您生產環境的應用程式使用未受支援或不安全的軟體，您可能就會遭遇嚴重後果，而免費OpenJDK 版本往往隱含諸多如此狀況。這將無可避免導致合規問題，而業界重量級認證機構也可能宣告您的產品不符合軟體安全標準。

此外，您還會觸犯法令要求。若您是一家需要定期稽核的公開上市公司，還會必須面對監管機構和政府的天打雷劈。

最後，無論您的公司是否公開上市，您都必須面對自己的客戶。若無法證明產品符合業界標準，您只會失去現有與未來的所有客戶。

為了保持合規性應用程式需要穩定與及時的安全更新

因此，為了遵守一切規定，您面對客戶、創造收入、重要業務的 Java 應用程式， 必須由營運團隊謹慎管理，而這意味著所有運行區的元件，都必須確保具備妥善的服務支援架構。

這些支援架構通常著重於系統穩定性和安全性。

實務而言，這將需要及時存取以達到幾乎即時完成部署的漏洞修復與安全更新。這也需要週期外程式錯誤的修正檔，全年無休地終保護著您的系統，甚至包括週末和假日。

確保支援以維護系統穩定性和安全性，是您確保合規性的唯一途徑。

某些產業的合規性負擔更重

某些產業尤其如此，特別是您的公司須遵守 PCI DSS 等嚴格標準的場合。

舉例來說，PCI 在支援契約的一部分條文中明確要求安全修正檔發佈後的 30 天內進行軟體更新。若未能這麼做，PCI DSS的合規性就會受到影響。正如最近許多新聞報導所證實，電力與公用事業是全球駭客大規模、公然、頻繁展開攻擊的目標。

因此，美國的北美電力可靠公司(NERC)的合規標準就要求大容量電力系統(BES)實施嚴格的安全管控。這項重要標準要求明確的服務等級協議(SLAs)，以確保能抵禦潛在網路攻擊。

在醫療保健領域，公司必須遵守健康保險流通與責任法案(HIPAA) 的安全規定。雖然該規則未解釋漏洞修復的問題，但它確實要求已識別的軟體漏洞必須符合 HIPAA管理保障和安全管理流程之標準。

在評估未使用無支援 OpenJDK 版本風險時，請先想想：

• 哪些法規命令給營運團隊帶來壓力 ?
• 您是否已經為所有重要軟體提供有效的支援契約 ?
• 您是否能承受為了處理原本可預防的安全性或產品問題，而需要數小時或數天的停機，以及公司聲譽的損害，而僅僅只是因為沒有更新最新版 Java?
• 您真的能夠承受免費和未受支援的應用程式，對您資安狀況、合規性、聲譽和財務產生的潛在影響嗎?
• 您公司所處的產業，是否經常遭到駭客攻擊 ?

風險 #4 若您認為免費、無支援 OpenJDK 就夠了

在過去，Sun Microsystems 和 Oracle 主導了所有 OpenJDK 項目， 並維護 Java6、7、8 和 11 等長期支援(LTS) 版本，直接為它們不斷提供修復，使用者無需付費訂閱即可獲得這些成果。不幸的是，那些美好時光一去不復返。Sun Microsystems的利他精神和開源承諾， 已經讓位給Oracle 的商業目標。

在公開場合，Oracle 目前的重心是支援和維護「前沿」OpenJDK 的開發。Oracle的確有對 Oracle Java 版本( 例如 7、8 和11) 進行了向後移植，但您必須進行昂貴的訂閱才能使用這些版本。

而 OpenJDK 社群主持其他 OpenJDK 版本的向後移植工程，但這些工程需要時間和資源。因此，常見的長期支援(LTS) 版本，例如 8 和 11，在向後移植的不足之處會出現風險，這些向後移植程式碼的完整性和品質都已埋下隱憂。

無支援 OpenJDK 無法保證及時提供更新版安全二進制檔案

使用無支援 OpenJDK 無法保證能及時取得更新後的安全二進制檔案，也不能保護資訊基礎設施免受 OpenJDK 社群不作為或作為不全而引起的軟體回溯。無論是Oracle 導致的軟體回溯，或是社群貢獻者的程式碼錯誤，若營運團隊此時沒有週期外修正檔的快速支援，將會使公司營運的關鍵軟體暴露於停機的風險。

例如，在一次 2018 年的 Java 更新導致Cassandra 的伺服器無法啟動。在此案例中，許多營運團隊無法退回先前的更新檔，因為這次的更新檔包含重大安全風險修復。在過去，開發團隊可以在所有受支援的版本上開發，因為 Sun Microsystems 和 Oracle 會維護 Java 8、7、6 等任何長期支援版本。

時代已經不一樣了。Sun Microsystems 和Oracle 過去無償提供的事物，現在需要訂閱繳費才能獲得。此外，跟之前相比，使用未受支援的 OpenJDK 中的許多 Java 應用程式中暴露出比以往更大量的問題。

儘管 Oracle 繼續為受支援的版本提供全面的安全保證，它的成本非常高昂。能快速獲取週期外修正檔，對關鍵的應用程式部署來說，顯得格外重要。

不訂閱支援將為您的事業帶來風險

雖然一些開源專案僅透過貢獻者就取得成功， 但 Java 過去的成功是由 Sun Microsystems 及 Oracle 先後的金錢挹注所建立。而 OpenJDK 利用了這些舊資產、以及社群力量中逐漸成長。但僅管這是個活躍的社群，它已不再得到大型、專門贊助商的支持。

這導致了 OpenJDK 面臨以下現狀:

1. 只有 Oracle，Java 過去的管理者， 只為Java 最新版本提供錯誤修復和安全更新。

2. 接著，OpenJDK 社群將 Oracle 的更新版本，向後移植到大多數公司使用的Java 版本( 例如 Java 11 和 8)。

3. 這增加了向後移植的不確定性。大多數由志願貢獻者組成的免費 OpenJDK 社群，必須完成這種串聯的複雜反向移植工作( 例如，11 → 8 → 7 → 6 等)。

即使是對於Java 龐大而敬業的貢獻者社群來說，及時修復已公開的程式錯誤，也是一項艱鉅的挑戰。讓我們看看下面這個例子。

在2019 年10 月的更新中，Oracle 修復了 19 個錯誤，並將它們向後移植到 OracleJava SE 8。但 OpenJDK 專案缺少在安全發佈日前完成向後移植的資源，這意味著他們不得不將此項工作推遲到之後的季度發佈。當這種情況發生時，我們又會遭遇前述的危險時間差。

企業需要關注安全性，因此也必須進一步關注Oracle JDK 兼容性。結論就是：企業使用與Oracle 保持同步的 OpenJDK 非常重要。

Oracle 是一家資源豐富的公司，在確保安全性和穩定性方面表現優異。麻煩的是，他們的支援服務成本太高了。現在您已經了解免費、無支援 Java 的風險，也已經考慮過您的 IT 團隊和整個企業會遭遇上述哪些問題，我們來探討如何減少風險吧！

使用正確的 Java OpenJDK 和支援訂閱來降低風險

如果您的公司有使用或仰賴 Java 的應用程式，那麼訂閱 OpenJDK 支援授權可能是一項很棒的投資。

有些人認為訂閱支援就像購買保險避險，有些人則認為訂閱支援是種諮詢服務，可以節省開發時間與應用程式團隊的時間。而還有些人認為，訂閱支援則會帶來智慧財產權和運營的保障。

無論是出於何種原因，您都必須對最適合您的 OpenJDK 支援授權做出明智抉擇。

為了獲得全面的支援並高枕無憂，您選擇Java 合作夥伴時請記得以下幾點:

1.您的OpenJDK 年度訂閱應隨附服務級別協議 (SLAs) 。季度更新或隨機安全修正檔是不夠的。一旦安全漏洞被發佈，您的合作夥伴應盡快提供安全修復，而週期外的修復也是不可少的。

2.為生產環境加速安全更新至關重要。將穩定的版本快速部署到您的生產環境中相當關鍵。此外，您的 OpenJDK合作夥伴應該擁有證明他們提供安全性和穩定性的成功記錄。

3.您的OpenJDK 訂閱不應造成財務、知識產權和法律風險。這是沒有商量餘地的。您OpenJDK 合作夥伴的二進制檔案應已透過 Oracle 許可的OpenJDK 社群技術相容測試工具以驗證符合 Java SE 規範。您的合作夥伴還需要至少已簽署 Java 8 和9+ ( 最好還有7) 的 OCTLA 協議，並保證 Java 類別及 API 不受污染。

4.您的 Java 支援合作夥伴應該要能夠支援您的全體 Java 資產，無論操作系統或何種版本，無論是在本地、虛擬機、還是雲端。這意味著他們必須對Java 有長期深入的了解，並且不僅專注於一個特定的 Linux 平台或單個雲端操作系統。他們必須具備各種技能來支援您公司獨有的 Java 需求。

最重要的是，一旦您有需要，您的夥伴應隨時提供服務。您應該能輕鬆聯繫您的支援團隊，無論是在週末和國定假日，或者您身在哪個時區。畢竟，只有在對方達成即時回應的要求時，您才能真正依賴這位Java 合作夥伴的經驗、奉獻精神、持續性和專業知識。

並非所有 Java 支援都有高品質

有些公司只單純的提供支援，但Azul 長期貢獻於 Java 社群，多年來，Azul 一直致力於 Java 生態系統和 OpenJDK 社群的茁壯，以發展和改進生產用的 Java。

我們對以下身分感到無比自豪:

• OpenJDK 專案主要貢獻者
• OpenJDK 漏洞小組成員( 此 28 人小組來自 13 家公司，其中就有 4 名是Azul 員工)，確保發佈重大安全更新
• Java 專家小組成員 (Java ExpertsGroup)， 決定9 項 Java SE (JDK9-17) 功能
• Java 使用者組別 (Java User Group)參與者，其中2 名 Azul 員工擔任組長，7 名 Azul 員工積極參與
• 自 2011 年以來一直是 Java 社群進步(Java Community Process，JCP) 成員，推動 Java 的未來發展
• Azul 旗下工程師還領導了OpenJDK7、13 和 15( 支援 Apple silicon 處理器) 的專案，遠勝任何其他公司。此外，Azul 團隊成員在OpenJDK 社群平台 foojay.io 上也十分活躍

這個平台是OpenJDK 之友 (friends ofOpenJDK) 的簡稱，是一個以使用者為中心的 Java 和 OpenJDK 技術儀表板網站。Azul 與其他人一起參與平台的顧問委員會。

Azul 在推動及支援關鍵應用程式部署方面，有著悠久而強大的記錄。

Azul 的創辦人對Java 的參與可以追溯到1990 年代中期及 Java 的草創期。

自從啟動 Azul 推動Java 企業版發展以來，達成了許多創新，包括:

• 不間斷垃圾回收器 (C4)
• Java 虛擬化
• 彈性記憶體
• 多種受管理的運行與系統堆疊技術
• 將 Mission Control、TLS1.3 和其他安全協定向後移植至 OpenJDK 8
• 支援 Apple M1 處理器OpenJDK 版本

這些創新的結合，為 Java 平台的擴展性和牢固性提供堅韌基礎。

有了 Azul Platform Core您再也不需要為安全性而犧牲價值

市面上 Java 的僅限安全性更新及穩定版本 (CPU) 只有兩種選擇: Oracle 或 Azul。而且只有 Azul 為開源的 OpenJDK提供服務。

使用 Oracle 的版本，企業可以獲得極高的安全性，但很貴，非常貴，非常非常貴。然而，透過與 Azul 合作，各家公司可以獲得安全、穩定的 OpenJDK 發佈記錄，並且直接命中客戶的心—不需要昂貴的費用。此外，提供僅限安全性版本(CPU) 可用於立即部署，且提供嚴格的服務級別協議(SLAs) 支援。

Azul 在推動及支援關鍵應用程式部署方面有著悠久而強大的記錄

此外，訂閱 Azul 後，您的智慧財產權與順暢 IT 營運將獲得保障。您可以盡情放心使用 Azul Platform Core 提供的版本：

• 通過Oracle 授權的OpenJDK TCK，符合 Java SE 規範，這是個包含超過12 萬個單元測試的測試套件
• 通過Java 規範參與 JSP 協定所定義之TCK，以享有額外的智慧財產權
• 在可兼容與規格兼容軟體的安裝上，提供延伸性的智慧財產權
• 獲得 Azul 執行的授權無污染認證此正規過程，是為了驗證和保證與可存取特定二進制檔案的 API 連結時，不會導致產品的智慧財產權被污染。Azul 如何確保無污染?

1. 驗證每個二進制套件的過程中，Azul 會對每個組建檔案進行詳細分析。

2. 此分析將追蹤並識別所有二進制檔案及物件所使用的程式連結，以追蹤可能使用 Azul Platform Core 二進制套件的物件。

3. 使用特別的原始碼識別二進制檔案及物件中連結的項目，同時智財權和授權也會被識別和分類。

4. 分析程式碼各個部分及其個別授權的詳細關係。

Azul 有著全球最強大的Java 虛擬機團隊

根據國際數據資訊有限公司(IDC) 統計，全球有超過 900 萬名程式開發人員，而其中 69% 的人員使用 Java，其它程式語言的使用人數完全無法比擬。

才華洋溢的眾多開發人員在激烈競爭下，每年會有30 位 Java 頂尖開發人員脫穎而出。 Azul 很榮幸有四名員工獲得 Java 頂尖開發人員的殊榮，他們也長期直接與客戶和 Java 社群各界通力合作。當您訂閱Azul Platform Core 時，您的公司可隨時聯絡業界最優秀的 Java 專家， 而他們對Java 虛擬機、記憶體管理、Java 性能問題和生產環境應用程式的可視化工具運用都有深入了解。

Azul 已經做好萬全準備，隨時能為您解決最棘手的問題。

Azul 的獨立就是您的獨立

作為全球唯一專注於 Java 而獨樹一格的獨立軟體開發商(ISV)、操作系統，供應商和雲端服務供應商，Azul 只有專一的業務。Azul 不會被其他公司的產品分散注意力。

Azul，只全心關注Java， 而非將您綁在企業版套裝軟體中，或讓您被無法擺脫的昂貴雲端廠商纏身。

最重要的是，Azul 擁有支援和保護全體Java 資產的專業知識和經驗，包括:

• Windows、Linux ( 包括 Alpine)、 macOS和Solaris
• 用於雲端的 Docker 和 Linux 容器
• 安裝程式和套件格式(DMG、MSI、RPM、DEB、APK 等)
• x86、Arm、PowerPC 和 SPARCv9 等處理器架構● 32 位元或 64 位元應用程式
• 所有級別的 Java 修正檔
• 包含JRE、模組化組建或CompactProfiles ( 僅限 Java 8) 的任何磁碟和記憶體容量
• 長期和中期支援的 Java 版本，包括JDK 15、13、11、8、7 和 6
• 在 Azul，您可以使用高級企業方案，因此您總能獲得您最需要的。此方案完全無須綁定，也沒有任何附加條件

Azul Platform Core 是擁有Java 應用程式公司的理想選擇

若您的應用程式或公司想藉由嚴格的 SLA來定期進行 Java 安全更新來確保安全性，Azul 就是您的最佳選擇。如果您需要 Java舊版本( 例如 7 或 6) 的支援，那麼 Azul是您唯一的選擇。 如果您需要來自 Java專家團隊的即時幫助及回應，我們邀請您加入 Azul 的世界。

在 Azul Platform Core 中實現完善的 Java 應用

必須說明的是，Azul 不會試圖改變OpenJDK 核心程式。與之相反，我們對Java 的規劃，能使 OpenJDK 的應用更加完善。除了修復錯誤之外，我們組織、策畫和監督以下作為來增強 OpenJDK：

1. 確保從 Oracle JDK 順利轉移， 同時維持相同的高標準執行環境，例如提供Oracle 曾使用過的關鍵字體。

2. 為開發人員、品質測試人員、 維運人員，及 IT 人員提供開箱即用的元件，讓使用者更加便於部署、分析、剖析、監控系統。

3. 降低您使用到重新發佈的 OpenJDK、執行環境有安全漏洞、智慧財產權污染、專利訴訟、與 Oracle 運行時的兼容性問題等風險。

關於Azul

Azul 是業界唯一專精於 Java 和 Java 虛擬機(JVM) 的公司，為基於 Java 開發的公司打造了完全受支援、符合各項準則規範的執行環境。歡迎造訪 www.gss.com.tw/azul 以了解更多資訊。