Java 有用論

2019-11-18 11:45:46

字體：大中小

來源：轉載

供稿：網友

　　1.我們老祖宗說過，合久必分，分久必合。軟件工程本身是希望從工程學的角度來控制工程的進度，混雜各種技術不是什么好現象，C++恐怕種類也不少，目前還有誰只寫ansi C++的？看到漫天飛的makefile，各個版本的lib，不知名的頭文件()，遍地的define。。。，恐怕暈的不止我一個，多有耐心的人都要消耗時間來協調各個部分的程序(嗚嗚，我是低手，別臭我)，寫了許久，還是某個平臺的(確實有人可以寫出移植方便的程序，但我輩低手尚我此種眼界和經驗)。提到IA32真考倒了，java和jvm最好還是分開講，信任一群公司的聯盟可以提供更好的jvm，好象不只是我這么想。當然，java很多東西做不了，可以嘗試通過JNI、CORBA、Socket等技術來調用萬能的C++啊。十八班武器，那個沒有自己長短處？不過現在做底層應用的，還是以C為主。不信，看看那些做通訊，電子的，哪個是在用C，而且將來也不一定會轉到C++。　
　　
　　2.java是什么？這個問題問的好，三年前，兩年前，一年前，半年前，大家的理解都不同，本人第一次對這個問題有感覺有觸發是在回答一份ibm調查問卷的時候。　
　　java.sun.com/PRodUCts下面那些東西，有誰看完了？我是看了幾個，但起碼知道跑java的設備目前已經存在了，雖然是手持設備或通訊類產品，而且不是只能跑java，但起碼那也叫硬件。將硬件跟軟件支持分開，這才是適應不斷升級硬件、軟件的最優結合方式，拘泥于技術的細節，忽略方向，這樣子很被動的。
　　
　　3.被他的例子擊中要害。沒話講，一是不熟悉，二是我也基本同意他的看法，除了3.1.3，小小細節就不必拖出來講了。　
　　
　　4.1是個老話題了。的確，java效率通常要低于c++，但是它是掛在jvm上運行的，比通常的C++運行多了個殼，而且用循環來比較的話，恐怕這種舉例更不公平，顯然C++對于y = x * z優化跟java的處理有不同。假如一味強調編譯器優化的某項特性，那java這邊也可以做優化啊。運行態編譯就那么不可行？別忘了，服務器上的程序沒有哪個是運行一次就被重新執行的，而執行過一次，運行態編譯就會體現它的優點，一個C++程序運行一次3秒，一個java程序運行一次6秒，這就說java慢？好，那么那個c++程序運行10000次就是30000秒，那個java還是這么簡單乘法嗎？請考慮統計數據采樣的重要性。統計本身就是們學問，加減乘除都要有憑據的。對于兩者效率差多少，個人意見：在不同的應用場合下來測試，這樣可能客觀點。　
　　
　　4.2預編譯java誰說沒有？SQLJ白出來那么久了。運算符重載在java就有一個"+"，假如C++中有反射的話，相信靈活性會有更大程度的提高。模板類都是C++的精華，我也非常喜歡，那是C++中的奇跡，ATL和STL活在一群熱愛C++的程序員里面，但是其它語言又有誰支持了？類型約束，呵呵，假如程序員連類型都寫錯，那么在C++不需要改嗎？多繼續是個老話題，不過從com/dcom、corba這些技術，恐怕接口比多繼續更受歡迎吧。究竟超過二層的多繼續在C++應用實例也不常見，主要原因是沒必要，而且程序難調。AWT的確不是很受歡迎，4年前，人們都以為AWT就是java全部，結果多少人放棄java，但現在情況就完全不同了。java可以將程序壓縮放在jar文件中，以減少文件尺寸和方便治理，不過pe的也有壓縮加殼技術，但是終究不是系統級支持。　
　　
　　4.3扯多點東西，那位老大一定對信號量等同步技術非常重視，在java中實現非常簡單明朗，C++也麻煩，那么關于資源如何釋放對于程序員就只是個編程的習慣，相信在java中忘記關掉stream的人在C++也可能犯同樣的錯，而且結果也會相同。答應C++程序員在析構函數多寫幾行關閉，為什么一定認為java程序員會忘了吶？假如java是騙局，那么這是一場跨國多巨頭聯合超級大騙局。　
　　
　　5.java發展時間不長，比c++是年青太多了，年青到基本框架到處都在搭建，jvm的版本也是很多，我現在使用的是1.2.2_005，對個人影響也許不大，但這個對公司的影響確實比較大，沒有哪個公司愿意為jdk1.1.x和jdk1.2.x寫兩套軟件，但這個就好象c++的庫版本治理混亂一樣，沒有哪種技術一開始不需要傷筋動骨的改造，perl的下一版都在重寫吶。　
　　　
　　6.1好象軟件工程要求你在寫代碼前先干點什么，這個應該不算java的問題。是采用如何的方式學習和應用語言開發的問題。在工程里面說明一遍，然后再在header里面寫一清遍，恐怕算是浪費體力吧。javadoc強烈推薦大家使用，可以根據代碼生成象jdk那種結構清楚的文檔，寫完程序，這種文檔也可以作為補充。　
　　
　　6.2呵呵，又是多繼續。實例舉多了，不利于幫助了解事物的本質。　
　　
　　6.3析構，呵呵，析構中再調用其它的析構，好處可以自己定制析構，但是對于調試程序恐怕也會帶來多一些麻煩，這個世界上的程序員還是要靠debug來吃飯的。析構到底有那么神奇，令仁兄接二連三提起？　
　　
　　6.4許多人都討論過一個大對象好，還是一堆小對象好，那么本人的看法是假如一個大對象完成所有工作，那么就將問題局部化，調試范圍集中在一個文件，但不利于多人開發，而且功能升級也不方便，重用的可能更小；假如多個小對象，可以分工明確，功能升級有可能減少代碼的修改量，最大可能重用組件，對于項目治理的確是個挑戰，看似簡單的小對象之間的架構才是component比oo多出來的精髓，但使用不當會令工作事倍功半。這個問題對c++和java都成立，但是由于語言的風格不同，所以受重視的程度有不同，許多人在學習java的過程里面都會思考、比較這兩種模式。　
　　
　　6.5移植的東西就很難講。ibm和Oracle都要在palm上搞數據庫，ibm是改寫的，oracle是重寫的，那么哪個服務器軟件不是一大堆for各個版本的不同操作系統。這些就是擺在眼前d的實際問題。不知不覺，64位又要大行其道了。　
　　Fortran77和basic現在也有人用，甚至cobol用的人都不少，為什么？商業社會不答應隨便放棄過去，推C++的時候面臨的是同樣問題，怎么就這么快忘了吶？　
　　java的基本類型比較少，這個是事實，之間轉換也不是非常靈活，但是c++中，類似整除和取余更是通過函數實現的(順便提下，基本上c++中每一個內置函數都有功能相同名字、類型不同的，這些恐怕也不是什么好現象吧)。細節問題，不至于影響對java發展方向的評價。　
　　全局變量這種東西可以放在一個類中包裝啊，c++也是希望減少使用全局變量、宏編譯，聯合體出現的年代，String都不是數據類型，操縱起來也要處處小心。現在用聯合體的場合一般是廠家提供的api需要，自己寫程序用聯合體的不多。用聯合的語言就一定要支持指針，這是java所不愿走的路。　
　　instanceof確實非常有用，因為java可以通過非常多的形式拿到類的實例，假如不知道是什么類或者實現了什么接口(別咬文嚼字，接口本身就是一種非凡的類)，可以讓java的靈活程度大大加強。比起dll的動態加載，java的動態加載就是天生的，不需要那么多亂七八糟的規矩，而且可以通過jar來集中治理同屬一類的java class。　
　　反射是java的一大特色。　
　　
　　6.6呵呵，java可以騎著c/c++啊，jni是吃白飯的？通過jdbc可以調用數據庫中的東西，jndi可以訪問目錄，jms可以訪問消息隊列，jts可以訪問交易系統，javacard可以在sim卡上跑，corba可以調用任何支持corba的東西，socket可以調用任何支持ip的語言，rmi雖然只能用java，但是可以非常透明的得到實例，這是其它語言不具備的優勢，適合網絡分布計算。呵呵，這些只是非常普及的java技術之一小部分，它雖然不是什么崇高的理論，但是起碼它能讓許多計算機在一起工作，為應用服務，這才是我們最關心的問題。　
　　
　　7.偏系統底層開發，我寧可用C，中間層開發倒是java，界面用些簡單工具就算了。至于c++，恐怕只是當初在接觸面向對象時看到的一個誘人的夢了。

上一篇：Java 學習之道

下一篇：JAVA學習經驗之談