Java仮想マシン

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
Java仮想マシン
デザイナーサンマイクロシステムズ
ビット32ビット
紹介された1994年
バージョン15.0.3 [1]
タイプスタックして登録–登録
エンコーディング変数
分岐比較して分岐する
エンディアンネス
開けるはい
レジスター
一般的用途メソッドごとのオペランドスタック(最大65535オペランド)とメソッドごとのローカル変数(最大65535)
Java仮想マシン仕様JavaSE 7 Editionに基づくJava仮想マシン(JVM)アーキテクチャの概要

A Java仮想マシンJVMは)ある仮想マシンを実行するためにコンピュータを可能にするJavaで書かれたプログラムと同様のプログラムを他の言語もコンパイルされたJavaバイトコード。 JVMは、JVM実装で必要なものを正式に説明する仕様によって詳細に説明されています。仕様を設定することで、さまざまな実装間でのJavaプログラムの相互運用性が保証されるため、Java Development Kit(JDK)を使用するプログラム作成者は、基盤となるハードウェアプラットフォームの特異性について心配する必要がありません。

JVMリファレンス実装は、OpenJDKプロジェクトによってオープンソースコードとして開発され、HotSpotと呼ばれるJITコンパイラが含まれています。Oracle Corporationから入手可能な市販のJavaリリースは、OpenJDKランタイムに基づいています。Eclipse OpenJ9は、OpenJDK用のもう1つのオープンソースJVMです。

JVM仕様

Java仮想マシンは、仕様で定義された抽象(仮想)コンピューターです。これは、Javaランタイム環境の一部です。ガベージコレクションに使用されるアルゴリズムとJava仮想マシン命令のいずれかの内部最適化(へのそれらの翻訳マシンコードは)指定されていません。この省略の主な理由は、実装者を不必要に制約しないことです。すべてのJavaアプリケーションは、Java仮想マシンの抽象仕様の具体的な実装内でのみ実行できます。[2]

始まるJavaプラットフォーム、標準版(J2SE)5.0は、下で開発されているJVMの仕様を変更するJava Community ProcessのJSR 924のように、[3] 2006年に提案された変更をサポートする仕様の変更クラスファイル形式(JSRを202)[4]はJSR 924のメンテナンスリリースとして行われています。JVMの仕様はブルーブックとして公開されました[5]序文は次のように述べています。

私たちは、この仕様は十分可能互換性のクリーンルーム実装を作るために、Java仮想マシンを文書化する必要があることを意図します。Oracleは、Java仮想マシンの実装の適切な動作を検証するテストを提供します。

OracleのJVMの1つはHotSpotという名前です。もう1つは、BEA Systemsから継承されたJRockitです。クリーンルームJavaの実装には、Kaffe、OpenJ9、およびSkelmirのCEE-Jが含まれます。オラクルはJavaの商標を所有しており、オラクルの仕様と完全に互換性があることを実装スイートとして認定するために使用できる場合があります。

クラスローダー

JVMバイトコードの組織単位の1つは、クラスです。クラスローダーの実装は、Javaクラスファイル形式に準拠するものをすべて認識してロードできる必要がありますどの実装も、クラスファイル以外の他のバイナリ形式を自由に認識できますが、クラスファイルを認識する必要があります。

クラスローダーは、次の厳密な順序で3つの基本的なアクティビティを実行します。

  1. 読み込み中:タイプのバイナリデータを検索してインポートします
  2. リンク:検証、準備、および(オプションで)解決を実行します
    • 検証:インポートされたタイプの正確性を確認します
    • 準備:クラス変数にメモリを割り当て、メモリをデフォルト値に初期化します
    • 解決策:シンボリック参照を型から直接参照に変換します。
  3. 初期化:クラス変数を適切な開始値に初期化するJavaコードを呼び出します。

一般に、クラスローダーには、ブートストラップクラスローダーとユーザー定義クラスローダーの2種類があります。

すべてのJava仮想マシンの実装には、信頼できるクラスをロードできるブートストラップクラスローダーと、拡張クラスローダーまたはアプリケーションクラスローダーが必要です。Java仮想マシンの仕様では、クラスローダーがクラスを見つける方法を指定していません。

仮想マシンアーキテクチャ

JVMは、Java仮想マシンの仕様で指定されている特定のタイプのデータで動作します。データ型はプリミティブ型(整数、浮動小数点、longなど)と参照型に分けることができます[6]。以前のJVMは32ビットマシンのみでしたおよびタイプは64ビットですが、ネイティブでサポートされていますが、各ユニットが32ビットであるため、フレームのローカル変数またはオペランドスタックで2ユニットのストレージを消費します。、およびタイプは、すべてのある符号拡張(以外であるゼロ拡張)と32ビット整数のように動作、同じlongdoublebooleanbyteshortcharcharintタイプ。小さいタイプには、ロード、保存、およびタイプ変換に関するタイプ固有の命令がいくつかあります。booleanは8ビットbyteとして動作し、0はを表しfalse、1はを表しtrueます。 (がbooleanのでタイプとして扱われているJava仮想マシン仕様第2版は、ほとんど差があるコンパイルされ、実行されるコードでは、この問題を明らかにbooleanし、byte以外の名前マングリングにおけるメソッドのシグネチャとブール配列のタイプは。booleanSでメソッドシグネチャはマングルされZbytesはマングルされBます。ブール配列は型を持ちます。boolean[]ただし、要素ごとに8ビットを使用し、JVMにはブール値をビット配列にパックする組み込み機能がないため、ブール値が実行し、byte配列と同じように動作するタイプを除きます。他のすべての用途では、booleanブール値を操作するためのすべての命令がbytesを操作するためにも使用されるためタイプはJVMに事実上不明です。)ただし、新しいJVMリリース(OpenJDK HotSpot JVM)は64ビットをサポートします。 64ビットOS上のビット/ 64ビットJVM。 64ビット環境でJavaを実行する主な利点は、アドレス空間が大きいことです。これにより、Javaヒープサイズを大幅に拡大し、Javaスレッドの最大数を増やすことができます。これは、特定の種類の大規模なアプリケーションに必要ですが、32ビットJVMと比較して64ビットJVMを使用するとパフォーマンスが低下します。

JVMには、オブジェクトと配列を格納するためのガベージコレクションされたヒープがあります。コード、定数、その他のクラスデータは「メソッド領域」に格納されます。メソッド領域は論理的にはヒープの一部ですが、実装ではメソッド領域をヒープとは別に処理する場合があり、たとえばガベージコレクションを行わない場合があります。各JVMスレッドには、フレームを格納する独自の呼び出しスタック(わかりやすくするために「Java仮想マシンスタック」と呼ばれます)もあります。メソッドが呼び出されるたびに新しいフレームが作成され、そのメソッドが終了するとフレームは破棄されます。

各フレームは、「オペランドスタック」と「ローカル変数」の配列を提供します。オペランドスタックは、計算のオペランドと呼び出されたメソッドの戻り値の受信に使用されますが、ローカル変数はレジスタ同じ目的を果たし、メソッド引数の受け渡しにも使用されます。したがって、JVMはスタックマシンレジスタマシンの両方です。

バイトコード命令

JVMには、次のタスクグループの説明があります。

目的はバイナリ互換性です。特定の各ホストオペレーティングシステムには、JVMとランタイムの独自の実装が必要です。これらのJVMは、バイトコードを意味的に同じ方法で解釈しますが、実際の実装は異なる場合があります。バイトコードをエミュレートするよりも複雑なのは、各ホストオペレーティングシステムにマップする必要があるJavaコアAPI互換性があり効率的に実装することです。

これらの命令は、共通のセットで動作します 特定の命令セットアーキテクチャネイティブデータ型はなく、抽象化されたデータ型

JVM言語

JVM言語は、Java仮想マシンでホストできる有効なクラスファイルで表現できる機能を備えた言語です。クラスファイルには、Java仮想マシン命令(Javaバイトコード)とシンボルテーブル、およびその他の補助情報が含まれています。クラスファイル形式は、コンパイルされたクラスとインターフェイスを表すために使用される、ハードウェアおよびオペレーティングシステムに依存しないバイナリ形式です。[7]

いくつかのJVM言語があり、両方ともJVMに移植された古い言語と完全に新しい言語です。JRubyJythonは、おそらく既存の言語、つまりそれぞれRubyPythonの最もよく知られた移植版です。 Javaバイトコードにコンパイルするためにゼロから作成された新しい言語の中で、ClojureApache GroovyScalaKotlinが最も人気のある言語かもしれません。 JVM言語の注目すべき機能は、相互に互換性があることです。たとえば、ScalaライブラリをJavaプログラムで使用したり、その逆を行ったりすることができます。[8]

Java 7 JVMは、JavaプラットフォームでJSR 292:動的型付け言語のサポート[9]実装します。これは、JVMで動的型付け言語をサポートする新機能です。この機能は、Java以外の言語をサポートするようにJVMを拡張することを使命とするDa VinciMachineプロジェクト内で開発されています。[10] [11]

バイトコードベリファイア

Javaの基本的な考え方は、ユーザープログラムがホストマシンをクラッシュさせたり、ホストマシン上の他の操作を不適切に妨害したりすることはなく、trustedに属する特定のメソッドとデータ構造を保護できるという観点から本質的に安全であるということです。同じJVM内で実行される信頼できないコードによるアクセスまたは破損からのコード。さらに、配列の終わりからアクセスしたり、初期化されていないポインタを使用したりするなど、データの破損や予測できない動作につながることが多い一般的なプログラマエラーは発生しません。クラスモデル、ガベージ収集ヒープ、ベリファイアなど、Javaのいくつかの機能を組み合わせてこの安全性を提供します

JVMは、実行される前にすべてのバイトコードを検証します。この検証は、主に次の3種類のチェックで構成されます。

  • ブランチは常に有効な場所にあります
  • データは常に初期化され、参照は常にタイプセーフです
  • プライベートまたはパッケージのプライベートデータとメソッドへのアクセスは厳密に制御されます

これらのチェックの最初の2つは、主に、クラスがロードされて使用可能になったときに発生する検証ステップ中に実行されます。3つ目は、クラスのデータ項目またはメソッドが最初に別のクラスによってアクセスされるときに、主に動的に実行されます。

ベリファイアは、有効なプログラムの一部のバイトコードシーケンスのみを許可します。たとえば、ジャンプ(分岐)命令は、同じメソッド内の命令のみをターゲットにできます。さらに、ベリファイアは、任意の命令が固定スタック位置で動作することを保証し[12]、JITコンパイラがスタックアクセスを固定レジスタアクセスに変換できるようにします。このため、JVMがスタックアーキテクチャであるということは、レジスタベースのアーキテクチャでのエミュレーションの速度が低下することを意味するものではありません。JITコンパイラを使用する場合。コード検証済みのJVMアーキテクチャーでは、JITコンパイラーが、ターゲット・アーキテクチャーのレジスターに割り当てられる必要のある名前付きの架空のレジスターまたは架空のスタック位置を取得するかどうかに違いはありません。実際、コード検証により、JVMは従来のスタックアーキテクチャとは異なります。従来のスタックアーキテクチャでは、JITコンパイラを使用した効率的なエミュレーションはより複雑で、通常は低速のインタプリタによって実行されます。さらに、デフォルトのJVMで使用されるインタープリターは、テンプレートインタープリターと呼ばれる特殊なタイプであり、通常のインタープリターのようにスタックをエミュレートするのではなく、バイトコードをネイティブのレジスタベースの機械語に直接変換します[13]。(多くの面で、HotSpotインタープリターは真のインタープリターではなくJITコンパイラーと見なすことができます)。つまり、バイトコードがターゲットとするスタックアーキテクチャーは実際には実装で使用されませんが、適切に実装できる中間表現の仕様にすぎません。レジスタベースのアーキテクチャ(単なる仕様であり、レジスタベースの仮想マシンに実装されているスタックアーキテクチャの別のインスタンスはCommon Language Runtimeです)。[14]

バイトコードベリファイアの元の仕様では、いくつかの点で不完全または不正確な自然言語が使用されていました。JVMを正式なシステムとして指定するために多くの試みがなされてきました。これを行うことにより、現在のJVM実装のセキュリティをより徹底的に分析でき、潜在的なセキュリティの悪用を防ぐことができます。実行中のアプリケーションが安全であることが証明されている場合は、不要な安全性チェックをスキップしてJVMを最適化することもできます。[15]

リモートコードの安全な実行

仮想マシンアーキテクチャにより、マシン内のコードが実行できるアクションを非常にきめ細かく制御できます。これは、コードが「意味的に」正しいことを前提としています。つまり、ツールによって、場合によっては仮想マシンの外で、(正式な)バイトコード検証プロセスを正常に通過したことを前提としています。これは、リモートソースからの信頼できないコード、Javaアプレット使用されるモデル、およびその他の安全なコードのダウンロードを安全に実行できるように設計されています。バイトコードが検証されると、ダウンロードされたコードは制限された「サンドボックス」で実行されます。これは、ユーザーを不正なコードや悪意のあるコードから保護するように設計されています。バイトコード検証プロセスに加えて、出版社はデジタル署名するための証明書を購入できますアプレットは安全であり、サンドボックスから抜け出し、ローカルファイルシステム、クリップボードアクセスし、外部のソフトウェアまたはネットワークを実行するようにユーザーに依頼する許可を与えます。

バイトコードベリファイアの正式な証明は、Javacard業界によって行われています(Java Cardバイトコード用の組み込みベリファイアの正式な開発[16])。

バイトコードインタプリタとジャストインタイムコンパイラ

ハードウェアアーキテクチャごとに、異なるJavaバイトコードインタプリタが必要です。コンピューターにJavaバイトコードインタープリターがある場合、そのコンピューターは任意のJavaバイトコードプログラムを実行でき、同じプログラムをそのようなインタープリターを備えた任意のコンピューターで実行できます。

Javaバイトコードがインタプリタによって実行される場合、その実行は、ネイティブの機械語にコンパイルされた同じプログラムの実行よりも常に遅くなります。この問題は、Javaバイトコードを実行するためのジャストインタイム(JIT)コンパイラによって軽減されます。 JITコンパイラは、プログラムの実行中にJavaバイトコードをネイティブマシン言語に変換する場合があります。プログラムの翻訳された部分は、解釈されるよりもはるかに迅速に実行できます。この手法は、頻繁に実行されるプログラムの部分に適用されます。このようにして、JITコンパイラは全体の実行時間を大幅に短縮できます。

Javaプログラミング言語とJavaバイトコードの間に必要な接続はありません。Javaで記述されたプログラムは、実際のコンピューターの機械語に直接コンパイルでき、Java以外の言語で記述されたプログラムは、Javaバイトコードにコンパイルできます。

Javaバイトコードは、プラットフォームに依存せず、安全であることを目的としています。[17]一部のJVM実装にはインタプリタが含まれていませんが、ジャストインタイムコンパイラのみで構成されています。[18]

WebブラウザのJVM

Javaプラットフォームの存続期間の初めに、JVMはリッチWebアプリケーションを作成するためのWebテクノロジーとして販売されていました。 2018年の時点で、ほとんどのWebブラウザーおよびWebブラウザーをバンドルしているオペレーティングシステムにはJavaプラグインが付属しておらずFlash以外のプラグインをサイドロードすることもできません。 Javaブラウザプラグインがで廃止されましたJDK 9 [19]

NPAPIのJavaブラウザプラグインは、JVMは、いわゆる実行できるように設計されたJavaはアプレットHTMLページに埋め込まれました。プラグインがインストールされているブラウザの場合、アプレットは、割り当てられたページの長方形の領域に描画できます。プラグインにはJVMが含まれているため、JavaアプレットはJavaプログラミング言語に制限されません。 JVMを対象とするすべての言語は、プラグインで実行できます。 APIの制限されたセットにより、アプレットはユーザーのマイクまたは3Dアクセラレーションにアクセスできますが、アプレットはその長方形の領域の外側でページを変更することはできません。競合する主要なテクノロジーであるAdobeFlash Playerは、この点でも同じように機能します。

W3Techsによると、2015年6月の時点で、JavaアプレットとSilverlightの使用はすべてのWebサイトでそれぞれ0.1%に低下しましたが、Flashは10.8%に低下しました。[20]

JavaScriptJVMとインタプリタ

2016年5月の時点で、JavaPolyを使用すると、ユーザーは変更されていないJavaライブラリをインポートし、JavaScriptから直接呼び出すことができます。JavaPolyを使用すると、ユーザーがコンピューターにJavaをインストールしていない場合でも、Webサイトで変更されていないJavaライブラリを使用できます。[21]

JavaScriptへのコンパイル

JavaScriptの実行速度の継続的な改善と、Webブラウザがプラグインのサポートを実装していないモバイルデバイスの使用の増加と相まって、JavaScriptへのコンパイルを通じてそれらのユーザーをターゲットにする取り組みが行われています。ソースコードまたはJVMバイトコードをJavaScriptにコンパイルすることができます。

JVM言語間で普遍的なJVMバイトコードをコンパイルすると、言語の既存のコンパイラをバイトコードに構築できます。JavaScriptコンパイラへの主なJVMバイトコードは、TeaVM、[22] Dragome Web SDKに含まれるコンパイラ、[23] Bck2Brwsr、[24]およびj2js-compilerです。[25]

JVM言語からJavaScriptへの主要なコンパイラには、Google Web Toolkit、Clojurescript(Clojure)、GrooScript(Apache Groovy)、Scala.js(Scala)などに含まれるJavaからJavaScriptへのコンパイラが含まれます[26]

Javaランタイム環境

OracleによってリリースされたJavaRuntime Environment(JRE)は、スタンドアロンJVM(HotSpot)、Java標準ライブラリJava Class Library)、構成ツール、およびJDK 9で廃止されるまで、ブラウザプラグイン。これは、ラップトップおよびデスクトップフォームファクタのパーソナルコンピュータインストールされる最も一般的なJava環境です。JVMに同梱されているフィーチャーフォンや初期のスマートフォン含む携帯電話には、JavaプラットフォームのMicroEditionを対象とするアプリケーションを実行することを目的としたJVMが含まれている可能性があります。一方、ほとんどの最新のスマートフォン、タブレットコンピューター、およびJavaアプリを実行するその他のハンドヘルドPCは、JVM仕様と互換性のないオープンソース仮想マシンを含むAndroidオペレーティングシステムのサポートを介して実行する可能性が最も高くなります(代わりに、GoogleのAndroid開発ツールは、Javaプログラムを入出力Dalvikバイトコードとして受け取ります。これは、Androidデバイス上の仮想マシンのネイティブ入力形式です。)

パフォーマンス

JVM仕様は、実装の詳細に関して実装者に多くの余裕を与えます。Java 1.3以降、OracleのJREにはHotSpotと呼ばれるJVMが含まれています。高性能JVMとして設計されています。

コードの実行を高速化するために、HotSpotはジャストインタイムコンパイルに依存しています。オブジェクトの割り当てとガベージコレクションを高速化するために、HotSpotは世代別ヒープを使用します。

世代別ヒープ

Java仮想マシンのヒープのためのJVMで使用されるメモリの領域である動的なメモリ割り当て[27]

HotSpotでは、ヒープは世代に分けられます

  • 若い世代の店舗短命オブジェクトを作成し、すぐにガベージコレクトされています。
  • 長く存続するオブジェクトは、古い世代テニュア世代とも呼ばれます)に移動されます。このメモリは、最初と次のガベージコレクションを生き残ったオブジェクトが格納される(2つの)サバイバースペースに分割されます。

永久世代(またはpermgenは)前のJava 8永久発生にクラス定義および関連するメタデータのために使用されたヒープの一部ではなかったです。[28] [29]永久世代のJava 8から除去された[30]

元々、永続的な生成はなく、オブジェクトとクラスは同じ領域に一緒に格納されていました。ただし、オブジェクトが収集されるよりもクラスのアンロードが発生することはほとんどないため、クラス構造を特定の領域に移動すると、パフォーマンスが大幅に向上します。[28]

セキュリティ

OracleのJREは、多数のコンピュータにインストールされています。したがって、古いバージョンのJREを使用しているエンドユーザーは、多くの既知の攻撃に対して脆弱です。これは、Javaは本質的に安全ではないという広く共有された信念につながりました。[31] Java 1.7以降、OracleのJRE forWindowsには自動更新機能が含まれています。

Javaブラウザプラグインが廃止される前は、どのWebページでもJavaアプレットを実行している可能性があり、悪意のあるWebサイトに簡単にアクセスできる攻撃対象領域提供していました2013年、Kaspersky Labsは、Javaプラグインがコンピューター犯罪者に最適な方法であると報告しました。Javaエクスプロイトは、ハッカーがハッキングされたWebサイトに展開する多くのエクスプロイトパックに含まれています。[32] Javaアプレットは、2018年9月25日にリリースされたJava11で削除されました。

も参照してください

参考文献

  1. ^ "jdk-updates / jdk15u:1055f2102e6e"OracleCorporation2021-04-20を取得
  2. ^ Bill Venners、 Java仮想マシンの内部第5章
  3. ^ 「JavaCommunityProcess(SM)プログラム-JSR:Java Specification Requests-詳細JSR#924」Jcp.org 2015年626取得
  4. ^ 「JavaCommunityProcess(SM)プログラム-JSR:Java Specification Requests-詳細JSR#202」Jcp.org 2015年626取得
  5. ^ Java仮想マシン仕様(第1第2版もオンラインで入手できます)。
  6. ^ 「第2章Java仮想マシンの構造」
  7. ^ 「Java仮想マシン仕様:Java SE 7 Edition」(PDF)Docs.oracle.com 2015年626取得
  8. ^ 「よくある質問-Javaの相互運用性」scala-lang.org 2015年11月18日取得
  9. ^ 「JavaCommunityProcess(SM)プログラム-JSR:Java Specification Requests-詳細JSR#292」Jcp.org 2015年626取得
  10. ^ 「ダヴィンチマシンプロジェクト」Openjdk.java.net 2015年626取得
  11. ^ 「新しいJDK7機能:Java仮想マシンでの動的型付け言語のサポート」Oracle.com 2015年626取得
  12. ^ 「検証プロセス」Java仮想マシン仕様サンマイクロシステムズ。1999 2009年5月31日取得
  13. ^ https://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Interpreter
  14. ^ 「CLRをレジスタベースにしないのはなぜですか?・問題#4775・dotnet / runtime」GitHub
  15. ^ Freund、Stephen N。; ミッチェル、ジョンC.(1999)。「Javaバイトコード言語とベリファイアの正式なフレームワーク」。オブジェクト指向プログラミング、システム、言語、およびアプリケーションに関する第14回ACMSIGPLAN会議の議事録-OOPSLA'99pp。147–166。CiteSeerX 10.1.1.2.4663土井10.1145 /320384.320397ISBN  978-1581132380S2CID  14302964
  16. ^ http://www-sop.inria.fr/everest/Lilian.Burdy/CBR02dsn.pdf
  17. ^ David J. Eck、 Javaを使用したプログラミング入門、第7版、バージョン7.0、2014年8月セクション1.3「Java仮想マシン」
  18. ^ Oracle JRockitの紹介 は、WaybackMachineリリースR28の22015年9月6日にアーカイブされました。「ジャストインタイムのコンパイルと最適化について」
  19. ^ 「OracleはJavaブラウザプラグインを廃止し、その終焉に備える」ArsTechnica2016年1月28日取得した15年4月2016
  20. ^ 「クライアント側プログラミング言語の使用における歴史的な年次傾向、2015年6月」W3techs.com 2015年626取得
  21. ^ オキアミ、ポール(2016年5月13日)。「JavaPoly.jsは既存のJavaコードをインポートし、JavaScriptから直接呼び出します」InfoWorld 検索された18年7月2016
  22. ^ 「TeaVMプロジェクトのホームページ」Teavm.org 2015年626取得
  23. ^ 「DragomeWebSDK」Dragome.com 2015年626取得
  24. ^ 「Bck2Brwsr-APIDesign」Wiki.apidesign.org 2015年626取得
  25. ^ Wolfgang Kuehn(ディケーター)。j2js-コンパイラGitHub
  26. ^ 「JSにコンパイルされる言語のリスト・jashkenas / coffeescript Wiki・GitHub」Github.com。2015-06-19 2015年626取得
  27. ^ 「HotspotJava仮想マシンでのガベージコレクションに関するよくある質問」サンマイクロシステムズ2003年2月6日取り出される7年2月2009年
  28. ^ a b 正光、ジョン(2006年11月28日)。「パーマネントジェネレーションの提示」取り出される7年2月2009年
  29. ^ ナッター、チャールズ(2008年9月11日)。「InvokeDynamicの最初の味」取り出される7年2月2009年
  30. ^ 「JEP122:永久世代を削除する」OracleCorporation2012-12-04 2014年3月23取得
  31. ^ 「Javaとは何ですか、それは安全ではありません、そして私はそれを使うべきですか?」Lifehacker.com。2013-01-14 2015年626取得
  32. ^ 「Javaエクスプロイトに対する保護はありますか?|カスペルスキー」Kaspersky.com。2013-09-09。アーカイブされたオリジナルの2015年4月4日に2015年626取得

外部リンク