文：浩華@HelloWorld!
最近看了黃世澤的「AutoTrac 3 程式設計傻的嗎？」，看後實在嚇了一跳，筆者似乎把軟件質素問題歸咎於程式語言選擇問題。小弟雖然都同意 Auto Trac 3 問題多多，但因為一套有問題的軟件而把一個程式語言打上一個大交叉，實在以偏概全又誤導對電腦系統不熟悉的普羅大眾。
問題不在 Java
Java不只是在AutoTrac3 或政府的舊系統中，稍為對Android開發有半點認知都知道，Android 程式編寫語言最初便是Java，到現在最新的Kotlin 都是與JVM 百份之一百相容的程式語言。難道大家又每兩星期重新啓動一次智能電話嗎？難道用家使用程式不爽的時候又把怨氣發洩到Java身上嗎？十居其九當然是聯想起製作軟件的軟件工程師吧。就當是因為Android 運行的是Android Runtime 並非 JVM，哪其他分佈式大型軟件呢？由處理大數據的Hadoop和HDFS軟件到搜尋軟件Elastic Search 及 Devops 軟件 Jenkins都是用 Java 編寫並用JVM運行，難道這些軟件又因為使用了2.5GB記憶體便每隔兩星期重新啓動嗎？哪全地球的軟件又要因此重新啓動多少篇？
記憶體洩漏非Java獨有問題
有些人會問 Java 已經有垃圾回收（Gabarge Collection）還會有記憶體洩漏（Memory Leak）的問題嗎？當然會有！可是涉汲技術細節太多，有興趣的可以搜尋過期對象引用（Obsolete references）。假若用其他語言編寫同樣軟件的話問題同樣有可能存在，關鍵並不是否用 Java的問題，而是軟件工程師在開發階段有否小心避免有蟲的程式及在壓力測試時有否發現洩漏問題。一句到尾，記憶體洩漏是軟件開發團隊要面對的難題，並非飲鴆止渴轉用其他語言就能解決的問題。如果一個工程師說改用其他程式語言就把記憶體洩漏問題搞好，那麼他不是好歹有限就是以為上司是傻的。
一台機器死掉不等如系統死掉
拜托了，分佈式系統理論已經是半世紀前的產物。即使一台電腦真的因為2.5GB的記憶體上限雖要重新啓動的話，按道理系統應該是可以依靠 Fail Over 維持應有服務，即是在重啓前臨時轉移到另一套相同系統的電腦。行內行外對現代的實時系統都要求高可用性（High Availability），如果符合不到的話，系統擁有單點故障（Single Point of Faliure, SPOF）的缺陷。單點故障的壞處相信各位讀者都知道，只要有其中一個電腦當掉，也會對用戶造成災難性的事故。要使系統達到高可用性應從系統設計出發，即是在軟件項目的起初設計階段已經要達到的基本要求，根本和使用哪種程式語言無絲毫的關係。
AutoTrac3 的問題眾多，把問題歸究於Java是無知的說法。事件發展到這地步，皆因軟件開發流程出了嚴重問題，由系統設計，硬件採購，程式編寫，質素監控到民航處以什麼準則，驗收測試及考慮理由決定以天價買入AutoTrac 3。以上問題全部都汲取人為因素，立法會有責任徹查，而有關當局必需負責並且向公眾一一交代。
（作者為資訊科技界選委，以上只代表筆者的個人意見）