JavaOne 2015概覽

Wielenga：NetBeans的主要功能是可以將世界各地的開發者連接在一起，共同解決技術難題。例如，NetBeans可以在使用 AngularJS和其他JavaScript框架的時候，為開發者提供即開即用的工具；也可以在使用JavaScript、CSS和 HTML的時候，為開發者提供高級編輯器。而且在NetBeans中也有專門為谷歌Chrome瀏覽器研發的插件，讓谷歌Chrome瀏覽器可以和 NetBeans進行交互。例如，當NetBeans發生變化的時候，也會立刻在谷歌Chrome中進行更新；當你點擊谷歌中的app應用時，不管是在 PC端，還是在移動端，你都可以看到被NetBeans定義的相關DOM（Document Object Model：文檔對象模型）元素在哪。不僅如此，NetBeans還集成了Cordova的許多功能，可以在以下鏈接中具體了解：

https://netbeans.org/features/html5/index.html

如果你在一個快速響應的工具中下載了綁定NetBeans IDE（Integrated Development Environment：集成開發環境）HTML5/JavaScript客戶端，那么所有的一切就都可以免費使用。

https://netbeans.org/downloads

Wielenga：JavaScript的生態系統是非常容易變化得，在新的技術到來的時候，JavaScript也會隨之不斷地發展。盡管你需要非常仔細地考慮在JavaScript生態系統中，哪一部分是你所需要的，并可以穩定使用，但是你仍然能夠在其中開發出有意義的應用。

Paumard：這兩個API都是流的一種。簡單來說：Java 8 Stream API是關于流，RxJava是關于反應流，這就是他們的區別所在。除此之外，這兩種API都允許寫入數據處理管道；都可以在同一時間消耗來自不同來源的數據，并連接到自定義源。兩者之間最大的不同是在J8環境中，當數據管道從數據來源拉取數據時，RxJava實際上是通過監聽產品，來監聽那些能獨立產生數據的來源。這樣就給數據處理管道的設計帶來了新的問題。主要問題就是：如果我們的數據處理管道速度不夠快，或者不能消耗所有產生的數據，那么會怎么樣。這樣就引入了背壓問題和一些不同的解決方案。我們可以結合Java 8 Streams和Java 8 CompletableFuture，并通過使用JDK 8搭建響應式流。這樣就可以提供我們所需的一切了，然而實際搭建起來卻非常困難，因此我們必須要有更簡單的模式來構造我們的應用。

Paumard：目前圍繞反應式流已經提出了不少的想法，RxJava就是其中的一種，當然解決方案肯定不止這一種。目前我們嘗試在JDK中創建 Reactive Stream API，不過可能要到Java 9中才能實現。我將會在另一次談話“Java反應式編程”中描述這些API。Java 9將會提供一個接口的通用設置，并且讓其中的一些類實現了響應式API的互用性( http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ 然后尋找Flow類)。正如我一直所說得，我不推薦在Java中使用RxJava，因為這些基于10k行代碼和250種方法類的API過于復雜。因此顯而易見，我們離所謂的“整潔代碼”還有不小的距離，而且靜態方法的大量使用也使得測試工作完全是一場噩夢。實際上，RxJava是.NET API的一種復制。作為復制版本，其中當然會有不少的缺點。其中之一就是，在一些用例中RxJava可以高效使用，但是在另一些其他的用例中則不行。簡而言之，反應模式帶來了現代應用中需要的許多東西。但是它仍然在進步，一些常見的問題仍然亟待解決。新的工具正在發展，作為開發者或者應用架構師，我們一定要抱著發展的眼光來看待這些。

Paumard：對于他們宣布近期轉向反應式架構的舉動，我一點都不感到驚訝。因為Spring團隊一直都是新編程框架的引領者，他們過去的成就也向我們展示了他們有創建這種新框架的能力。在微服務中，反應式架構的效果很好，可以為我們提供了一個簡潔的設置模型，來幫助融合、鏈接和組合微服務，并且為我們提供非常好的方法來處理異常。背壓一個很難解決的問題，會在每個用例基礎中被處理。我非常確信將會在未來看到更多關于這個主題的創新。

Gee：這不是我所能想象得！Java 7的生命已經結束了，相對于Java 8來說，Java 7不具備任何優勢。但是，我看到很多的開發者仍然在局限與Java 6之中，因為對于一個技術團隊來說，為了不承擔風險，他們對新技術的態度仍然比較保守；但是我也看到了許多的團隊直接從Java 6完成了到Java 8的轉變。

Gee：這是一個普遍的誤解，我已經開始后悔使用這個作為我談話的標題了，在這里并不是“憤怒"的意思，而是表示”在實際生活“中，這是一種英式表達，但是可能即使是英國人也不是都了解這種表達方式！這次談話的目的是展示Java 8在完全運行的APP中的實際使用，而不是僅僅展示"這是lambda表達式"或者”這是一個流“之類的抽象功能。

至于Java 9當然會加入有不少有趣的新概念，但是我懷疑它對于日常開發的影響和沖擊會比Java 8小很多（但話雖如此，Java 9應該會增加不少的Streams API，肯定會解決我現在不喜歡使用流的問題）。

Gee：我想要人們了解到得是開發者在工作中對這些新特性的看法。不僅是學習到了新的語法，而是知道在什么特定的情況下使用lambdas表達式和流，并且改變開發者的思考方式。我也想看看你們是會覺得Java 8的解決方案更好，還是傳統的方法更簡潔、容易理解。最后，我希望你們的IDE（我當然是指IntelliJ IDEA！）能幫助你們從傳統的工作方式轉變為使用新的功能。

Pericas-Geertsen：MVC 1.0是一種標準API，因此未來將會變成JavaEE 8的一部分，并被多個供應商支持。因為MVC 1.0是基于已經被許多開發者普遍使用的JAX-RS API。

Pericas-Geertsen：當談及WEB UI框架的時候，并沒有一種萬能的解決方案。就像已經有報告稱，目前已經有公司在把服務器端框架遷移到客戶端后，發生了一些執行錯誤，因此不得不又遷移回服務器端。這就說明，雖然基于JS的客戶端框架雖然非常好用，但是我相信在未來服務器和客戶端這兩種框架依然會共存。這完全取決于哪種工具更適合開發者使用。

Pericas-Geertsen：我希望開發者能夠了解3點：1.MVC 1.0的基本原理；2.MVC 1.0和JAX-RS的關系；3.MVC 1.0的可擴展性。當開發者足夠了解MVC 1.0之后，就可以考慮在下一個項目中使用MVC 1.0框架了。

Mann：我不認為這是一個二選一的命題。JavaEE MVC是一個行動導向的框架，就像Spring MVC一樣。對有些技術團隊來說，他們偏愛傳統的行動導向MVC框架；但是，對于另一些技術團隊，面向構件的MVC框架也是一個很好的選擇。而且，如果由于某些原因你需要同時使用這兩種架構模式，也是完全可以的。最初，我們考慮的是在JSF上面構建MVC（這是完全可能的)，但是后來決定把兩種模式分離開來。

Mann：我已經在這個行業干了很長時間了，了解軟件架構的發展方向經常是搖擺不定的，當然這樣也可以讓我們更加深入的了解所用框架的利弊。可以肯定地說，永遠都不會有一種萬能的架構模式，同時適用于所有的案例。當你把所有的框架都放在服務器端時，必定會限制你在瀏覽器上的操作空間，而且對硬件的需求也會非常大；同理，當你把所有的框架放在客戶端，雖然會讓你有更大的操作空間，但對客戶端的負擔也會更大，而且很難同時滿足不同瀏覽器的需求。我認為折中的方案應該是，比起使用純粹的JS框架，應該盡可能多的增加服務器端架構，當然也不要完全使用服務器端架構。然而無論怎么說，最主要的一點是要讓 JavaEE平臺盡可能多得支持更多功能。

Mann：MVC開發模式的優勢在于它本身就是基于JAX-RS的基礎之上搭建的（最初我們是打算把它作為JAX-RS的一部分，但是JAV-RS EG希望把兩者分離開來）。因為它實際上是JAX-RS頂端的一層。所以你能輕易地把純REST服務和具有操作路徑和返回視圖特點的web app進行混搭（這些在Facelets, JSP或者其他技術中都能得到運用, 例如Velocity和Thymeleaf）。這樣就可以允許你把服務器端模板和數據綁定技術運用到其它有意義的地方。

Marsh：Asgard（AWS云管理和應用部署的WEB接口）作為最強大的云部署工具，已經有許多年了。現在，我們在Asgard的基礎上研發出了新的部署工具。這個新的部署工具實際上是一個持續交付平臺，而不是一個純粹的部署工具。在管理工作流的時候，這將會是一個功能非常強大的工具。可以讓我們在未來的一段時間里拭目以待。

在監控方面，Atlas工具也是非常的不錯，但不是所有人都需要這么復雜的工具。我認為其中最核心的是Janitor Monkey，它可以在云服務幫助下清理不用的進程并管理消耗-這就不需要我們自己主動去清理不用的進程了。

Marsh：系統管理員跟那些部署和運行自己編寫的服務的開發者相比，所做的工作是完全不同的。例如，系統管理員是需要管理第三方工具。而且開發者運行自己所開發的工具時，很顯然會比使用那些他們即不能查看代碼，又不能修復Bug的工具要容易的多。

Marsh：DevOps是一個重載術語。就如同之前的敏捷開發一樣，我要小心別把它們混淆在一起，我們需要假設它們都是同等重要的。通過從這次談話中，我最希望開發者可以借助這些工具，幫助他們了解他們的服務到底是如何運行的，并且認識到這些工具可以讓他們的企業獲益。

Gaur：物聯網云服務是一個新增的Oracle PaaS（Platform-as-a-Service）組合。Oracle物聯網云服務能夠使用戶牢固地連接上任何設備，執行及時和預測性的設備數據分析，拓展企業應用中的業務流程。并且為了預防性維護和資源追蹤，可以通過Oracle PaaS讓物聯網應用在高速發展中使用預構一體化。其中，Oracle和第三方SaaS應用包括JD Edwards的Oracle E-Business Suite和Oracle Fusion Applications。

Gaur：物聯網是一個擁擠的市場。目前已經有了不少的點方案供應商，但是Oracle在許多方面都是獨一無二的，自身有很大的優勢：

a）平臺：在眾多企業之中，Oracle是唯一一個可以提供完整的一體化平臺的供應商，其中涵蓋了：智慧網關，設備連通性，安全性和企業應用全方位的分析。物聯網CS架構能夠為許多的企業應用提供即開即用的連通性來進行物聯網應用的快速開發。

b）設備虛擬化：首先，它可以讓你連接其他公司任何設備。我們把拿出每一個設備都看做一套簡單的API。這就意味著像CRM系統和服務云一樣企業應用，可以直接跟這些設備交流，而且不用擔心類似于傳輸協議和短信格式之類的技術上細微差別。

c）安全性：安全性毫無疑問是最重要的部分。Oracle物聯網云服務會把設備當做是第一級成員（就像APP或用戶），并且保障端對端的安全性。

d）分析性：Oracle物聯網云服務能夠為設備數據提供實時，并且基于歷史和大數據的預測性分析。這可以使客戶了解設備中數據的流向，識別關鍵模式和異常，并且驅動決策。

Gaur：在這一塊，我們主要是面向企業服務的，就像產業制造、運輸和物流一樣。當然，我們也會為客戶和合作者提供免費的試用來體驗物聯網云服務。當然了，我們的物聯網云服務許多技術組件都是開源的，其中包括物聯網云服務的客戶端庫。

Shmeltzer：我這次的談話主要是關于Oracle MAF框架（Mobile Application Framework：移動應用框架）。這與你之前所用的TAP框架比起來的話可能會是一次技術革新。MAF是基于MVC框架，并運行在Java開發的設備之上。你可以使用XML來定義的視圖，并且可以通過HTML5技術呈現出來，你也可以使用Java來編寫你的控件和模型層。

你以此開發的APP應用不管是在Android還是iOS設備上都可以運行。Oracle內部已經使用MAF框架開發了超過100個這樣的APP了，并且都已經在iTunes或者Google應用商店里上線。

Shmelter：目前世界上已經有了成千上萬的Java工程師，我們現在所做的是讓他們可以繼續使用已有的技能，來進行移動端的開發。你所使用的語言是你了解得（Java 8），你所使用的IDE也是你熟悉得（Eclipse或者JDeveloper），就連框架也是你所擅長得（MVC，POJOs，基于UI定義的組件）。

對投資Java的IT應用商店來說，我們已經為他們解決了技術上的障礙，讓開發者可以利用已有的資源進行移動APP的開發。

Shmeltzer:如果你是一個Java開發工程師，現在已經有了一個解決方案，可以讓你利用目前已學的各種技術，無縫轉變到新的移動設備開發當中。

Laforge：坦率地說確實有一定的關系，因為我們可以清楚地看到類似于New York Times這樣的Android app，已經在Apache Groovy上被成功重寫了，我的博客中也進行了解釋：

http://open.blogs.nytimes.com/2014/08/18/getting-groovy-with-reactive-android/

間接來說，因為Android工程師開發APP所用的自動化工具，是Google選擇用Gradle來構建得。而Gradle上用來做DSL開發得則是Groovy，因此自然越來越多的開發者都開始了解Groovy。

但是更重要的原因是，許多的公司和項目都開始轉向使用Gradle。因此除了Android之外，我們把Gradle看做是促使Groovy普遍使用的關鍵因素。

最后但是很重要的一點，我也認為把Groovy遷移到Apache Software Foundation上本身就有很大的吸引力，因為開發者們知道Apache Groovy經過了長期運行，技術上已經十分成熟，因此會被廣大的開發者們所信任。

InfoQ：你能分享你認為最重要的三點，可以更有效率地使用Groovy嗎？

Laforge：如果只能挑選3點的話，這就比較難了！

1）第一，你可以使用Java開發的方法，因為Groovy是Java的一種超集。但是當你學習Groovy的時候，你要逐步的學習新的技巧來使你的代碼更簡潔，表達更清晰，也更健壯。

2）第二，學會使用GDK（Groovy Development Kit：Groovy開發工具）。Apache Groovy會提供海量的API和方法來修飾JDK class文件，這些都是很有用的，能夠提高開發效率。

3）最后但是很重要的一點，是類型協議的概念。你可以在任何地方使用“def方法”，把變量、參數、領域等定義為動態類型，但這并不是一個很好的做法。你需要給所用的API一個清晰的協議。因此當申明變量、參數、領域時， 你需要使用合適的類型。這樣可以幫助你增強與Java的互用性（當你在同一個項目中混合使用這兩者語言時），可以幫助你進行記錄（考慮到 JavaDoc/GroovyDoc），你的編譯器在這種編寫方式的協助下也會更容易使用（導航，代碼補全，潛在問題等）

你也可以使用@CompileStatic或者@TypeChecked上的注釋，來對你進行幫助。

Laforge：我認為不同的人會從這次談話中會了解到不一樣的東西，希望那些經驗豐富的Groovy開發者可以學到一些新的Groovy開發技巧，讓他們能夠在開發時使用；而對于那些剛接觸Groovy的開發者來說，我希望他們能看到Groovy的強大功能；而對于那些對Groovy持有懷疑態度的人，我希望這次談話能夠改變他們的看法，認識到Groovy在提高效率，代碼可讀性，健壯性和領域特定語言（DSL）上能夠提供很好的幫助。

我相信對所有的人來說，都可以從這次談話中學到一些有用的東西。

Bucek：根據瀏覽器和客戶端的支持情況顯示——websockets具備一切所需的功能，你可以在任何情況下使用。在必要的時候，有一些框架甚至會效仿websocket連接使用長輪詢，但是我認為這些并不重要，因為即便如此開發者也不會去使用這些框架。

不過當涉及到后臺基礎框架需求的時候，websocket與所謂的“標準”應用可能會存在一些不同，但是如果后臺能夠支持https協議或者提供一些其它更持久的連接的話，那么這些就不再是問題了。

Bucek：我認為這種說法是無稽之談。REST框架已經被應用在簡單而高效的“RMI遠程引用層(Remote Reference Layer)協議”之中，目前為止，我還沒有見到任何可以取代它的東西出現。

“響應式API會變成未來發展的主流”——根據目前基礎結構的發展來說，我是同意這個觀點的。如果你想做異步開發，當然希望接收到得不止一個響應——REST客戶端是把所有的響應融合，并且基于所有接收的響應來產生一個響應——這些可以在響應式API的幫助下非常容易地實現，而且不會有任何阻礙和額外的線程，也不必考慮同步問題。

Bucek：

• WebSocket和REST并不是相互競爭的關系，他們是互補的。
• 如果你需要更有效率的雙向交流，或者是減少瀏覽器（或獨立應用程序）的反應時間，你應該考慮使用WebSocke協議。
• WebSocket并不會被HTTP/2所取代。