重拾Java:這種編程語言為什么不行了?
為了應對新工作,筆者在過去兩周一直在重新熟悉一位老朋友:JAVA。我以JAVA開啟了我的軟件事業,與之共行了兩年半左右的時間。但是隨著容器和微服務的出現,JAVA很快消失了。時至今日,距我上次用Java正經寫代碼已有三年。筆者沒想到它會再次出現,尤其是出現在微服務領域。
這是怎么回事?答案很簡單:無處不在的微服務鋪天蓋地。
- 易于擴展
- 高可用性
- 更簡單的代碼庫,不必擔心并發和多線程
- 容器化帶來的便攜性
所有這些都使人們質疑Java(更具體地說是JVM),更不用提Java最臭名昭著的Spring框架了。
有時,人們沉浸在Kubernetes之類的技術中,感覺Java的時代已是歷史,Java在容器和微服務生態系統中表現欠佳(軟件可擴展性和高可用性的關鍵)。盡管被Python等語言(筆者現在的首選語言)的簡單和優雅所動搖,但作為Java曾經的死忠粉,筆者認為Java仍在某些領域有毋庸置疑的優勢。
例如,Java有強大的線程功能,筆者職業生涯的早期就將它們直接用于關鍵銀行應用。雖然將編譯語言與腳本語言的性能指標進行比較并不公平,但Java堅如磐石的性能確實無與倫比。
而對于水平擴展性和微服務體系結構,這種語言固有性能的作用微乎其微,因為人們可以直接產生更多容器來獲得出色的性能。顯然,這些腳本語言,再加上在容器范圍內即時放大或縮小的能力,就能使Java打道回府了。筆者確信,Java已死,至少在微服務領域。
在新工作中,筆者進一步確信并痛苦地意識到這種語言有多令人厭惡、煩躁和費解(一部分在于Spring等過時的死板框架)。
Java與Spring的一派正經
首先講講臭名昭著的Spring框架。與五年前無異,Spring體積龐大且令人費解,充斥著無窮無盡的注釋,開發人員每次要么得求助于教程或示例代碼,要么只能研讀Spring提供的冗長文檔。
Spring本就采用了一種很死板的語言,用單行注釋和看似簡化的包裝器加以掩蓋,從而加劇了這個問題的嚴重性,這些包裝器會帶來一堆調用和類別例示,通常都派不上用場。
所有開發人員都同意這點:語言的可控性、指令和透明度對是高效開發軟件的關鍵。簡而言之,開發人員希望準確了解代碼中發生了什么以及執行了哪些例程(至少是在較高層次上)。但Spring在此有著極大阻礙。
如果必須在類的頂部插入六個各自運行任務注釋,它們在Spring環境中錯綜復雜地相互聯系,那你的處境就復雜了。不僅Spring如此,以Lombok庫為例。這是其首頁上第一行描述:
“Lombok項目是一個Java庫,它會自動插入您的編輯器和構建工具中,從而為您的Java增光添彩。無需再編寫另一個getter或equals方法,一個帶有注釋的類將具有功能全面的生成器,自動執行日志記錄變量等等。”
壓縮Java代碼的目標不過是照本宣科,不能真正發揮作用。
Java應該停止匹配腳本語言的簡潔性。第一,這犧牲了Java代碼的一致性:想象返回Java發現所有的getter和setter都消失了,取而代之的是單行注釋@NoArgsConstructor。這哪還有一致性?
其次,它增加了本就費解的抽象數組。例如,Spring可以在后臺設置自動裝配(bean注入),這是可以理解的,但是Lombok在應用程序環境中位于何處,以及如何協調消息?如果每個類都有六個注釋,那么這些注釋還實例化了多少其他例程或類來完成這種簡單的工作?
每個開發人員都不希望有額外的代碼四處潛伏。然而這就是筆者三年后遇到的Java代碼,沒有任何改變。實際上,微小的變化也只會使情況變得更糟。Java仍然側重于愚蠢的規則,這些規則規定了應使用的類名,所在的包,以及變量是私有的還是受保護的。但根本沒人在乎這些。
相比之下,Python對缺少語言的訪問說明符直接回復:“大家都是成年人了”。這僅僅一行的回復嘲諷意味十足又極具吸引力,它立刻引起了我的共鳴,我過去常常覺得荒謬且無用的概念在它的影響下合理了很多。
保持簡單,程序員們
在軟件行業,你經常能聽到人們說“KISS”:保持簡單(Keep it simple),傻子們(Stupid)。Java只有認真考慮這點才能生存。
如今,微服務模式在軟件行業中幾乎無處不在,甚至許多運行古早應用程序的組織也越來越多地替換其舊的整體,以簡化設計并提高可擴展性。對于程序員而言,這意味著將其龐大的代碼庫或復雜的業務邏輯分解為更簡單、簡潔的功能——一種無需在代碼中進行狀態管理的范例,從而避免并發和多線程的問題。
歸根結底,無論何種服務,都只處理某種格式(JSON或XML)的數據,然后將它們傳遞到消息總線(如Kafka)以進行進一步處理。即使是這樣簡單的設置中,Java和Spring還在照搬過時又死板的代碼語法:Application Contexts、 bean injections,、autowiring、 POJO mappers、需要大量內存的 JVM、討厭的 class loader。
所以,結論是什么?“保持簡單,程序員們!”