私は、Web経由で実行する必要があり、Javaのコンパイラツールやjavaccapiにアクセスできるプロジェクトに携わっています。私のチームは、Javaアプレットを使用してWebベースにすることを考えています。この場合、アプレットが実行できることと実行できないことには一定の制限があるのではないかと思います。コンパイラへのアクセスはクライアントのマシンではなくサーバーで行われるので、これは問題にならないだろうと思います。アプレットを使用すると、説明されているように2つを分離できますか？
2 に答える
1
ええ、アプレットはそれらにアクセスできるので、良い選択です。しかし、それは非常に限られた/鈍いルックアンドフィールを持っています. これで JavaFx を使用すると、独自の StyleSheet を定義できるため、非常に優れたルック アンド フィールが得られ、間違いなく 2 つのレイヤーも分離されます。
于 2013-02-25T07:22:04.193 に答える
1
アプレットが署名されている場合、アプレット (および JavaFX アプレットでさえも) はこの状況で機能します。アプレットには微妙な落とし穴がたくさんあるので、その技術にコミットする前にプロトタイピングを行うことをお勧めします。JavaFX デプロイメント ガイドに従って、JavaFX ベースのアプレットをデプロイする方法を確認してください。
私は、Java をコンパイルするには、完全な Java Development Kit をインストールする必要があると考えていました (これは、アプレットの展開状況では確実に行うのが難しいでしょう)。しかし、コンパイルAPIは、標準のJava実行環境に含まれるjavax.tools APIに含まれているようです。したがって、これはおそらく、ユーザーが完全な Java Development Kit をインストールする必要なく、Java コードのクライアント ベースの展開とコンパイルを含むソリューションを開発できることを意味します。
または、サーバー上でコンパイルを実行できるクライアント/サーバー ソリューションを検討することもできます。このようなアプローチの例 (Java WebStart ベースのソリューションを使用) は、TopCoder Algorithm Competition Applicationです。このアプリケーションを実行するための jnlp ファイル ( http://apps.topcoder.com/wiki/display/tc/The+Algorithm+Competition+Arena ) を次に示します。アプリケーションを使用して TopCoder に ID を登録し、それを使用していくつかのコードを作成およびコンパイルしてみることをお勧めします。TopCoder の実装は、JavaFX が存在する前に記述されたプレーンな Swing を使用しますが、必要に応じて実装に JavaFX を同様に使用することもできます。
コンパイルするコードに (構文を認識したテキスト スタイルの) エディターがさらに必要な場合は、JavaFX に埋め込まれたこのCodeMirrorベースのエディターのようなものを使用できます。CodeMirror ベースのソリューションは、エディターを HTML ベースのWebViewコントロールにラップします。JavaFX 8 の場合、構文を強調表示するテキスト エディターTextFlowの新しいコントロールを使用できる可能性がありますが、その API はまだサポートされているパブリック リリースの一部ではありません。
アップデート
この回答で概説されている戦略を使用して、この作業を行いました。
このイメージは、アプレットまたは Webstart アプリケーションとしてクライアント コード エディターにアクセスできるようにする html ページです。画像の上部の領域は、Java 編集をサポートする CodeMirror JavaScript エディターを強調表示する構文が埋め込まれた WebEngine に基づくコード編集領域です。画像の下部の領域は、クライアント マシンのローカル エディターでコードをコンパイルし、その後実行した出力です。出力は、コンパイル エラー、sysout へのプログラム出力、および syserr に出力される実行時例外で構成されます。ソリューションのトリッキーな部分は次のとおりです。
- sysout と syserr をキャプチャして JavaFX コントロールにリダイレクトする方法を検討しています。
- Java コンパイラーの検索。
デフォルトの Oracle Java Runtime Environment Provider は、Java コンパイラ実装への汎用インターフェイスを提供するだけで、Java コンパイラ実装自体は提供しません。その実装は、jdk に含まれる tools.jar にのみ含まれます。そのため、アプレットをパッケージ化するときに、アプレットのパッケージに tools.jar を含めました。javac コンパイラーのインスタンスを取得するためのサービス・プロバイダー・インターフェースを取得するのに苦労したので、最終的に次の行を使用してインスタンス化しました。
JavaCompiler compiler = new com.sun.tools.javac.api.JavacTool();
上記は、sun がプライベート com.sun クラスをいつでも変更する可能性があるため、やや脆弱ですが、少なくともこのインスタンスでは機能しました。
注意すべきもう 1 つの点は、システムで使用できるランタイム環境よりも古い javac コンパイラを使用して tools.jar を出荷すると、次のような警告が表示される可能性があることです。
warning: C:\Program Files\Java\jre8\lib\rt.jar(java/lang/Object.class): major version 52 is newer than 51, the highest major version supported by this compiler.
It is recommended that the compiler be upgraded.
上記の警告は、Java 7 tools.jar を含むアプレットを出荷し、Java 8 ランタイムを使用してアプレットを実行したために発生しました (これらの警告に関係なく、アプレットは正常に動作したことに注意してください)。
アップデート
このソリューションのコードをgithub リポジトリ (プロジェクト名の概念)に配置しました。更新されたソリューションでは、Oracle Java Compiler ではなく、 Eclipse Compiler for Javaが使用されます。主な理由は、Eclipse Compiler の場合は別の jar (Oracle ディストリビューションの 14 メガのツール jar ではなく 1.8 メガのみ) であり、ライセンスが少し明確であるためです。Java コンパイラ インターフェイスはプラグ可能であるため、tools.jar がクラスパスに配置されている場合でも Oracle コンパイラを使用できます。
于 2013-02-25T20:14:26.187 に答える