為什么說Java正在死去
為了在新工作中更好地與技術(shù)堆棧保持一致,過去兩周我一直在和一個(gè)老朋友Java進(jìn)行自我重新認(rèn)識(shí)。不久之前,它以無與倫比的熱情和活力開始了我的軟件事業(yè)。這一過程持續(xù)了大約兩年半的時(shí)間,但是隨著容器和微服務(wù)的出現(xiàn)而很快消失。到今天,距我上次編寫任何嚴(yán)肅的Java代碼已經(jīng)三年了。老實(shí)說,我從沒想到它會(huì)再次出現(xiàn),尤其是在微服務(wù)領(lǐng)域。
所以發(fā)生了什么事?答案很簡(jiǎn)單:微服務(wù)無所不在的浪潮席卷了我們。
- 易于擴(kuò)展
- 高可用性
- 無需擔(dān)心并發(fā)和多線程的簡(jiǎn)化代碼庫
- 容器化帶來了可移植性
所有這些因素促使我們質(zhì)疑Java(更具體地說是JVM)的功效,更不用說Java最臭名昭著的框架Spring了。
有時(shí),人們沉浸在Kubernetes之類的技術(shù)中,感覺Java的時(shí)代已經(jīng)過去,并且在容器和微服務(wù)生態(tài)系統(tǒng)中的表現(xiàn)不佳(這是軟件可擴(kuò)展性和高可用性的關(guān)鍵)。但是,作為曾經(jīng)堅(jiān)定支持Java的人-盡管一直受到Python之類的語言(現(xiàn)在已經(jīng)成為我的首選語言)的簡(jiǎn)單和優(yōu)雅的影響,但我仍然繼續(xù)為Java不可否認(rèn)的某些領(lǐng)域保留一席之地優(yōu)點(diǎn)。
例如,我很清楚Java強(qiáng)大的線程功能,在我的職業(yè)生涯初期就將它們直接用于關(guān)鍵銀行應(yīng)用程序。雖然將編譯語言的性能指標(biāo)與腳本語言的性能指標(biāo)進(jìn)行比較是不公平的,但Java堅(jiān)如磐石的性能卻無與倫比。
但是在水平可伸縮性和微服務(wù)體系結(jié)構(gòu)的世界中,這種語言的固有性能太重要了,因?yàn)槿藗兛梢院?jiǎn)單地產(chǎn)生更多的容器來獲得出色的性能。顯然,這些腳本語言以及它們?cè)谌萜黝I(lǐng)域中即時(shí)放大或縮小的能力,使Java物有所值。我一勞永逸地確信Java已經(jīng)完成了(至少在微服務(wù)領(lǐng)域如此)。我是對(duì)的!
在我的新工作中,這些信念僅得到進(jìn)一步加強(qiáng),使我感到痛苦的是,我意識(shí)到這種語言變得多么令人討厭,煩躁和令人費(fèi)解-部分原因是由于Spring等過時(shí)的儀式框架。
Java和Spring的儀式
讓我們從臭名昭著的Spring框架開始。
與五年前相比,Spring是如此龐大且令人費(fèi)解,充斥著無窮無盡的注解,這些注解使開發(fā)人員每次需要完成工作時(shí)就只能依靠教程或示例代碼。細(xì)讀Spring自己詳盡的文檔既是艱巨的任務(wù),又是艱巨的任務(wù)。
實(shí)際上,我最喜歡的是像Spring這樣的框架,而不是Java本身。Spring采用了一種已經(jīng)很禮貌的語言,用單行注解和看似簡(jiǎn)化的包裝器對(duì)其進(jìn)行掩蓋,從而加劇了這個(gè)問題,這些包裝器最終召喚出了通常不需要的類的調(diào)用和實(shí)例化的狂歡。正如任何開發(fā)人員都會(huì)同意的那樣,語言的控制,命令和透明性對(duì)于有效的軟件開發(fā)至關(guān)重要。簡(jiǎn)而言之,作為一名開發(fā)人員,想準(zhǔn)確地了解代碼中發(fā)生了什么以及執(zhí)行了哪些例程-至少是在較高層次上。但是Spring在這方面痛苦地阻止了你。
如果必須在類的頂部放置六個(gè)注解,而每個(gè)注解都在做自己的事情,并且在Spring上下文的網(wǎng)格中錯(cuò)綜復(fù)雜地相互聯(lián)系,那么你將處于一片模糊的境地。這不僅是Spring。以Lombok庫為例。這是其首頁上宣傳的第一線:
" Project Lombok是一個(gè)Java庫,它會(huì)自動(dòng)插入你的編輯器和構(gòu)建工具中,從而為你,的Java增光添彩。永遠(yuǎn)不要再編寫另一個(gè)getter或equals方法,帶有一個(gè)注釋的類將具有功能齊全的生成器,自動(dòng)執(zhí)行日志記錄變量等等。" |
壓縮Java代碼的這種反常的目標(biāo)令人沮喪,并且痛苦地針對(duì)該語言進(jìn)行工作,而不是做任何真正的事。
Java應(yīng)該簡(jiǎn)單地停止嘗試與腳本語言的簡(jiǎn)潔性相匹配。首先,這犧牲了Java代碼的一致性:想象回到Java只是發(fā)現(xiàn)所有的getter和setter都消失了(我們?cè)?jīng)學(xué)過的知識(shí)對(duì)于Spring自動(dòng)裝配很重要),現(xiàn)在已被單行注釋@NoArgsConstructor取代。一致性在哪里?
其次,它增加了已經(jīng)令人費(fèi)解的抽象數(shù)組。例如,在這里,Spring可以在后臺(tái)設(shè)置自動(dòng)裝配(bean注入),這是可以理解的,但是Lombok在應(yīng)用程序上下文中位于何處,以及如何在兩者之間協(xié)調(diào)消息傳遞?如果我的每個(gè)類都有六個(gè)注解,那么這些注解還實(shí)例化了多少其他例程或類來完成這一簡(jiǎn)單的工作?沒有真正的開發(fā)人員會(huì)希望將所有這些額外的代碼潛伏在角落。可悲的是,這是三年后我遇到的那種Java代碼。沒有一件事情發(fā)生改變。實(shí)際上,即使發(fā)生的微小變化也只會(huì)使情況變得更糟。
Java仍將重點(diǎn)放在愚蠢的規(guī)則上,這些規(guī)則規(guī)定了應(yīng)使用的類名,應(yīng)使用的包以及變量是私有的還是受保護(hù)的。說真的,誰在乎?
相反,"我們都是成年人"實(shí)際上是Python對(duì)該語言中缺少訪問說明符的官方回應(yīng)。這種嘲諷而引人入勝的單行回應(yīng)立刻引起了我的共鳴。最終,它使我經(jīng)常覺得是荒謬且不必要的概念更為理智。
保持簡(jiǎn)單,愚蠢 KISS
如果您在軟件行業(yè)一次又一次地聽到一件事,那就是KISS的首字母縮寫:保持簡(jiǎn)單,愚蠢。如果Java要生存,這是需要認(rèn)真考慮的事情。
如今,微服務(wù)模式已在軟件行業(yè)中幾乎普及。甚至許多運(yùn)行舊版應(yīng)用程序的組織也越來越多地替換其舊的整體,以簡(jiǎn)化設(shè)計(jì)并提高可伸縮性。對(duì)于程序員而言,這意味著將其龐大的代碼庫或復(fù)雜的業(yè)務(wù)邏輯分解為更簡(jiǎn)單,簡(jiǎn)潔的功能-一種無需在代碼中進(jìn)行狀態(tài)管理的范例,從而免除了并發(fā)問題和多線程噩夢(mèng)。
歸根結(jié)底,所有服務(wù),無論是某種形式或形式,都只處理某種格式(JSON或XML)的數(shù)據(jù),然后將它們傳遞到消息總線(如Kafka)以進(jìn)行進(jìn)一步處理。甚至在這樣簡(jiǎn)單的設(shè)置中,Java和Spring仍在反駁禮節(jié)性代碼語法,應(yīng)用程序上下文,復(fù)雜的bean注入,自動(dòng)裝配,POJO映射器,內(nèi)存消耗巨大的JVM和臭名昭著的類加載器的過時(shí)修辭。毫無意義地應(yīng)對(duì)。
判決?"保持簡(jiǎn)單,愚蠢!"