HTML5とWebAssemblyでJVMを置き換え、モダンブラウザ上でJavaアプリケーション（およびアプレット）を実行：CheerpJ 3.0を公表

TLDR: 過去1年間、私たちはCheerpJの新しいアーキテクチャに取り組んできました。HTML5/WebAssemblyにおけるJVMの実装で、ブラウザ上でJavaアプリケーションを実行するように設計されています。CheerpJ 3.0は2023年の晩夏にリリースされる予定で、これまで以上に使いやすく、高速で、互換性の高いものになります。私たちのJavaFiddleのライブデモは、すでに現在の開発バージョンに移行しています。

CheerpJは、大規模で変更されていないJavaアプリケーションやアプレットをブラウザで実行するためのリーン・テクノロジーズのソリューションです。実行は完全にクライアントサイドで、標準的なHTTPサーバー以外のサーバーサイドのコンポーネントは一切必要ありません。ここ数年、CheerpJは商業的にだけでなく、コミュニティにおいても最も成功した製品であり、全世界で10万人以上のユーザーを獲得しています。

CheerpJの成功は、最小限の労力で実世界のJavaアプリケーションを効率的に実行できることに起因しており、レガシーなクライアントサイドJavaアプリケーションの寿命を延ばすのに非常に有効です。これは、いくつかの機能によって実現されています：

* ソースコードは不要： CheerpJは、ソースコードへのアクセスを全く必要とせず、.classや.jarファイル内のJavaバイトコードのレベルで動作します。サードパーティのライブラリや依存関係、難読化されたコードも問題ではありません。

* 高度なJava機能をサポート： 実際のJavaアプリケーションやOpenJDKのランタイムでは、リフレクション、マルチスレッド、ランタイム生成クラス（ラムダ/インボケディナミック、プロキシの実装に使用）などが利用されることがあります。CheerpJは、これらすべてを完全にサポートしており、アプリケーションの適応を必要としません。

* OpenJDKとの互換性： CheerpJは、修正されていないOpenJDK環境に基づいており、ネイティブJVMと比較して、ブラウザ上で同じ動作を保証します。ファイルシステム、ネットワーキング、印刷、クリップボード、その他多くのサブシステムがシームレスに動作するよう、多くのエミュレーション層を含んでいます。

# なぜ新しいアーキテクチャが必要なのか？

現行バージョンのCheerpJで達成した成果を誇りに思うと同時に、長年にわたって、特に技術的な能力と使いやすさの両面で、いくつかの欠点が浮かび上がってきています：

* 実行モデル： その性能を達成するために、CheerpJは、元のアプリケーションの各.jarファイルに対して最適化された.jar.jsを生成するAOTコンパイラを含んでいます。これらのファイルは、実行時にCheerpJによって.jarの対応ファイルと共にロードされ、実行を高速化するために使用されます。このモデルは、理解、デプロイ、統合が難しいことが判明しました。CIセットアップの後処理としてCheerpJを追加する必要性は、しばしば歓迎されない負担として感じられ、私たちの企業ユーザーの多くは、実際のAOTコンパイラバイナリを彼らの制御環境で実行することが困難であることを発見しました。

* ClassLoadersのサポートに制限がある： Javaのクラス名からバイトコードへの変換は、ClassLoadersによって実行時に完全に制御することができます。AOTコンパイルモデルは、このレベルの柔軟性とは真に互換性がありません。実際のアプリケーション、特に複雑なフレームワークに基づくアプリケーションでは、これは予想以上に重大な制限であることが判明した。また、AOTコンパイル・モデルは、複数のjarに重複するクラスを扱う場合にも脆弱で、これはロギング・ライブラリ（log4j、slf4j）では非常によくあることです。

* 起動時間とダウンロードサイズ： Javaアプリケーションは、依存関係を追加する際にかなり自由になる傾向があり、時には、実行時にわずかなクラスを使用しながら、全体の.jarを出荷することがあります。現在のCheerpJモデルでは、この結果、多くのjarとjar.jsファイルがダウンロードされ、実行時に解析され、実行されることになり、アプリケーションのスタートアップを遅くしています。

* ランタイムサポートはJava 8に限定: CheerpJでJava 9以降のランタイムバージョンのサポートを追加する主な障害は、Javaの「ネイティブ」メソッドの実装（JNI経由）であり、ランタイムの追加バージョン/サブバージョンごとに大規模な反復作業を必要としました。

# CheerpJ 3.0アーキテクチャ：WebAssemblyによるJVMの完全な置き換え

私たちは、ブラウザベースのx86仮想マシンであるCheerpXから学んだ教訓を生かしつつ、CheerpJアーキテクチャを一から再設計することで、これらの問題すべてを解決する全体的なアプローチをとることにしました。

新しいCheerpJアーキテクチャの主な特徴は以下の通りです：

* Goodbye AOT, hello JIT compilation : CheerpJ 3.0は、完全に透過的な多層実行モデルを採用しています。これは、ほとんど使わないコードには高速インタプリタを、頻繁に使うコードにはJITコンパイラを組み合わせることから始まります。この新しいモデルでは、未使用のクラスに対してコードが実行・生成されることはなく、起動時のパフォーマンスが向上しています。AOTコンパイラや.jar.jsファイルがないため、CheerpJ 3.0の統合と展開は、既存のHTMLページに数行追加するだけでよくなりました。

* クラスローダーをフルサポート： JVMが通常どのように動作するかを模倣した新しいJITアプローチのおかげで、アプリケーションが提供するものを含むクラス解決のために、適切なクラスローダーに完全なコントロールを与えることができるようになりました。これにより、重複したクラスによる非互換性を完全に排除することができます。

* スケーラブルな新しいJNIアーキテクチャ： OpenJDKのネイティブコードの100%をWebAssemblyにコンパイルし、Javaの最新バージョンや、ユーザーが必要とする特定のポイントバージョンをサポートするための実行可能な経路を提供します。これは、CheerpJが完全に修正されていないバージョンのOpenJDKを使用することを意味し、互換性のレベルをさらに拡張しています。

これらのアーキテクチャの進歩により、CheerpJ 3.0は、完全なOpenJDKランタイムを持つ、JVMの完全なWebAssemblyベースの代替品とみなすことができます。

# 次のステップ

CheerpJ 3.0は現在まだ開発中ですが、すでに十分に安定しており、私たちのJavaFiddleのデモで使用することができます：ブラウザでJavaコードをコンパイル、実行、共有する完全なクライアントサイド環境です。このデモは、Javaコンパイラ自体がJavaで書かれており、CheerpJでも実行できるという事実を利用しています。
![blog_lt_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3486144/1a75cb36-f176-9e1c-b820-ec1c6e162f02.png)
CheerpJでSwingの "Hello World "をコンパイルし、ブラウザで完全にクライアントサイドで実行する

CheerpJ 3.0の正式リリースは2023年夏以降を予定しており、リリースに向けてさらなる発表を行っていく予定です。既存のJavaアプリケーションをブラウザに移行させるという実証済みの機能だけでなく、Web開発のクライアントサイド言語としてのJavaに影響を与えるかもしれないという点で、私たちはこの技術に非常に期待しています。

[Discord](https://discord.com/invite/K2cERkVX2S)で質問していただければ、いつでもどんな質問でもお答えします。

[Twitter](https://twitter.com/leaningtech)でフォローしていただくと、CheerpJを含むすべての製品の最新情報が確認できます。

詳細はこちら　https://leaningtech.com/legacy-modernisation-jp/

引用元：https://leaningtech.com/announcing-cheerpj-3-0-a-jvm-replacement-in-html5-and-webassembly-to-run-java-applications-and-applets-on-modern-browsers/