【CSDN 編者按】提到 Java，批評聲從未中斷，無論是“已死”還是“

即將衰亡

”，總有開發者唱衰 Java。然而與批評不同的是，本文作者是Java的忠實粉絲，他對控訴Java劣跡的特性進行一一反駁。

原文連結：https：//debugagent。com/the-reason-java-is-still-popular

宣告：本文由 CSDN 翻譯，未經允許禁止轉載。

作者 |

Shai Almog

譯者 | 彎月

最近，Java 19正式釋出。Java仍然是我摯愛的程式語言，但前一段時間有人在帖子中控訴Java的種種“劣跡”（原文連結：https：//medium。com/codex/i-finally-gave-up-on-java-5187947bef1b）。

在此，我想對其進行逐一反駁。

Getters and setters

首先，那篇帖子中抱怨了 getter 和 setter。但實際上，在現代 Java 中，getter 和 setter 不是必需的。我們從 Java 14 開始就有記錄，在我看來Lombok很好。我們唯一需要 getter/setter 的地方是在一些特定的設定（例如 JPA）中，而且 Lombok 也完美地解決了這個問題。

那篇帖子反覆訴說 Java 缺乏語法糖特性。但實際上這是有意為之。如果你對最新的語法細節感興趣，則可以看一看 Kotlin。Java 的發展“緩慢而穩定”，這是

一件好事，也是 Java 長壽的主要原因。

語法糖和運算子過載

現代 Java 包括 switch、var、多行字串等模式，還有一些即將推出的功能，包括字串模板。字串模板的支援還需要一段時間，因為 Java 想要“正確地實現”。API 級別有一些此類的支援（而且已經有一段時間了），但效能不是很好。字串模板的目標是建立一種語法以支援以下寫法：

ResultSet rs = DB。“

SELECT

*

FROM

Person p

WHERE

p。last_name = \{

name

}

”；

注意，這裡的 name 是一個變數，編譯器需要動態地檢查並從作用域中獲取！

DB 可以由開發人員自定義實現，不需要“內建”，因此你可以構建複雜的模板。

話雖如此，我們還是先把 Java 未來的規劃放在一邊，只看看現在的Java。

近十年來，我們一直不推薦使用 String 的 append，因為使用+的效能更高，而且更易於閱讀。

實際上，運算子不能過載是一個巨大的好處。如果看到 a + b，那麼我就知道這是一個字串或一個數字，而不是一些不為人知的方法。這是 Java 最大的優勢之一，也是它流行了近 30 年而其他語言卻被拋棄的原因之一。Java的語法設計考慮到了大規模的程式碼閱讀。當專案的程式碼規模高達百萬行，甚至是十萬行時，你將會面臨完全不同的問題。此時，如果你發現模組X中的程式Y錯誤地過載了某個運算子，那麼除錯就會非常困難。語法應該儘量簡單，最初節省的任何小成本將來都要 10 倍償還。隨著程式碼越來越複雜，時間越來越久，簡單的定義也會發生變化。再加上工具的強大功能可以大規模解析嚴格的簡單程式碼，由此帶來的

好處也數不勝數。

檢查型異常

檢查型異常不是必須的，但這是 Java 最優秀的特性之一。程式碼發生異常的事情太常見了。作為個人娛樂專案，出現異常也沒問題，但如果要構建專業的應用程式，那麼就必須處理每個錯誤。檢查型異常可以避免發生意外情況。人們討厭檢查型異常，只是因為他們懶。而 Java 不讓你偷懶。

對於建立網路連線、資料庫連線、開啟檔案等操作，不處理異常是不可能的。就算我想偷懶，檢查型異常也會強迫我在某個地方處理異常。這個特性非常好。

依賴

我對於 Maven 和 Gradle 的意見頗多。但跟其他依賴系統相比，它們還算不錯。雖然二者的確存在一些問題，但拿它們跟 cargo 這種年輕的包管理器做比較是不公平的，再說後者幾乎沒有任何可用的包。Maven 中心庫擁有 27TB 的jar 包，每個月有 4960 億次請求。它依然能正常工作，而且基本上沒有宕機時間。

其他工具，比如 NPM，也襯托了 maven 的強大之處。如果說 maven 中的依賴是一個問題，那麼 NPM 的問題豈不是有 100 倍，而且還無人管理。這些問題會變得越來越複雜，特別是當市場上存在多個版本的 maven 時。但是，maven 和 gradle 這樣做的原因之一是工具。許多情況下，IDE 都能解決並自動修復這些問題。

Java 的文化問題

這篇文章（https：//alexn。org/blog/2022/09/19/java-cultural-problem/）中提到了關於 Java 的一些文化問題，我同意。Java 開發者傾向於把每個問題都變成更復雜的問題。有時候，這是必要的，畢竟 Java 是個超級龐大的怪物，它的解決方案通常都有過度設計的問題。這肯定要比設計不足要好，但的確

要付出一定的代價。

為什麼使用註釋進行驗證

我想起了下面這個例子，看似“正確”，但其實有問題：

@NotNull @Email

String noReplyEmailAddress

作者認為這樣不對，應該寫成下面這樣：

public

record

EmailAddress

（

String

value

）

{

public

EmailAddress {

// We could‘ve used an Either data type， ofc；

Objects。requireNonNull（

value

）；

// regexp could be better

if

（！

value

。matches（

“^［^@\\s］+@\\S+$”

））

throw

new

IllegalArgumentException（

String。format（

“’%s‘ is not a valid email address”

，

value

））；

}

}

這段程式碼當然可以這麼寫，但有幾個問題，因此我們需要使用 Bean 驗證：

這種寫法無法被最佳化。而Bean驗證可以被框架移動到更高的層次，甚至可以由客戶端程式碼進行驗證，因為它是宣告式的API。這裡我們不需要執行建構函式來進行驗證；

宣告式的註釋可以向下層移動，無縫地應用到資料庫約束上；

可以同時應用多個註釋；

語法更簡潔。

因此，儘管這裡的註釋看起來有點奇怪，而且不會強制檢查型別，但能極大地提升效能，而且很強大。這種用法背後有很多考量。

總結

本文花了很多篇幅來反駁其他文章，下面我想提出一些自己的看法。Java 已有近 30 年的歷史了，很多功能仍然能與 Java 1。0 相容，這一點就非常了不起！

Java 採取保守路線的好處之一就在於，可以“私下裡”進行最佳化，而使用者甚至注意不到。Java 9 完全改變了字串在記憶體中的表示方式，從而極大地降低了記憶體使用，但這個改動對外部沒有任何影響。與之類似，Loom 提高了 Java 同步應用的吞吐量，Valhalla 進一步改善了集合的效能，統一了物件和基本型別的觸發。Panama 讓我們擺脫了 JNI，降低了與原生程式碼打交道的難度。

如果你不喜歡Java，也許可以試試 Kotlin 或 Scala。JVM 無所不包，其帶來的優勢普遍適用，而且上面我提到的那些好處能讓整個生態系統受益。