Xexex's Java 和其他二三事

Facebook 將自己的未來賭在 HTML5 上，這是他們合理的選擇，不過，他們大概也只有這個選擇，畢竟通路 (作業系統/瀏覽器) 都不在他們手上。然而這個純 web 的選擇對他們來說也是困難重重：

Facebook vs. IE

Facebook 和微軟是友好的 (而且擁有股權)，IE 的市佔率也夠高，但是 微軟 對 HTML5 的支援總是心不甘情不願，功能少又落後。因為微軟骨子裡就不希望 web 起飛，不然會傷害到 Windows/Xbox 的業務。因此 Facebook 很難從 IE 上發展出他們冀望的功能。

Facebook vs. Chrome

Chrome 提供最先進的 HTML5 支援，但 Facebook 和 Google 是死對頭，也就是說當 Facebook 希望 HTML5 加什麼功能，以強化他們未來的使用體驗時，Google 這第一關就過不了。

Facebook vs. Mobile

Mobile 瀏覽器市佔不斷的上升，未來的趨勢不可擋，但是目前市佔最高的是 Apple 的Mobile Safari。但 Apple 和 Facebook 交情可爛了，之前 Apple 和 Facebook 曾合作在 iTunes 上推出 Social 的功能 "Ping" ，但最後 Facebook 單方面的 bang 掉iTunes，氣炸 Apple。後來 Apple 上的 iOS5 就只整合 Twitter，而不是 Facebook。而 Facebook 現在也進軍音樂界，正式成為 Apple 的敵人。你說 Mobile Safari 的發展會理 Facebook 嗎？難喔。而 Mobile 瀏覽器第二把交椅則在 Google 手上，理由同上一點，死對頭無解。

Facebook vs. Firefox (Mozilla)

Firefox 和 Facebook 沒有什麼交惡的紀錄，因此 Firefox 是 Facebook 最後的希望了。我個人預測未來 Firefox 和 Facebook 會有結盟。比方說 Firefox 首頁會變成 Facebook (就像 Firefox 的搜尋內建的是 Google，然後 Google 會付錢給 Firefox)。如果雙方合作順利，Facebook 希望的 HTML5 新功能，Firefox 方就會投贊成票。唯一的問題是 Firefox 市佔正在下降，而在 Mobile 更是能見度零。

☘☘☘

Facebook 的賭注放在 HTML5 上，但是卻無法自己推動改革，只能等別人施捨，我不能說 Facebook 會因為這樣就做不出好產品，但初期的發展肯定處處碰釘子，功能受限的。

Google 推出了 Google+ Page 了，有不少人提出改進的建議... 不過我覺得加強、補足功能什麼的都是其次。因為真正的問題在於 G+ 的成長受到了局限。如果 G+ 的用戶持續成長，廠商看到了人潮，即使 Page 功能再陽春廠商還是會辛勤的更新。看看 Twitter 就曉得了，Twitter 哪有什麼廠商專用的帳號？但是商用的帳號還是超多，更新也很頻繁。G+ 的 Page 成功與否還是在 G+ 本身活躍程度。

G+ Page 的推出也突顯了 G+ 另一個發展缺失 － Me too feature。G+ 現在有 #Hashtag，也有 Page，這兩個功能非常有特色，然而都是抄來的。抄來的沒關係，只要整合的更好就是一百分。Hashtag 在 Twitter 上能夠發展起來可說是水到渠成。140字過短但又想加標題、歸類，怎麼辦？於是用戶想出 hashtag 法寶，而最終也獲得官方支援，更進一步成為 trend。而 Facebook 很需要 Page 因為 Facebook 用戶的 Feed 全部是 private，只有親朋好友看的到。全部是 private 但大家又有共同關心人事物，於是便誕生 Page 滿足公開分享、號召的需求。

Twitter/Facebook 各自 自然的發展 出適合他們環境的獨特功能，但 Facebook 不做 Hashtag，Twitter 也不玩 Page，反觀 G+ 呢？照單全收，然後少了深度的整合。新功能像是畫蛇添足，無法引起共鳴，更別說讓用戶發展出更多有趣的應用了。G+ 如果發展得當，我們未來也會看見 G+ 獨有的社交互動方式，有可能是官方設計的，也有可能是用戶發明的。隨便舉例：比方說不是用 hashtag，而是直接用 circle aggregate news，你每天上來看 G+ 就看到不同大小的 circle 各自代表熱門的程度，而那些 circle 可能活動完後就丟了。又比方說不是現在看到的 G+ Page，而是 circle 本身就是 Page，使用該 circle 就是認同品牌，認同信念。..... 這些是隨便想到的，但我就覺得這樣有魅力多了。

Social 並不是只有 Twitter/Facebook 兩種型式，我很冀望 G+ 能走出自己的路，而不是看到別人有什麼就抄什麼。我想唯有如此 G+ 才能真正的成長。

Java 戰場一天不得閒，早先的 web framework 已經結束，喔，最少是沒人有興趣了。上一次戰很大的還有 closure，這也隨著 Sun 被 Oracle 買下後結束了。最新的戰場是改革 Java 語言本身。大家都知道在 JVM 上能跑的語言很多，多到滿出來了。不過，近來有個新趨勢逐漸成形，大家似乎了解到 "革命" 在這個圈子是不會成功的，尤其是面對那一大票保守、平庸的 Enterprise Java 開發者，而他們上面還有更保守的上司們。現在採取的策略是 "演進"，設計者不再熱衷創造很前衛的語法，反而盡可能的相似原有的語言，而且提供原本 Java 開發者就習慣的開發體驗 (i.e. IDE)。另外，與過去不同的是，這一次語言不是什麼某某某的回家作業，而是有組織的推動。

．Eclipse Xtend 2

這是最近剛推出的，不過並不是 Eclipse Foundation 主推的語言，而是 Xtext 計畫衍生的語言 （Xtext 是設計 DSL 的工具, Xtend 是為了產生 Java code 而特別設計的語言）

策略：static typed。Xtend 語言 compile 成 Java code，而不是 byte code。而產生的 Java code 可讀性很好。由於是Eclipse 旗下計畫，理所當然會擁有最好的 Eclipse IDE 支援。對於企業來說，導入的成本很低。

．Kotlin

今年 JetBrain 發表的新語言，目前還只在 JetBrain 內部開發。發展的目的是讓 JetBrain 的 IDE 賣的更好。（笑）

策略：static typed。主打新語言配合 IDE 的支援可以避免常犯的錯誤 (例如在 IDE 的幫忙下可以完全避免 NullPointerException)，這個語言自然會有 IntelliJ IDE 最好的支援。而為了推廣，他們也計畫開發 Eclipse plugin。

．Scala

從學術界起家的語言，帶有濃厚的學術色彩。很早就開始發展，可以說是 Java.next 的先趨，後來其他的新語言都受到 Scala 的影響。盡管發展的早，推廣還是很慢，設計者後來了解到要在 Java 界起飛必需具備優良的 IDE 和商業支援，因此成立 TypeSafe 公司，投入更多資源開發 Eclipse Plugin。但近一兩年飽受語言過於複雜的批評。

策略：static typed。Scala 訴求是 a scalable language。它融合物件導向和函數型兩大編程範型，使用者可以逐步轉換到函數範型，進而滿足在多核心時代 scale 的需求。語言的彈性極大，可設計出類似 DSL 的 API。

．Groovy

在 Ruby on Rails 發展時，搭順風車起飛的語言。後期由 Spring 主導和支援，而且有固定的社群，但是無法繼續再成長。事實上 Groovy 已經不在 Java.next 的行列了，列在這裡只是純做為參考。如果又有另一個新的 Java 語言跟 Groovy 的訴求一樣 （動態語言、但效能差，而且 IDE 支援弱)，那麼它是無法動搖 Java 界。

策略：dynamic typed。大部份的 Java code 都可以直接在 Groovy 上 compile，所以學習門檻最低，也可以設計 DSL。在 Rails 起飛之時，算是 Java 界對它做的回應。

．Dart

這不是 JVM 語言，不過它的目標是 Java 開發者。Dart 是由 Google 開發，企圖取代 javascript 成為新一代的 web 語言。過去 Google 曾致力於開發 GWT，但重心已經轉換到 Dart 上。目前已釋出 preview 版和 IDE (Eclipse based)。

策略：Dart 有自己的 VM，是 optional typed 的動態語言。optional typed 的意思是 type 只對開發工具有用，在執行期間 type 被捨棄了。雖然是動態語言但 Dart VM 是由原 V8 engine 的設計者開發，效能上不會是問題。它可以 compile 成 javascript 在非 chrome 的瀏覽器上執行。它將會同時佈署在 browser 和 server 上，取代 javascript 和 java 的地位。Google 為其後盾是其他語言無法抗衡的優勢。（個人預測 google 遲早會讓 Dart 在 JVM 上執行，或是讓 Dart 可 compile 成 java code)

．Java 8

Java 語言本身進程太慢，迫使市場自行衍生出各式各樣的 Java.next。不過 Java 語言最終也會跟上 Java.next，但會是最為保守，並且完全相容舊版，尤其是在 Brian Goetz 的領導之下。（Oracle Language Architect)

策略：Goetz 的做法是統計，他會統計開發者的意見來決定 Java 的新語法。比方說對於該不該去除 CheckedException，他統計後發現大家抱怨的其實是那一大串的 catch block，而不是 CheckedException 本身，因此最後 CheckedException 沒有去除，反而讓 catch 支援 multi-catch。而在 Java8 的 closure 語法上，他選擇了 Scala 和 C# 的語法，理由是它們的語法被廣為接受而沒有太多的負面批評。

結語

Java.next 的語法會和 Java 很像。因此各家語法的不會有太大的差異，發展的功能也會很類似：就是替 Java 加上 closure、簡化 getter/setter property、去除無謂的型別宣告、去除 CheckedException、替 collection 加入 map/filter/each、first class function、operator overloading 等等

如果和原來的 Java 語法差異過大，將會影響企業接受的程度，進而失去可能的 Java.next 寶座，這也是目前 Scala 很大的問題。