J2CL-絶対に遅かった

誰もまだ葬儀に遅れることができませんでした。

バレンティン・ドミル

先週、Googleのチームがようやく 2015年から話題になっているJ2CLフレームワークのソースコードをアップロードしました 。 JavaをJavaScriptに翻訳するというアイデアは決して新しいものではなく、誰もが長い間Google Web Toolkitでコーンを埋めていましたが、コミュニティはこの製品を他に類をみずに待っていました-彼らはそれについて話し、スピーチをしましたが、誰もそれを見ませんでした。

‌‌‍‍

最初の発表から3年以上が経過し、製品は生まれることさえなく市場を失ったようです。 今日、 Scala.js 、 Kotlin.js 、 JSweetがあります 。もちろん、Web開発はTypeScriptによってハイジャックされており、Java用のスペースは残っていません。 この間、多くの熱心なジャビストでさえ、「Java for Front-end」への信頼を失い、このJavaScriptフレームワークを抑制しました。

リリースが行われたので、何が起こったのか、誰に役立つか見てみましょう。

アイデア

基本的に、ブラウザでJVMをエミュレートするのは難しいタスクです。 Google Web Toolkitの開発者は長い間それを解決してきており、一定の成功を収めています。トランスレータを構築し、標準Javaライブラリのエミュレーションメカニズムを開発し、アプリケーション開発のチューニングを提供しました。

このアプローチには多くの利点があります：静的型付け、ブラウザでサーバーコードを再利用する機能、およびJava IDEの形の既製ツール。 元々GWTで規定されていたアプローチの多くは、TypeScript、Web Pack、およびその他のフロントエンド開発ツールで見られます。

古いGoogle Web Toolkitは、UIを構築するためのかさばりと抽象化のために好まれませんでした。 J2CLの考え方はより単純です。Javaを可能な限り低いコストでJavaScriptに変換できるため、JavaScriptからJavaを簡単に呼び出すことができ、その逆も可能です。

そして、2015年にJSに不要なガベージがなければ高品質のJavaトランスレータが本当にあったとしたら、Web開発がさらに発展するかどうかはわかりません。

バックグラウンドJ2CL

2015年の初めに、Google GWTチームは難しいが必要な決定を下しました。これは、フロントエンド開発でJavaを使用できるようにする新しい製品を開発することです。

これは主に、Web開発のトレンドの変化と、WebのJavaを孤立したエコシステムではなく、大規模なスタックの不可欠な部分と見なしている新しい内部クライアントが原因でした。 これには、完全に新しいビジョンとゼロからのツールの作成が必要であり、他のエコシステムと密接に統合する必要があります。

GWTでは、これらの目標を達成することはほとんど不可能でした。 GWTにはJavaSciptとの双方向の対話用のツールがありましたが、フレームワークはUI、RPCライブラリ、その他のアプリケーションAPIの形で大量の荷物を取り除くことができませんでした。

この獣は何ですか

開発者によると 、J2CLはJavaScriptアプリケーションへのJavaコードのシームレスな統合を提供します。 Closure Compilerを使用したコード最適化に重点を置いた、シンプルで軽量なJavaからJavaScriptへのトランスレーターです。

• 1つのプロジェクトでJavaとJavaScriptを簡単に組み合わせて、各言語から最高の結果を得ることができます。
• サーバーソリューション、Webアプリケーション、Androidプラットフォーム間でコードを再利用できます。 Guava、Dagger、AutoValueなど、多数のJavaライブラリが利用可能です。
• モダンで快適。 プロジェクトのアセンブリは、Live-reloadでサポートされるBazelに基づいています。
• 確認済み。 J2CLはGSuiteプロジェクト（GMail、Docs、Slides、Calendar）の本番環境で使用されていると言われています。

基本的に、J2CLは、Javaクラスバイトコードを使用せずに、JavaソースコードをJavaScriptコードに変換します。 つまり、Google Web Toolkitの場合のように、プロジェクトをコンパイルするには、使用するすべてのライブラリのソースコードが必要です。 さらに、これにより、新しいリリースでのJava言語機能のサポートに関する質問が発生します。 現時点では、開発者はJava 11のすべての構文機能のサポートを約束しています。

J2CLはGWTウィジェット、GWT RPC、およびその他のGWTライブラリをサポートしません-基本的なJavaおよびJavaScript統合メカニズムのみ-JSInterop 。

つまり これは、まったく新しいトランスポーターを備えたGWTの非常に限定されたバージョンです。 また、新製品はGWTとの互換性がなくなったため、GWTではなくJ2CLと呼ばれます。 その結果、GWT 3の予定されているリリースは、すべてのアプリケーションライブラリがトランスレータ自体のシステムレベルから分離されるJ2CL上のフレームワークになります。

既存のJava互換性の制限はGitHubで説明されています 。 基本的に、それらはGWTと同じままでした-リフレクションのサポートはなく、JavaネットワークAPIはありません。 しかし、何かが異なります。たとえば、配列とリストのセマンティクスはエミュレートされません。たとえば、インデックスは配列の境界での出現をチェックしません。 開発者はJVMの動作をエミュレートすることではなく、オーバーヘッドを最小限に抑え、完全な互換性を確保するために大量のJavaScriptを生成しないように言語の構文に焦点を合わせます。

J2CLは本番環境で使用できますが、OSSバージョンはまだまだ遠いです。 たとえば、 Windowsでのプロジェクトの開始に問題があり、開発者は安定したAPIを約束していません。

Googleの内部製品のビルドシステムとしてBazelを選択するのは簡単に説明できますが、コミュニティにプラスはありません。また、このビルドシステムを学ぶ以外に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の新しいトランスパイラープロジェクトは、コンパイラプラグインとして実装され、ソースコードを再解析する必要はありません。 また、この点に関して、J2CLは解析するソースコードを必要とするため、後退しています。

別のポイントは、Java言語自体です。 簡潔なKotlinでサーバー部分とクライアント部分の両方を記述できる場合、なぜ冗長Javaで記述しますか？

ただし、別の同様のプロジェクトであるJSweetと比較すると、J2CLをより信頼しています。 JSweetツールはより使いやすく、すぐに使用できますが、JSweetには小さなコミュニティがあり、そのほとんどすべてが1人のユーザーによって作成されています。

オープンソースコードと言いますか？

プロジェクトがApache 2.0のオープンライセンスを持っていることは確かに喜ばしいことです。

残念ながら、 オープンソースはオープンな開発プロセスを意味するものではありません。 コミュニティの最大の失望は3年前に発表されたJ2CLプロジェクトですが、ソースコードを公開している人はいません。最終APIに影響を与えることはできず、パッチを送信する場所がないため、開発プロセスをスピードアップできません。

状況が改善し、製品が実行可能になることを期待しましょう。

更新： GWT2から移植された最初のJ2CLアプリケーション-https : //github.com/DominoKit/dominodo