Java的未來將如何發展？

> Photo by Jonas Jacobsson on Unsplash.

為了在新工作中更好地與技術堆疊保持一致，過去兩週我一直在和一個老朋友Java進行自我重新認識。不久之前，它以無與倫比的熱情和活力開始了我的軟體事業。這一過程持續了大約兩年半的時間，但是隨著容器和微服務的出現而很快消失。到今天，距我上次編寫任何嚴肅的Java程式碼已經三年了。老實說，我從沒想到它會再次出現，尤其是在微服務領域。

所以發生了什麼事？答案很簡單：微服務無所不在的浪潮席捲了我們。

· 易於擴充套件

· 高可用性

· 無需擔心併發和多執行緒的簡化程式碼庫

· 容器化帶來了可移植性

所有這些因素促使我們質疑Java（更具體地說是JVM）的功效，更不用說Java最臭名昭著的框架Spring了。

有時，人們沉浸在Kubernetes之類的技術中，感覺Java的時代已經過去，並且在容器和微服務生態系統中的表現不佳（這是軟體可擴充套件性和高可用性的關鍵）。但是，作為曾經堅定支援Java的人-儘管一直受到Python之類的語言（現在已經成為我的首選語言）的簡單和優雅的影響，但我仍然繼續為Java不可否認的某些領域保留一席之地優點。

例如，我很清楚Java強大的執行緒功能，在我的職業生涯初期就將它們直接用於關鍵銀行應用程式。雖然將編譯語言的效能指標與指令碼語言的效能指標進行比較是不公平的，但Java堅如磐石的效能卻無與倫比。

但是在水平可伸縮性和微服務體系結構的世界中，這種語言的固有效能太重要了，因為人們可以簡單地產生更多的容器來獲得出色的效能。顯然，這些指令碼語言以及它們在容器領域中即時放大或縮小的能力，使Java物有所值。我一勞永逸地確信Java已經完成了（至少在微服務領域如此）。我是對的！

在我的新工作中，這些信念僅得到進一步加強，使我感到痛苦的是，我意識到這種語言變得多麼令人討厭，煩躁和令人費解-部分原因是由於Spring等過時的儀式框架。

Java和Spring的儀式

讓我們從臭名昭著的Spring框架開始。

與五年前相比，Spring是如此龐大且令人費解，充斥著無窮無盡的註解，這些註解使開發人員每次需要完成工作時就只能依靠教程或示例程式碼。細讀Spring自己詳盡的文件既是艱鉅的任務，又是艱鉅的任務。

實際上，我最喜歡的是像Spring這樣的框架，而不是Java本身。Spring採用了一種已經很禮貌的語言，用單行註解和看似簡化的包裝器對其進行掩蓋，從而加劇了這個問題，這些包裝器最終召喚出了通常不需要的類的呼叫和例項化的狂歡。正如任何開發人員都會同意的那樣，語言的控制，命令和透明性對於有效的軟體開發至關重要。簡而言之，作為一名開發人員，想準確地瞭解程式碼中發生了什麼以及執行了哪些例程-至少是在較高層次上。但是Spring在這方面痛苦地阻止了你。

如果必須在類的頂部放置六個註解，而每個註解都在做自己的事情，並且在Spring上下文的網格中錯綜複雜地相互聯絡，那麼你將處於一片模糊的境地。這不僅是Spring。以Lombok庫為例。這是其首頁上宣傳的第一線：

" Project Lombok是一個Java庫，它會自動插入你的編輯器和構建工具中，從而為你，的Java增光添彩。永遠不要再編寫另一個getter或equals方法，帶有一個註釋的類將具有功能齊全的生成器，自動執行日誌記錄變數等等。"

壓縮Java程式碼的這種反常的目標令人沮喪，並且痛苦地針對該語言進行工作，而不是做任何真正的事。

Java應該簡單地停止嘗試與指令碼語言的簡潔性相匹配。首先，這犧牲了Java程式碼的一致性：想象回到Java只是發現所有的getter和setter都消失了（我們曾經學過的知識對於Spring自動裝配很重要），現在已被單行註釋@NoArgsConstructor取代。一致性在哪裡？

其次，它增加了已經令人費解的抽象陣列。例如，在這裡，Spring可以在後臺設定自動裝配（bean注入），這是可以理解的，但是Lombok在應用程式上下文中位於何處，以及如何在兩者之間協調訊息傳遞？如果我的每個類都有六個註解，那麼這些註解還例項化了多少其他例程或類來完成這一簡單的工作？沒有真正的開發人員會希望將所有這些額外的程式碼潛伏在角落。可悲的是，這是三年後我遇到的那種Java程式碼。沒有一件事情發生改變。實際上，即使發生的微小變化也只會使情況變得更糟。

Java仍將重點放在愚蠢的規則上，這些規則規定了應使用的類名，應使用的包以及變數是私有的還是受保護的。說真的，誰在乎？

相反，"我們都是成年人"實際上是Python對該語言中缺少訪問說明符的官方迴應。這種嘲諷而引人入勝的單行迴應立刻引起了我的共鳴。最終，它使我經常覺得是荒謬且不必要的概念更為理智。

保持簡單，愚蠢 KISS

如果您在軟體行業一次又一次地聽到一件事，那就是KISS的首字母縮寫：保持簡單，愚蠢。如果Java要生存，這是需要認真考慮的事情。

如今，微服務模式已在軟體行業中幾乎普及。甚至許多執行舊版應用程式的組織也越來越多地替換其舊的整體，以簡化設計並提高可伸縮性。對於程式設計師而言，這意味著將其龐大的程式碼庫或複雜的業務邏輯分解為更簡單，簡潔的功能-一種無需在程式碼中進行狀態管理的範例，從而免除了併發問題和多執行緒噩夢。

歸根結底，所有服務，無論是某種形式或形式，都只處理某種格式（JSON或XML）的資料，然後將它們傳遞到訊息匯流排（如Kafka）以進行進一步處理。甚至在這樣簡單的設定中，Java和Spring仍在反駁禮節性程式碼語法，應用程式上下文，複雜的bean注入，自動裝配，POJO對映器，記憶體消耗巨大的JVM和臭名昭著的類載入器的過時修辭。毫無意義地應對。

判決？"保持簡單，愚蠢！"