Posted by Mr. Saturday
Mr. Friday 的 Java會步上 COBOL 的後塵嗎? 一文還真是引起了相當多的討論，連在 FunP 上面都有一些高手們長篇大論的回應，另外我也看到了 qing 前輩也寫了篇文章 (剛剛也看到他來留言了) 來參與討論，Friday 也針對一些問題跟我私底下聊了一下．正好我自己也有一些淺薄的經驗，這邊就斗膽拿出來跟大家分享一下．不過我先開門見山地表明自己的觀點好了，基本上我覺得拿兩個程式語言來比較好壞，就跟拿英文和中文來比較好壞一樣，意義不大．每種語言有他存在的目的和當初被創造的理由，也各有其優缺點，而且語言會因為使用者而呈現出不同的面貌，真實生活中的語言如此，程式語言自然也不例外．
我比較想要談的，是像 Java 語言版本升級的問題，這也是 qing 前輩著墨甚多的一個問題，底下引述一段：
你沒有必要苦苦追趕Third party程式庫的新版本。通常，在產品開發之前，你就會決定你的技術解決方案，確定你所用的程式庫可以滿足你的需求。在產品開發中途決定更換所用程式庫的major version或到minor version是滿嚴重的事。大多數會需要選定新版的程式庫，多半是發生在選定開發一個新產品的時候。這麼一來，又怎麼會有「程式老跳訊息告訴你這個jar檔版本太舊不是他要的」的問題呢？
對於版本升級這個問題，我認為這絕對是個對工程師影響重大的事情．這邊我想舉出一個另外的例子和切入點，大家就會知道為什麼版本控制和升級會是個大問題．
大家的討論通常會把程式語言聚焦在產品上面．在單純地開發一個產品這方面，可能就像 qing 所講的，你一開始可以選定技術方案，確定所用的程式庫，中途不要亂更換版本，就不會有什麼問題，不過多數的時候在實際上，世界並沒有這麼美好．程式語言的升級有的時候不只是更改語法或是加入新的 language feature 和 library，很多時候伴隨著升級而來的，是去除舊版本的 bug 和替換舊的 library，甚至於改變某些 function 的行為．這並不是你是否要當一個新版魔人的問題，當你發現舊版本的 bug 可能會引響你的產品，甚至於你原本用的 function 被 deprecated 掉的時候，你必須去考慮升級，確保日後的相容性和穩定性．即使這件事情是發生在你的開發過程中，你也必須花費心力去評估或做修正，這當然是個大問題．不過當然，如果你開發的產品是如此地完美，以致於以後所有的版本更新都不會影響到你，那麼以上我說的對你來說就不成立．但我相信大多數的人不是如此．
以上的討論只放在用程式語言開發一個一個獨立的產品上面，各位是否想過，當一個語言成為你全公司的 infrastructure 的時候，狀況又會是怎麼樣？小弟任職的軟體公司，很不幸地就以 Java 去打造至關重要的 infrastructure．也就是說現在我們公司的工程師不只是用原生的 Java 去開發一個一個的產品而已，Java 這個語言本身已經擴展到全公司，成為很多環境的基礎，包括 parallel programming 的 framework 如 MapReduce；Remote Procedure Call 的 framework 等等，都是 based on Java 打造出來．這種規模和等級已經不是單一產品的問題，而是牽涉到以後所有還沒出現的產品和既有的產品，和全公司上千甚至上萬名工程師每天如何去寫程式的問題．
也因此，小弟公司內部有一個 team 叫做 Java Infrastructure Team，每次 Java 預定要推出升級的版本時，他們就如臨大敵，工作量暴增，必須立刻評估新版本對於全公司的影響，立刻做出反應，這牽涉到的問題多如牛毛，在管理上：有沒有必要升級是一個問題；什麼時候升級是一個問題；其餘合作廠商是否升級也是一個問題；在技術上：新版本的 performance 是否有差異是一個問題；新版本是否又會帶來新的 bug 是一個問題；對於既有產品的影響又是一個問題；在人員教育上：升級之後的磨合期也是一個問題．請注意，我不是在談單一個人去開發單一產品，我是在說版本升級 (即使是一點點最細微的更動) 如何同時影響到數千個產品，數千位工程師．在這種規模之下，很不幸地，你必須去苦苦追趕程式語言的升級．我想這也是為什麼 Mr. Friday 會提出版本升級的問題．
也因此，我認為版本升級，當然是個非常重大的議題．
相關推薦
 |
 |
訂閱 所有文章 (含專欄文章 + 產業新聞 + 其他文章)
同意你的觀點，版本升級對企業基礎建設而言，是一個重大的議題。
但如果說Java的版本太多，我則有不同的看法。以.Net來說，他沒幾年也出到第三版，不是嗎？不論Java，你看Ruby，PHP，PYTHON，那一個沒有版本演進？大家都在比快的…。
通常企業是不喜歡升級的啦，可以的話，看可不可以在現有版本上把bug解一解，不要亂動比較好。一個受歡迎的產品或架構的原罪就是，當他越受歡迎，就有很多人希望他不斷有新功能，但也有很多人希望他就這樣不要變動了。重點是，這二種人有時可能是同一個人…Orz
所以說，版本升級是一個軟體，特別是受歡迎軟體的共同問題，但Java的問題沒有特別嚴重。
我再提一個關於銀行的例子好了。很多銀行的主要系統可能已經穩定下來了，功能面看起來也沒有很大的問題，照理來講應該就不用去動他，那何苦還要去升級、勞師動眾去修改自己的code以配合新版本的Java ?
原因是EOS，也就是End of Service。以市佔率最高的IBM WebSphere Application Server (簡稱WAS)為例，今年WAS5的維護合約就要到期，也就是說以後銀行有任何關於WebSphere 5版維護面的問題，IBM都不支援。對銀行來說，要嘛你就給他放著不動，可是誰敢這樣作？出了問題誰負責？所以剩下的選擇就是升級到新版，而新版的WebSphere 6.1預設是用Java 5 SE。也許WAS上可以設定改用舊版的JVM，但是在所有相關配套產品與第三方Library都逐漸改成支援新版(甚至可能不支援1.4之前的JVM)的時候，請問銀行要怎麼選擇？到底這樣算是「追逐新版」還是「不得不為」？
還有Qing內容有提到說「你沒有必要苦苦追趕Third party程式庫的新版本。」當你不得不升級JVM的時候，Third Party程式庫的版本問題也就跟著來。我之所以會說Java版本出太快，就是因為現在很多銀行還在用1.4，還沒升級到5.0，但是Java官方已經出到6.0了。如果這個第三方程式庫5.0的版本有問題，Third Party把大部份心力都放在開發6.0版，但6.0版銀行又還不能用，那這問題要怎麼解決？
針對Mr. Saturday的文章，我有些想法，可能要等比較有時間再回覆了 XD 但是針對Mr. Friday的留言，我還是不認為這個例子舉的好 :p 我想問的是，從這個銀行昇級的例子來看，JDK 1.4 到現在是歷經了多少年的時間呢？在這麼頻繁的改版過程中，又是經歷了多久才讓銀行面臨到這個抉擇？
我並不明白IBM之所以不再維護WebSphere 5的原因為何，如蒙賜教不勝感激，不過我們可還是在為我們的客戶維護著JDK 1.3上的產品啊 :p
To Qing,
IBM的EOS規定可以看這個網頁
http://www-07.ibm.com/tw/support/tsc/eos/w.html
這裡面寫到的Websphere 5 EOS日期是2006/9/30
客戶可以付費再買2年的原廠維護 - 那就是2008/9/30到期。
WebSphere 5從表上看來是2002年的產品。不再繼續維護舊版應該是IBM的策略，一方面半強迫客戶升級，一方面對維護人員來說也是學新產品新技術的機會。
To Qing,
至於你說升級到1.4花了多少時間，我只能說很久，沒辦法給你很確切的時間範圍。從1.2到1.3甚至有客戶是花了半年以上升級然後失敗的。不只是JVM換版本，上面的Library合不合，相關的軟體會不會踩到deprecated甚至是defect，踩到了之後等patch…
幸運的三個月勉強可以，不幸運的花一年都沒解。我現在這家客戶是去年年初才升的，相關的問題都還沒完全解完〈調了某些參數以後可以跑，但問題根源找不出來總是讓人不安心〉。今年下半年又要再升一次，而且還只是升到Java 5.0版。你覺得我舉的例子不好，也許是我表達有問題吧。但是我看到的現實是這樣。
To Mr. Friday,
對，所以這是我想表達的重點。以這個例子來看，讓銀行客戶感到挫賽的應該是IBM的責任佔比較多。
To Qing,
我反而不覺得這可以完全說是IBM的問題。一是我相信這問題應該不只WebSphere會有，應該全部的廠商或多或少都會遇到。二是我所提到的客戶例子，問題應該在JDBC，但Database是Oracle的，那這個問題依舊算是IBM的錯嗎？
這我是覺得有些奇怪！IBM要EOS，那是他們廠商與合作夥伴之間的問題，有時大廠為了營收或其他政治性問題，挾持用戶作出他們不想作的事（昇級），是很常用的手法，那麼，這是那些廠商的問題，而不是Java的問題吧！
我本來不想昇級，因為A廠商要挾我要昇級，我就怪B廠商東西不好，讓我不好昇級，這好像有些奇怪！？
當然，如果是A、B兩廠商是處於競爭狀況，A廠商為了要逼迫B廠商的市場！這就可以理解了。。一句話，誰叫你不全用我的解決方案。。
最好的工具或語言，不見得是市面上最廣泛使用的，市場、行銷、政治因素等都要考慮在內。。。
如果今天是要討論Java本身的好或壞，不要把這種廠商之間的服務關係扯進來，會不會比較好，不然好像會失焦。。
我覺得這篇中討論的版本問題，還有Mr. Friday舉的銀行例子，已經有些偏離Java本身的討論了，變成討論廠商之間的競爭問題，我還是比較贊同qing的觀點。。
To 良葛格，
呼，再講下去我自己都累了，反正我的意思應該都回得差不多了，寫完這篇回應應該就不回了。
如果語言優劣可以不要把版本控制與廠商競爭扯進來，那就真的太好了，但是實際上很困難。正如同我一開始引用systemanalyst的話:
「當我們在談論一個程式語言時，我們必須要從整個軟體工程的角度來看。Java不只是一個語言。當你看著Java時，你必須包含整個平台來看。」
這平台的提供者，可能是Sun，可能是IBM，可能是BEA，也可能是其他廠商。Java新語言制定的速度與修改的內容，會不會影響到這些廠家的競爭關係？廠家間的競爭關係〈以及相容性問題〉，會不會影響到Java平台在企業間被接受的程度？如果以上問句的答案是Yes〈至少我認為是〉，那為什麼不能放在一起討論？
純論語言特性，也許Java今天不會這麼流行。相關平台業者的廣度、支援能力都是重要原因之一。如果討論Java未來會不會繼續流行下去，我相信廠商競爭這一塊也是個重要因素。
版本升級絕對是政治上的問題了，只要你要賣錢這就是問題。
我手邊還有銀行是用jdk1.1.8的版本，也還在維護。
因為版本更新是很大的問題，所以你要如何對客戶說你手邊的AP Server (ex WebSphere) or JDK(ex 1.1.8)已經out of service了，而且客戶會接受。
如果客戶不接受（通常因為還沒上線，那個產品就要EOS了，IBM有產品剛上市兩個月就排定18個月後該版本EOS，很不幸兩個月內用那時候最新的版本拿到新案子，我就有遇過這種雜碎事情），而且因為更改新版本需要全部重新測試，我們上次重新測試全系統用了超過百人的測試大軍，測了一萬個defects。
不過版本問題不是Java的問題，今天用COBOL寫也是一樣。只是Java有個特點，他的版本更新快，改動的幅度又大，很有可能讓舊程式完全失敗（尤其是該死的Swing）。
「當我們在談論一個程式語言時，我們必須要從整個軟體工程的角度來看。Java不只是一個語言。當你看著Java時，你必須包含整個平台來看。」
我以為，您所謂的平台是指軟、硬體上的平台，如果真要把廠商的競爭關係也算在平台上，真的會扯不完（而且軟體工程的東西，會討論到什麼SUN、IBM、BEA嗎？我不記得有看過！），因為，會造成今日Java問題的，本身就是那幾個大廠，一堆標準的制定，就是靠著那幾個大廠決定的，當初決定標準時，就是一場你爭我奪了。
如果從這個角度來看，要讓Java生或Java死，不是有沒有新工具的問題，如果今天各大廠想要讓Java死，只要在最初制定標準時下毒藥就好了，不用等到別的技術來取代。
我不否認「廠商競爭」是很重要的討論話題，也會是工具將來在市場上活不活的下去的因素之一，不過，討論廠商競爭，就等於討論商業手段，我的論點就是從這出發的！如果今天大家想討論的是這個，那就不是討論技術，而是討論商業了！
從技術面，會有技術面該討論的問題，以談論工具好或不好；從商業面，就會有商業面的問題，討論什麼手段可以逼對手退出市場！
我舉個實際的例子，我有一個很爛的產品，因為用了某個商業手段，結果在市場是採用率最高，你怎麼說？（該產品在市場上絕對有很多東西可以取代它，什麼產品我就不便講了！）
同理，某個工具是否存活於市場上，與該工具是不是好工具，並無絕對關係！一開始的文章其實是從技術面討論起的，結果現在轉移到商業上，我只覺得在失焦了。
不曉得 MMdays 能否討論一下
假如新版本需要更改整個架構
版本升級與再寫一個新系統那個會比較好？
以及如何去評估改舊的、寫新的哪個好？
回應”版本控制，版本升級是不是個問題？”…
在前一篇「 關於 ”Java 即將變成另一個 COBOL” 這篇文章 」之後， Mr. Saturday 也針對其中的「 Java 版本發行速度太快」這個議題發表了 ” 版本控制，版本升級是不是個問題？ …
也舉銀行當例子好了
我公司的客戶(們) 他們的運作規則大概是這樣的
買系統（建置系統）的時候 會要求廠商用當時最新的穩定產品
等系統上線之後 除非『絕對必要』 上線產品當時的所有系統環境，就會是這套系統永遠的環境，直到系統消失。
追平台的版本？ 想太多
廠商說產品EOL，繼續用到不能用為止
10年 20年的系統 從來沒升級過的 在銀行比比皆是
對他們來說 開門做生意 IT系統只是支援性的系統 能用 夠好用 夠重要 沒有人會去動它 也沒有人想去動它 因為 沒有人願意承擔萬一系統停擺 讓公司不能賺錢 甚至賠錢的風險
另外 談到COBOL 小弟對JAVA跟COBOL都是完全的門外漢 我只知道一件事
台灣 2000年以來 有換核心銀行系統的銀行(8家) 所採用的系統 只有兩家不是用COBOL寫的 這兩家 很剛好 都很小 一個用JAVA（嚴格來說，應該說是ORACLE） 另一個用.NET 其餘六家 有四家在台灣排在前10大
而且 現在的COBOL 也算是個VM 也可以Write once run everywhere 也支援HTTP,XML,COM等介面 (有興趣請參觀acuCOBOL)
步入COBOL後塵 好像是說COBOL已死 但實際上COBOL活的很好 以一個Business Oriented Language來說 應該可以說無人可出其右
COBOL已死？我們只是不在它的世界而已吧
最後 說個追版本的小故事
某銀行的某一個關鍵系統 原本用JDK 1.4開發 UT UAT都完成了 結果開發廠商 的技術頭頭發現 1.5的效能比1.4好很多 而且架構也比較漂亮 然後他們就很神奇的的更換了JDK。到上線的那一天 well，直接跳到結論，效能的問題根本不在AP，是DB架構太….。 取得這個結論的花費，應該有3千萬吧。 追版本對嗎？ 追版本不對嗎？ 我不知道 我還在寫C跟Delphi。
Java會步上COBOL之升級是否為問題…
最近正熱的議題?其實我怎麼覺得好像在半年一年多前就有國外媒體還是誰提過?所以已經有點冷感了。而小弟本身就是資訊焦慮者，每次遇到升級就會非常想幫手上的東西升級(…
給一個我跟銀行主管交涉的例子，的確EOL是關鍵，但是他們為了確保投資值得，會要求這個時間最少是十年，所有的3rd party程式也都能確保有十年的生命期。
有點規模的銀行（台灣沒有見過），甚至要求每個3rd party程式資料庫都要被檢查，而且要求廠商提出十年的保證期，不然不能使用。
當然，這已經不是Java的問題了。
最後，雖然我認為Java的版本更新是問題，不過只要沒牽扯到UI，基本上沒大問題。主要的問題都是發生在Swing上面，要是你夠猛用AWT寫各種元件（如tree, table），那可能改版的陣痛會少更多，我也遇過這種專案，可惜後來找不到人要維護，寫程式的人可能已經變總經理了，新人根本不可能會AWT。
要記得對客戶來說，UI才是大問題，後方的計算要錯還真是難。
最後，那個換核心系統還用COBOL的問題是單純政治。COBOL沒死，而且沒有凋零，因為這一換的生命週期最少是二十年。
”版本控制，版本升級是不是個問題？”後記…
在我寫前一篇文章時，其實我猜想 Mr. Saturday 應該就是任職於某公司，因為從他的文中所描述的情況，大概也沒別家公司了 XD 這 .. 不管我有沒有猜對， Mr. Saturday 都不要打我啊～ 說…
就我看了那麼多留言, 大家的立場、所屬公司、參與過的專案都不大一樣, 而重點就在於大家都以自己的立場為出發點, 所以造就一連串發散的討論。
[...] Mr./Ms. Days (MMDays) - 網路, 資訊, 觀察, 生活 - [MMDays 專欄] 版本控制，版本升級是不是個問題？ http://mmdays.com/2008/01/04/programming-language-version-control/ [...]
[...] Mr./Ms. Days (MMDays) - 網路, 資訊, 觀察, 生活 » Blog Archive » [MMDays 專欄] … [...]