上周，Google團隊終于發布了J2CL框架的源代碼，自2015年以來就對此進行了討論。將Java轉換為JavaScript的想法根本不是什么新鮮事，而且每個人在使用Google Web Toolkit之前都遇到了麻煩該產品在社區中倍受關注-經過討論并成為會議演講的主題，但沒人能看到它 。

自首次發布以來已經有3年多了，而且該產品似乎甚至在其誕生之前就失去了市場。 今天，我們有了Scala.js，Kotlin.js和JSweet，此外，該開發已經由TypeScript占用，并且Java不再有地方了。 這么長時間以來，即使是最熱愛Java的人也對“ Java for Front end”失去了信心，并學到了一些JavaScript框架。

但是，由于它終于發布了，所以讓我們看一下結果以及將其用于什么目的。

理念

在全球范圍內，在瀏覽器中模擬JVM是一項相當復雜的任務。 Google Web Toolkit開發人員長期以來一直在嘗試解決此問題并取得了一定的成功：他們建立了一個編譯器，開發了標準的Java庫仿真機制，為應用程序開發提供了工具。

這種方法具有許多優點：靜態類型檢查，瀏覽器中服務器代碼的可重用性，以Java IDE表示的現成工具。 現在，TypeScript，Web Pack和其他前端開發工具中代表了GWT的許多內置方法。

優秀的舊版Google Web Toolkit因其笨重且抽象的UI構建方式而遭到反對。 J2CL的想法更簡單–它使我們能夠以最小的開銷將Java轉換為JavaScript，以便您可以輕松地從JavaScript調用Java，反之亦然。

即使在2015年末有一個非常不錯的從Java到JS的轉譯器，都可以在沒有哈希的情況下運行，但幾乎不可能假設Web開發會如何發展。

J2CL前傳

2015年初，Google GWT團隊做出了艱難而緊急的決定-開發支持Java進行前端開發的新產品。

主要是由于Web開發趨勢的變化及其新的內部客戶，他們將Java for Web視為不是孤立的生態系統，而是將其視為大型堆棧的重要組成部分。 它需要一種完全創新的觀點，并創建應該從頭緊密集成到其余生態系統中的工具。

使用GWT幾乎不可能實現這樣的目標。 盡管GWT具有與JavaScipt雙向交互的方式，但該框架無法擺脫UI，RPC庫和其他應用API的巨大負擔。

那是什么野獸

正如開發人員所聲稱的那樣 ，J2CL將Java代碼無縫集成到JavaScript應用程序中。 它代表了一個簡單輕巧的Java-to-JavaScript 編譯器 ，該編譯器專注于借助Closure Compiler進行代碼優化。

• • 在一個項目中輕松混合Java和JavaScript，以充分利用每種語言的優勢。

實際上，J2CL將源Java代碼轉換為沒有Java類字節碼JavaScript代碼。 這意味著，與Google Web Toolkit一樣，項目編譯需要所有使用的庫源。 此外，它提出了最新版本支持的Java語言功能的問題。 在此階段，開發人員承諾將支持Java 11的所有語法功能。

J2CL不支持GWT窗口小部件，GWT RPC和其他GWT庫，僅支持基本的Java和JavaScript集成工具JSInterop 。

也就是說，這是一個非常有限的GWT版本，帶有全新的編譯器。 并且由于新產品不再與GWT兼容，因此稱為J2CL而不是GWT。 總體而言，即將發布的GWT 3版本將代表基于J2CL的框架，其中所有適用的庫都將與翻譯器系統級別分開。

現有的Java兼容性限制在GitHub上進行了描述。 它們基本上與GWT中的相同-沒有反射支持，沒有網絡Java API。 但是也有一些不同之處–不會模擬數組和列表的語義，例如，不執行數組中索引的檢查。 開發人員重點放在JVM行為仿真上，而不是在語言的語法上，以最大程度地減少開銷成本并避免生成大量JavaScript以確保完全兼容性。

盡管J2CL已準備好投入生產，但其OSS版本離它還很遙遠。 例如， Windows上的項目啟動存在一些問題，開發人員無法保證穩定的API。

選擇Bazel作為內部Google產品的構建系統是很公平的，但是它對社區沒有任何好處，除了學習該構建系統之外，沒有其他方法可以使用J2CL。 同時，我們只能等待社區為Maven / Gradle制作插件。

開始工作

首先，J2CL需要Mac OS或Linux。

其次，您必須安裝Bazel –而不是Google制造的異國情調的構建系統。

現在，您可以從官方存儲庫中構建一些東西，例如HelloWorld。

> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld

當您查看輸出時，您會驚喜地發現：

> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js
document.write('Hello from Java! and JS!');

當然，它什么都沒有證明，但是很高興在所有GWT模塊之后都能看到如此的簡約。 沒有其他應用程序示例，因此我們將等它們顯示出來。

如果我們有xxx.js是什么意思

目前，很難說出它的用途。 乍一看，J2CL包含一個大膽的想法–以與TypeScript相同的方式將Java重用于前端。 另一方面，該項目似乎錯過了機會。

諸如Kotlin.js和Scala.js之類的新JS transpiler項目被實現為編譯器的插件，并且不需要源代碼解析。 從這個角度來看，J2CL落后了一步，因為它需要進行源分析。

還有一個問題是Java本身。 當您可以在簡潔的Kotlin上同時編寫服務器端和客戶端時，為什么還要使用冗長的Java？

但是，與另一個類似的項目JSweet相比 ，我更信任J2CL。 JSweet工具更友好，更實用，但是JSweet社區很小，幾乎完全由一個人編寫。

所以你說它是開源的？

該項目獲得了Apache 2.0免費許可絕對是一個好消息。

不幸的是， 開放源代碼與開放開發過程不同 。 社區最大的失望是由于當前的情況而出現的，J2CL項目是3年前宣布的，但是沒有人顯示其源代碼，您無法影響其最終API或加快開發過程，因為無處可發送修補程序。

讓我們希望情況會發生最好的變化，并且產品會投入使用。

翻譯自: https://www.javacodegeeks.com/2018/12/j2cl-better-late-never.html

總結

以上是生活随笔為你收集整理的J2CL –迟到总比不到好的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。