以下討論只針對PC端和行動端。
Java最大的優勢真的在於跨平台嗎?以前是,但現在已經不是了。
有跨平台需求的只是客戶端應用,而不是服務端。例如桌面應用,你的客戶可能是Windows用戶,也可能是Linux用戶,這時候如果不想多投入成本對各個平台進行適配,那麼Java所謂的”Write once, run everywhere”就顯得異常光彩。然而今天,整個軟體世界都在向B/S應用傾倒(嵌入式除外),即使要做客戶端跨平台,QT等第三方框架遠遠比Swing更強大,Java在桌面應用領域基本上被淘汰已經是不爭的事實了,而當初Java引以為傲的Applet也早已銷聲匿跡。如果說客戶端Java還有一點優秀的話,那就只有Android了。 Android最初確實靠JVM屏蔽了不同硬體設備之間的區別並取得了巨大的成功,但在今天,Android L中ART模式的出現也即將顛覆這一情況,況且Google還可能會想用自家的Go語言取代Java成為Android平台的第一語言。所以在客戶端,Java幾乎完敗。
服務端應用不需要跨平台。做Web伺服器,我想沒有哪家公司今天用Linux,下個月就換Windows吧?如果只是更換Linux發行版,如從Debian到Fedora,本質上講其Linux核心是不變的,因此像C++這樣純編譯類型的語言已經沒什麼問題。如果做遊戲伺服器,我想幾乎都會選擇Linux而不是Win平台。 Java的跨平台優勢的實用性其實已經被大大弱化了,可以說在實際應用中並不明顯,在一般情況下幾乎感知不出Java還能跨平台這個特性。身為三大商用JVM之一的JRockets是只有編譯器的JVM,即應用程式啟動時會將字節碼全部編譯為本地機器碼,這其實就很大程度上摒棄了跨平台,而追求效能。
今天,Java最大的優勢在於其龐大而完善的生態系統。 一門程式語言是否能流行,主要是由其生態系統決定的。 Java生態系的完善性主要體現在以下幾個方面:
Java擁有世界上數量最多的程式設計師。你說他們是農民也好,但數量放在那裡,最明顯的效果就是公司招募的時候會比較容易招募Java程式設計師。試想如果你想要做一套軟體,你有一個很棒的技術方案需要用C++,Scala或Ruby等語言實現,但招不到足夠的人手,那麼計劃多半泡湯。這時候你的應用程式Java也能做到,而且很輕鬆就能招到足夠的人,那麼你選擇Java的可能性就要大一些。
Java擁有大量的第三方類別庫。假如你想解析HTML,用C/C++這類語言恐怕多半只能自己寫解析演算法庫了,而如果是Java,你可以非常輕鬆地在Github上找到JSoup,使用Maven導入依賴後分分鐘就搞定HTML 。為此還有一句諷刺Java的話是:「我們不生產程式碼,我們只是Github的搬運工。」這句話從字面上看是很有道理的,但卻忽略了對軟體生產效率的提升所帶來的巨大價值。對於軟體的開發,公司的唯一成本其實就是“人頭費”,每減少一個月開發時間,就能幫助公司節省幾十萬幾千萬的研發成本。
Java擁有功能強大的IDE。 Eclipse,透過外掛程式幾乎可以滿足你開發的任何需求。它雖然有些慢,但你可以透過JVM調優來提高程式的流暢度,千萬不要使用預設的JVM參數。不過,IntelliJ Idea已經完全超越Eclipse了,Idea的智慧程度幾乎可以媲美Win平台下的VS。我是那類離了Vim就活不下去的人,在這兩款IDE中都有Vim插件從而讓我愉快地存活下去。
Java擁有很多殺手級應用。 不必多說,Spring, Struts, Hibernate, Hadoop, Tomcat, JBoss等等。
Java的語法特性很少。對,這也是一項優點。 C++比較C增加了大量特性,學起來費事不說,用起來還會降低程式碼可讀性,其實是費了工夫不討好。當今世界對程式語言的要求是語法簡單,程式碼可讀,對效能已經是退而求其次了,因此才誕生了Python, Ruby這樣的程式語言。有很多人批評Java語法寫起來很臃腫,我承認這一點,但事實是,程式語言從來都不是因為語法臃腫而被淘汰的,決定其生死的是生態系統。對於批評者,引用知乎的一句話:」動態型一時爽,程式碼重構火葬場」
Java的效能已經夠高了。 Sun/Oracle的HotSpot JVM內建的JIT編譯器在運行時對字節碼已經做出了非常大的優化努力,服務端應用啟動後對JVM進行足夠的”預熱”,並給出合理的啟動參數即可。如果不是對效能十分敏感的系統類別應用,Java已經夠快了。有一個簡單可行的方法可以形像地看出這一點,在JVM啟動參數中加入+XX:PrintCompilation可以看到JIT編譯器的忙碌。現今世界對軟體的需求越來越大,在效能可接受的情況下,開發效率才是第一位的,這也是Python這類動態腳本語言流行的主要原因