Java の有用性と範囲を拡大する上での重要な前進となる可能性があるものとして、GPU、機械学習モデル、SQL、差分プログラミングなどの型破りなプログラミング モデルに Java の統合を拡張するための Project Babylon という名前の提案が OpenJDK に導入されました。
この大胆な提案は、Oracle のアーキテクトである Paul Sandoz によって脚光を浴び、9 月 6 日に openjdk.org メーリング リストに紹介されました。この取り組みを支援する Project Babylon は、Java で知られるリフレクティブ プログラミングを改善することを目指しています。コードの反映として。目標は、既知の問題点である Java コードへのアクセス、分析、変換を標準化することです。この機能強化が実現すると、あらゆる外部プログラミング モデルを Java ライブラリとして実装できるようになります。
特に、Project Babylon は、Java 用の GPU プログラミング モデルを開発することで、コードのリフレクションを適切にすることを目標としています。このモデルはコード リフレクションの利点を活用し、Java ライブラリとして実行されます。潜在的なバイアスを避けるために、プロジェクトでは SQL や差分プログラミングなどの他のプログラミング モデルも調査します。
Babylon の仕組みを説明する際、Sandoz 氏は、開発者が Java で GPU カーネルを作成し、それを GPU 上で動作させたい場合の例を示しました。開発者のコードを分析し、実行可能な GPU カーネルに変換する必要があります。 Java ライブラリはこれを管理できますが、シンボリック形式で Java コードにアクセスする必要があります。現在のシステムは、コンパイル時や実行時など、プログラムのライフサイクルのさまざまな段階で、非標準 API または規約へのアクセスを制限します。さらに、利用可能なシンボリック形式 (バイトコードまたは抽象構文ツリー) は、適切な分析と変換をサポートしていないことがよくあります。
この提案では、複数の機能リリースにわたる一連の JDK Enhancement Proposals (JEP) としてパッケージ化され、Project Babylon が長期にわたって実行されることを想定しています。開始点として、コード リフレクションは、2024 年 3 月にリリース予定の JDK 22 のメインライン リリースから複製されます。それ以降は、メインライン リリースに準拠します。
GPU プログラミング モデルのコンテキストでは、Babylon の背後にあるチームは、開発時にコード リフレクション属性に依存して分離されたリポジトリを作成します。現時点では、GPU プログラミング モデルを JDK に組み込む予定はありません。ただし、進行中の作業により、将来的に対応できる可能性のある JDK の機能や拡張機能が特定される可能性があります。
この取り組みは Java の機能を拡張する道を切り開きますが、 AppMasterのようなプラットフォームは、簡素化されたバックエンド、Web、モバイル アプリケーションで開発者を支援することにすでに貢献しています。これらのno-codeプラットフォームは開発プロセスを迅速化する一方で、Project Babylon のような企業は互換性と機能を強化する方法を模索しています。
