Java22

為了加快執行速度和使用既有的外部函式庫以避免重複造輪子，Java 程式常會需要與原生程式碼（Native Code）進行互動。它的目的是為了效能優化、存取硬體資源，或是使用現有的功能強大 C/C++ 函式庫。然而，傳統的 Java Native Interface（JNI）機制存在著許多限制和安全性問題。 Java 22 推出的 JEP 454 Foreign Function & Memory API（FFM API）提供了全新的解決方案。JEP 454 不僅提供了更安全、更現代化的方式來進行 Java 與原生程式碼的互動，還大幅簡化了記憶體管理和函式呼叫的複雜度。下面老喬會簡介如何使用 JEP 454 FFM API 來達成更優秀且更健全的外部存取方式。 前言 Java 平台為開發人員提供了豐富的解決方案，包括與其他平台函式庫互動的功能。無論是存取資料庫（JDBC）、使用 Web 服務（HTTP 客戶端）、服務遠端客戶（NIO channels），或是本地行程通訊（Unix-domain socket），Java API 可以方便且可靠地存取非 Java 語言撰寫的資源。 …

Java 22 的 JEP 458 為 Java 開發流程帶來了一項非常重大的改變，使得開發人員擁有更便捷的程式開發體驗，特別是在專案初期和原型開發時期。這項新功能允許我們直接使用命令列去執行多個 Java 原始碼檔案，而無需事先編譯它們。 本文將深入介紹這項新功能的細節、設計理念、以及對開發流程的影響。下面將透過幾個實際的範例來展示它如何能夠簡化我們的開發過程，並介紹它們的應用方式。 前言 我們都知道 Java 程式語言擅長於大型且複雜的應用程式，它們通常會由大團隊開發並維護達數年之久。不過，在許多大型應用程式的早期階段，我們會開發較小的原型程式並驗證其功能可行性，而不會直接撰寫完整可交付的成品。此時的專案結構可能還不存在，而且即使出現，也會產生頻繁的變化。在這個階段，快速迭代和徹底變更是常常發生的事。 因此，在目前的 Java 開發環境中，我們常常面臨著這樣普遍的困境：當專案從單一檔案擴展到多個檔案時，開發過程往往需要一個明顯的轉變。這種轉變通常牽涉到專案架構的變化、建構流程的修改、學習新的指令，或是依賴某些 IDE 的功能，這對於初學者來說特別具有挑戰性。 近年來，JDK 中增加 …

在 Java 的發展歷程中，程式碼的簡潔性、可讀性和維護性一直是開發者關注的重點。Java 21 的 JEP 443 引入了未命名變數和模式的概念，並在 JDK 22 的 JEP 456 中成為正式功能。它可以簡化模式匹配語法，使其更易於使用與理解，並提升開發效率。 本文將介紹如何使用底線字元 _ 去匹配不必要且可完全省略的變數和模式，以及如何在實際開發中運用這項特性來減少冗餘程式碼，使其能夠更明確地表達開發人員的意圖。 前言 在日常的開發中，我們有時需要宣告一些實際上不會用到的變數，無論是出於程式碼風格的考量，或是因為在某些情況下需要變數宣告。例如，在處理迴圈、捕捉異常或是操作串流時，有些變數純粹是為了符合語法要求而存在，而這些變數的命名往往成為一種負擔。它們不只增加了程式碼的複雜度，還可能導致靜態分析工具發出警告。 雖然我們在編寫程式碼時就已知道並不會使用這些變數，但如果沒有明確地註解說明的話，其他的維護者可能會意外使用該變數，從而違反了原本的意圖。如果我們能夠使這些變數不可能被意外使用，那麼程式碼將更具資訊性、更具可讀性，並且更不容易出錯。 未使用的變數 具體來說，當我們在處理計 …

自 Java 於 1995 年面世以來，Java 虛擬機（JVM）的垃圾回收機制一直是眾所矚目的重要功能，也是效能優化的關鍵領域。本文將介紹 JEP 423 的 G1 垃圾回收器區域釘選（Region Pinning）技術，能大幅改善 G1 垃圾回收器在處理 Java Native Interface 臨界區域時的效能。 區域釘選技術的核心目標是減少 JNI 使用臨界區域時的延遲問題，以維持垃圾回收的效率。這項技術允許 G1 垃圾回收器在 JNI 臨界區域期間繼續進行垃圾回收，而不是完全禁用它，並藉此提高 Java 程式的整體效能和回應性。 前言 Java 雖然能夠完成許多複雜的任務，但因為 Java 語言本身的特性與平台的限制，導致它在某些情況下無法完成特定的任務，或是效能比其他語言差。為了彌補這些短處並善用其他語言的長處，讓 Java 程式碼能夠與其他程式語言（如 C 或 C++）相互操作是重要且必要的。它可以讓我們不用去實作其他語言已經完成的工具，使我們專注在解決問題而不是重造輪子。 為了能夠與 C 和 C++ 等程式語言進行溝通，Java 1.1 中定義並實作了 Java Na …