為什么說Java正在死去
為了在新工作中更好地與技術堆棧保持一致，過去兩周我一直在和一個老朋友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和臭名昭著的類加載器的過時修辭。毫無意義地應對。
判決?"保持簡單，愚蠢!"
