エディタフレームワークの概要

Eclipse のテキストエディタフレームワークは、ワークベンチのユーザインタ フェイスフレームワーク JFace が提供するテキスト表示機能等を集約し、さら にエディタとしての基本機能を付加したものである。 Eclipse のテキストエディタフレームワークはワークベンチプラグイン org.eclipse.ui.workbench.texteditor で提供されている。 先に、Eclipse のエディタは ITextEditor インタフェイスを実装しなければ ならないと述べたが、この ITextEditor も org.eclipse.ui.workbench.texteditor プラグイン内の src/org/eclipse/ui/texteditor/ にある。また、デフォルトエディタ TextEditor クラスの親クラス StatusTextEditor も org.eclipse.ui.workbench.texteditor プラグインにあるクラスで、プラグイン のソースツリーの中の src/org/eclipse/ui/texteditor/StatusTextEditor.java にある。

org.eclipse.ui.workbench.texteditor プラグインの org.eclipse.ui.texteditor パッケージは、テキストエディタそのものの基底ク ラス群のほか、テキストエディタにまつわるインタフェイス、テキストエディタ の動作（アクション）の実装クラス・インタフェイス群、およびこれらが使用す るクラスから構成されている。

テキストエディタの構成

先に述べたとおり、テキストエディタに提供する機能の大部分は AbstractTextEditor クラスに集約されている。 AbstractTextEditor では、テキストエディタを構成する主要な機能を実装した クラスのインスタンスを保持している。 本項では、この AbstractTextEditor が管理するインスタンスのうち、下記につ いて概観する。

• fSourceVeiwer

• fSourceViewerConfiguration

• fInternalDocumentProvider

• fPreferenceStore

• fActions

fSourceViewer は ISourceViewer インタフェイスの実装クラスのインスタンス である。 AbstractTextEditor の fSourceViewer は、テキストエディタのインスタンスが 編集対象としているドキュメントの表示を担当する。 ISourceViewer の実装クラスはソースコードの表示に関わる機能を提供するクラ スで、org.eclipse.jface.text プラグインの org.eclipse.jface.text.source パッケージで提供されている。

ISourceViewer はテキストファイルの表示機能を提供する ITextViewer を継承したインタフェイスであり、通常のテキスト表示機能に、プログラムソー スの表示で必要となる機能を追加したものである。 ITextViewer は org.eclipse.jface.text プラグインの org.eclipse.jface.text パッケージに含まれている。 ISourceViewer や ITextViewer は表示機能のみを管轄しており、文字入力を はじめとする編集機能は直接的には保有していない。 ちなみに、ITextViewer は、表示の形式等を管理・決定するクラス TextPresentation を内部で管理している。

ITextViewer の実装クラスとして TextViewer クラスが、また ISourceViewer の実装クラスとして SourceViewer がそれぞれインタフェイスと同じパッケージ 内に提供されている。 クラスの継承関係等は図5および 図6を参照。 Java ソースのビューアクラス JavaSourceViewer も SourceViewer を継承した クラスとして実装されている。

fSourceViewerConfiguration は ISourceViewer の実装クラスの設定を管理する クラスである。 SourceViewerConfiguration は org.eclipse.jface.text プラグインの org.eclipse.jface.text.source パッケージで提供されている。 このクラスは JFace フレームワークが提供する様々な拡張機能 の設定を一括して管理しているクラスである。 SourceViewerConfiguration を ISourceViewer の configure メソッドで渡して やることで、SourceViewer 自身の表層を定義している。 なお、JFace が提供する諸機能については、JFace フレームワークが提供するエディタの機能項 を参照のこと。

fInternalDocumentProvider は、IDocumentProvider インタフェイスのイン スタンスで、TextEditor と編集対象のドキュメントの実体（ファイルなど）と の対応付けを行っている。 IDocumentProvider は org.eclipse.ui.workbench.texteditor プラグインの org.eclipse.ui.texteditor パッケージで提供されている。 諸々のパッケージでファイルなどを対象とした実装クラスが提供されている (図7)。

fPreferenceStore は IPreferenceStore インタフェイスのインスタンスで、 エディタに関する様々な設定を保持している。 IPreferenceStore は一種のハッシュテーブルで、機能的には java.util.Properties をリッチにしたものと考えてよい。実体は org.eclipse.jface プラグインの org.eclise.jface.preference パッケージに ある。 AbstractEditor では、エディタの設定を保持するためにこの IPreferenceStore クラスを使用している。 ここで対象となる設定項目とは、例えばエディタの表示色指定やキーバインドな どである。 fPreferenceStore が保持する内容はエディタの諸機能の実装部分等から参照で きるため、エディタの拡張機能を実装した際に実装した機能に関連する設定を新 たに fPreferenceStore に持たせることも可能である。 ただし、設定項目を追加した場合、新たに追加された設定項目を変更するユーザ インタフェイスも必要となる。

fActions は AbstractEditor が管理するアクションの一覧を保持する HashMap である。 アクションとは、キー操作などに連動して行うエディタの動作を定義したもので、 カットアンドペーストや、検索、置換などがその代表例である。 AbstractTextEditor が管理するアクションについては テキストエディタのアクション定義項を参照。

テキストエディタのアクション定義

テキストエディタフレームワークでは、カットアンドペースト、検索、置換など、 テキストエディタに関連する様々な基本編集作を用意している。これらの動作は、 org.eclipse.ui.workbench.texteditor プラグインの org.eclipse.ui.texteditor パッケージのクラスや、AbstractTextEditor の内 部クラスなどとして提供されている。

表1はその一例である。

図8 にテキストエディタに関するアクション クラスの一覧と継承関係を示す。

この中の ResourceAction 以下のクラスはいずれも org.eclipse.ui.texteditor パッケージのクラスである。 org.eclipse.ui.workbench.texteditor プラグインで提供されるこれらのアクショ ンは、何れも TextEditroAction やその親クラスの ResourceAction などを継承 していることがわかる。 Eclipse フレームワークではキー入力などをハンドルする Action は IAction インタフェイスを実装していなければならない。この階層の中では Action クラ スが IAction を実装したクラスになっている。

これらのアクションは、AbstractTextEditor クラスの createActions メソッド で実体が作成され、エディタのアクションとして関連付けが行われる。

なお、カット、コピー、ペーストなどの編集機能についてはコアプラグイン org.eclipse.ui.workbench で提供されている。これらは、 Eclipse UI/org/eclipse/ui/actions/ ディレクトリの中の TextActionHandler の内部クラスとして定義されている。

dabbrev を実装する場合、上記のアクションと群と同様に ResourceAction もし くは TextEditorAction を継承したクラスを作成し、その中に動作を記述す ることになる。 dabbrev では、通常近隣の行を検索し入力された文字列にマッチする行を検索す ることとなる。従って、FindNextActoin や DeleteLineAction などは参考にな る可能性がある。 また、dabbrev の操作ではインクリメンタルサーチと同様に２ 回以上連続してアクションが呼ばれたときに動作が変化する(順位の低い候補を 表示する)ので、IncrementalFindAction クラスや、同クラスを補助している IncrementalFindTarget クラスなどが参考になるものと思われる。

本来であれば、このほかの部分についても詳細な報告をすべきかもしれないが、 今回調査対象になっている部分の殆んどは org.eclipse.ui.workbench.texteditor プラグインではなく、JFace フレームワー ク関連のプラグインで提供されている。 そこで、org.eclipse.ui.workbench.texteditor のフレームワーク解説はここで 一旦終了し、次節では JFace の提供するテキストエディタフレームワークにつ いて説明する。

JFace テキストフレームワークが提供する機能の概要

先にも述べたが JFace は Eclipse に対してユーザインタフェイス機能を提供 する高位のフレームワークであり、ワークベンチプラグインの一部として提供さ れている。JFace フレームワークの大半の機能はワークベンチプラグイン org.eclipse.jface で提供されているが、テキストエディタに関連したフレーム ワークはワークベンチプラグイン org.eclipse.jface.text で提供されている。

エディタの諸機能のうち JFace のテキストエディタフレームワークが提供して いる機能は下記のとおりである。

• フォントの装飾やスタイルの変更

  テキスト中に現れる特定の文字や範囲に対して、指定された条件に従って文字色 やフォント、フォントのスタイルを変更する機能を提供する。

• テキストの整形（フォーマット）

  文脈に応じて、テキスト中に空白や改行を適宜挿入しソースコードを見やすくす る機能を提供する。

• 補完候補の出力

  文脈に応じて補完候補を表示、選択する機能を提供する。

• ポップアップによるヘルプ等の表示

  マウスカーソルの位置に応じて適切なコメントやヘルプをポップアップウィンド ウに表示する機能である。Java エディタの場合は、クラスやメソッド等の JavaDoc コメントや、変数の型、カーソル位置に関するエラーや警告のポップアッ プ表示に利用されている。

• 外部のドキュメント情報との連携

  外部のドキュメント情報との連携は、エディタ以外の部分が保持しているドキュ メントのテキストに関連した情報との連携を行う。 例えば、Java ソースファイルの場合、外部でソースの構文木情報などのドキュ メントモデルデータを管理しているが、エディタで Java ソースを編集した際に は、変更内容に応じて構文木情報を修正しなければならない。 この機能は、このようなテキストの編集に伴って発生するテキストエディタ外 のドキュメント情報の修正のトリガとして利用される機能である。

次項以降では、これら JFace のテキストフレームワークが提供する諸機能の仕 組みと活用方法について概説する。

JFace テキストフレームワークでの拡張機能設定

まず最初に、ここでは上記の諸機能に共通する部分として、拡張機能の設定方法 について概説する。

JFace テキストフレームワークが提供する機能の概要項で述べたように、jface のテキストフ レームワークでは多種多様な機能を提供している。 これらの機能は何れも対象となる位置の文脈など、ドキュメントにまつわる条件 ごとに、その条件下で行うべき動作を指定する必要がある。 フォントの装飾を例に取ると、ここでいう条件とは対象部分が文字列であるか予 約語であるか平文であるか、といったものであり、また動作とは文字列であれば 青色、コメントは茶色、本文は基本は黒だけど予約語だけは太字の紫にする、と いったものである。

従って、このような条件と動作の組み合わせを与えてやることで、これらの機能 を実現することが可能となる。 Eclipse の JFace テキストエディタフレームワークで提供する機能は、いず れもこの条件と動作のセットで定義される。

このうち条件は内容種別を表す String で付与する。例えば、文字列は "QUOTED_STRING", コメントは "COMMENT", それ以外は "OTHERS" という名前を 割り当てる。 一方で、動作はそれぞれの機能ごとに動作を記述したクラスを作成する。 JFace フレームワークでは、個別機能ごとにインタフェイスやテンプレートクラ スが用意されており、個別のエディタではこれらを継承したクラスを実装するこ とで動作を付与する。 内容種別の文字列と動作記述クラスとの対応関係は HashMap が保持しており、 内容種別を与えることで実際の動作の定義を取得することが可能となる。

このような構成になっているのは、編集テキストの部分ごとにフォント装飾や テキスト整形のストラテジ(動作)が大きく異なるためではないかと想像され る。 例えば Java のソースコードについて考えてみると、普通のソースコードの部分 とコメント部分ではフォント装飾やコードアシストのストラテジは全く違ったも のである。そこで、内容種別ごとに動作が定義できるようになっているのではな いかと思われる。例えば、Java エディタでは、下記の６種類のパーティション が用意されている。

• 一行コメント (// で始まるコメント)

• 複数行にわたるコメント(/* から */ まで)

• JavaDoc コメント(/** から */ まで)

• 文字列定数(ダブルクウォートで囲まれた部分)

• 文字定数(シングルクウォートで囲まれた部分)

• Java プログラム本文(上記以外)

なお、これらの内容種別や動作の役割と関係は、 JDT の Java エディタ項で説明する。

さて、実際には、内容種別に対応した動作記述クラスを取得する前に、対象とな るドキュメントを解析し、テキスト中の種別の境界を決定したり、個別の部 分ごとにドキュメントの内容種別を判別する必要がある。 内容種別とその境目の情報はパーティションと呼ばれており、これらのパーティ ションの判定についてもフレームワークが提供されている。 なお、パーティションの分割および内容種別の判定の詳細については テキストのパーティション項 で説明する。

エディタが提供する諸機能は、全て org.eclipse.jface.text.source パッケー ジの SourceViewerConfiguration クラスで一括管理されている。 拡張機能を実装した場合、実装した拡張機能のクラスを SourceViewerConfiguration のインスタンスに登録し、 このインスタンスを AbstractTextEditor の setSourceViewerConfiguration メ ソッドに渡してやることで、機能が利用できるようになる。

テキストのパーティション

本項ではテキストのパーティションについて説明する。 パーティションとは、編集対象テキストを、内容などに応じて部分ごとに分割し た際の個々の断片のことである。 JFace テキストフレームワークでの拡張機能設定項で述べたように、Eclipse のエ ディタフレームワークでは、内容種別ごとにフォント装飾やテキスト整形の ストラテジを定義することが可能である。 テキストのパーティションの特徴は下記のとおりである。

• パーティションは重複しない

• テキストの全ての文字は必ずどれか１つのパーティションに属する

• パーティションには必ず１つの内容種別が割り当てられる

JFace テキストフレームワークでは、このパーティションをスキャンするための 機能を提供している。このパーティションとスキャニングのフレームワークは ワークベンチプラグイン org.eclipse.jface.text の org.eclipse.jface.text.rules パッケージにある。 このパッケージではパーティションに関するインタフェイスのほかに、ルールベー スのスキャナのテンプレートなども提供している。 また、JFace プラグインが提供する装飾などの機能についても、テンプレートと なるクラスを提供している。 関連するクラスおよびインタフェイスを表2 に示す。

基本的には IPartitionTokenScanner の実装クラスを用意すればよい。 実装クラスは setRange もしくは setPartialRange でスキャンする範囲を指定 でき、かつ nextToken メソッドで範囲内のパーティションを順次取得できる ように実装する必要がある。 nextToken の戻り値は IToken インタフェイスである。IToken は is 系のメソッ ドでトークンの種別が取得できるほか、getData メソッドの戻り値を String に キャストすることで内容種別を取得できるようにする必要がある。

IPartitionTokenScanner の実装クラスとして RuleBasedPartitionScanner が用 意されている。このクラスは IRule インタフェイスの実装クラスによって与え られるルールを組み合わせることで、テキストをスキャンする機能をより簡単に 実装できる。Java エディタでは、パーティションのスキャンに RuleBasedScanner を継承した JavaPartionScanner クラスを利用している (図9)。

ソースの解析やトークンというと、前回の調査報告で述べた Java コンパイラの ソース解析機能 (org.eclise.jdt.core プラグインの compilre ディレクトリに ある org.eclipse.jdt.internal.compiler.parser.Scanner クラスなど)や、そ の際に利用するトークン(org.eclipse.jdt.core プラグインの dom ディレクトリ以下にある org.eclipse.jdt.core.dom.ASTNode クラス や model ディレクトリ以下にある org.eclipse.jdt.core.IJavaElement など)との関係 が気になる。 しかし、残念ながら JFace テキストフレームワークが用意するスキャナやトー クンと、JDT のコンパイラにあるこれらのクラスとは一切無関係である。 スキャナについては、JDT では Java エディタ専用のトークンおよびスキャナを Java コンパイラとは完全に独立して実装しており、トークンの取得にはこのス キャナを利用している。

フォントの装飾

フォントの装飾に関する機能は org.eclipse.jface.text プラグインの org.eclipse.jface.text.presentation パッケージに用意されている。 presentation パッケージのクラスは下記の 4 つである。

この機能は、文字入力などによって生じたテキストへの変更に対し、全体を再描 画するのではなく、影響が波及する範囲のみを再描画することを想定した実装に なっている。 例えば、１文字入力された場合、大抵はその文字、あるいはせいぜいそ の単語のみを変更すればよく、それ以外の部分については文字が入力される前の 表示がそのまま利用できる。 このように、テキスト全体を再描画する必要があるケースはそれほど多くはない。 １文字入力されるたびにテキストビューを全て再描画してしまうと極めて効率が 悪くなる恐れがあることから、 テキストが変更される都度、変更によって表示の修正が必要となる必要 最低限の範囲を特定し、その部分のみを修正することを意図しているものと思わ れる。 なお、最初にテキストを表示する時には、テキスト全体が変更されたものするこ とで全体を描画させることが可能である。

jface.text.presentation パッケージのうち、テキスト修正動作に直接関連する ものは、IPresentationDamager と IPresentationRepairer である。 IPresentationDamager インタフェ イスは、テキストの変更によって表示の修正が必要となる範囲を特定するクラ スのインタフェイスである。 IPresentationDamager が特定した修正範囲に対し、実際にテキストの修正を行 うクラスのインタフェイスが IPresentationRepairer である。

IPresentationDamager は getDamageRegion というメソッドを持っている。 このメソッドは、 テキストが編集などにより変更された際に、変更が行われた範囲と変更内容を受 けて、その変更が影響する範囲を返す。 IPresentationRepairer には createPresentation というメソッドがあり、この メソッドは、IPresentationDamager の getDamageRegion の返した範囲情報と、 その部分へのテキスト表示設定を受け取ると、テキスト表示設定の内容を更新す る。

一方で IPresentationReconciler は、テキストの内容種別に対して適切な IPresentationDamager および IPresentationRepairer を提供する、いわば HashMap 的クラスのインタフェイスである。jface.text.presentation パッ ケージでは、IPresentationReconciler のテンプレート実装として PresentationReconciler クラスを提供している。 大抵のエディタでは、 PresentationReconciler は拡張することなくそのまま利 用可能である。実際に、Java エディタでも PresentationReconciler がそのまま 利用されている。

IPresentationDamager と IPresentationRepairer については、 jface.text.presentation パッケージにはインタフェイスしかないが、 org.eclipse.jface.text.rules パッケージに実装クラスがある。 RuleBasedDamagerRepairer および DefaultDamagerRepairer が該当するクラス である(表4)。 このうち、RuleBasedDamagerRepairer は DefaultDamagerRepairer を継承 しただけのクラスなので、実際には DefaultDamagerRepairer が実装クラスの実 体である。 このクラスは、IPresentationDamager と IPresentationRepairer の両方を実装 したクラスである。 IPresentationDamager と IPresentationRepairer は相互に強く依存しているた め、単一のクラスに両方の機能を実装したものと想定される。 DefaultDamagerRepairer はコンストラクタの引数として ITokenScanner など を必要とするが、これはパーティション内の更なるトークンの解析に利用される。 後述の Java エディタでもこの DefaultDamagerRepairer を使用している (フォント装飾の実装項参照)。 詳細を理解するためには Java エディタでの実装を読むのがよい。

このクラスは、テキストのパーティション項で説明した ITokenScanner を 付与すると、この Scanner を利用して修正対象となる範囲を抽出し、その部分 の表示を修正させる。 修正範囲の表示内容の生成は AbstractTextEditor が保持する SourceCodeViewer に与えられた TextPresentation が行う (テキストエディタの構成項参照)。

テキストの整形に関するクラス

テキストの整形に関する機能は org.eclipse.jface.text プラグインの org.eclipse.jface.text.formatter パッケージに用意されている。 formatter パッケージのクラスは下記の 3 つである。

このうち、テキスト修正動作に直接関連するものは IFormattingStrategy であ る。IFormattingStrategy インタフェイスには format というメソッドがある。 このメソッドは、整形対象の文字列や、そ の部分のインデント情報などを渡すと、その部分を整形した結果の文字列を返す。 整形対象や整形後の文字列の受け渡しには String を利用している。 このほかに、整形に時間を要するケースを想定してか、format の開始および停 止を通知するメソッドがある。

IFormattingStrategy については、テンプレート実装は用意されていない。 これは、FormattingStrategy クラスの実装は、ドキュメントの種類によって多 種多様で、極めて一般化しにくいためではないかと想定される。 なお、Java エディタでは独自に IFormattingStrategy の実装クラス JavaFormattingStrategy を用意している。

IContentFormatter インタフェイスは、テキストの内容種別に対して適切な IFormattingStrategy を提供するクラスである。 このインタフェイスの役割は、フォントの装飾機能における IPresentationReconciler インタフェイスと同様であり、内容種別文字列をキー とする HashMap のようなものである。 IContentFormatter のテンプレート実装が ContentFormatter クラスである。 フォント装飾での PresentationReconciler と同様に、基本的には ContentFormatter もエディタ毎の実装はあまり必要はなく、 Java エディタでも ContentFormatter がそのまま利用されている。

補完候補の表示

補完候補の表示に関する機能は org.eclipse.jface.text プラグインの org.eclipse.jface.text.contentassist パッケージに用意されている。 contentassist パッケージのクラスは非常に多いが、そのうち主要なクラスは下 記のとおりである。

補完候補は IContentAssistProcessor インタフェイスの実装が管理する。 実際の補完候補は、１つづつ ICompletionProposal インタフェイスのインスタ ンスに格納されており、IConentAssistProcessor の computeCompletionProposals メソッドを呼ぶことで ICompletionProposal の配 列を取得することができる。 メソッド補完時などに表示されるパラメータの一覧も IContentAssistProcessor が管理しており、こちらは IContextInformation に格納される。 これも同様に IContentAssistProcessor の compilteContextInformation メソッ ドを呼ぶことで、配列を取得することができる。 IContentAssistProcessor および IContextInformation はそれぞれテンプレート 実装が用意されている。 なお、IContentAssistProcessor のテンプレート実装は用意されていない。

IContentAssistant インタフェイスは、テキストの内容種別に対して適切な IContentAssistProcessor を提供するクラスである。 このインタフェイスの役割は、その他の機能と同様に、内容種別文字列をキー とする HashMap のようなものである。 IContentAssistant のテンプレート実装が ContentAssistant クラスで ある。なお、Java エディタでは ContentAssistant クラスと、このクラスをを 継承した JavaCorrectionAssistant の２つを利用している。

ポップアップの表示

ポップアップの表示に関する機能は org.eclipse.jface.text プラグインの org.eclipse.jface.text.information パッケージに用意されている。 information パッケージのクラスは下記のとおりである。

もともとは、ポップアップの情報提示も org.eclipse.jface.text.contentassist パッケージで提供されていたが、org.eclipse.jface.text.information が後か ら追加されたようだ。現在でも org.eclipse.jface.text.contentassist にもポッ プアップに関連するクラスが残っており、こちらでもポップアップ表示が可能な ようである。

表示内容に直接関わるものは IInformationProvider インタフェイスと IInformationProviderExtension インタフェイスである。 IInformationProvider インタフェイスには getSubject というメソッドと getInformation というメソッドがある。 getSubject メソッドはテキスト中の指定されたポイントに対して、同じ情報が 表示される範囲を返すメソッドである。 例えば、Java ソースエディタを例に取ると、メソッド名の部分にマウスカーソ ルを移動させると、同じメソッド名の上をマウスカーソルが移動している間は、 そのメソッドに関するポップアップメッセージを表示し続けるが、メソッド名の 部分からマウスカーソルが外れるとポップアップメッセージは消滅する。 この場合、getSubject は、このメソッド名の開始位置から終了位置までを表示 範囲として返す。 もう一つの getInformation メソッドは、getSubject メソッドが返した表示範 囲に表示すべきメッセージを文字列 (String) で返す。 例えば、Java ソースエディタで、getSubject が指し示した表示範囲が文字列だっ た場合、getInformation メソッドはそこで表示すべき内容、つまり、メソッド の型定義と JavaDoc コメントの冒頭部分を戻り値として返す。 IInformationProviderExtension は、IInformationProvider の getInformation の戻り値を Object にした getInformation2 というメソッドを 持っている。これは、ポップアップ表示の内容が String だけでは表現しきれな いケースを想定して用意されたものである。

IInformationProvide および IInformationProviderExtension の テンプレート実装はワークベンチでは用意されていない。 Java エディタでは独自にこれらの実装クラス JavaElementProvider および JavaInformationProvider クラスを用意している。

IInformationPresenter インタフェイスは、テキストの内容種別に対して適切な IInformationProvider を提供するクラスである。 このインタフェイスの役割は、その他の機能と同様に、内容種別文字列をキー とする HashMap のようなものである。 IInformationPresenter のテンプレート実装が InformationPresenter クラスで ある。これもその他の機能と同様に、エディタ毎の実装はあまり必要はなく、 Java エディタでも InformationPresenter がそのまま利用されている。

外部のドキュメント情報との連携

外部のドキュメント情報との連携に関する機能は org.eclipse.jface.text プラグインの org.eclipse.jface.text.reconciler パッケージに用意されている。 reconciler パッケージの主要クラスは下記のとおりである。

外部のドキュメント情報との連携処理に直接関与するものは、 IReconcilingStrategy インタフェイスと IReconcilingStrategyExtension イン タフェイスである。 IReconcilingStrategy インタフェイスには reconcile というメソッドがあり、 このメソッド内にでドキュメントの変更に対する処理内容を記述する。 reconcile メソッドは２つあるが、片方が変更範囲が明らかな場合に変更され ている範囲を付与できるのにたいし、もう片方は変更範囲は特定せずに再構成を 行うメソッドである。 IReconcilingStrategyExtension には setProgressMonitor というメソッドがあ り、進捗状況を表示するプログレスバーなどと連携ができるようになっている。 これは、ドキュメント情報との整合性をとる処理には時間を要することが多いた めと思われる。

IReconciler インタフェイスは、テキストの内容種別に対して適切な IReconcilerStrategy を提供するクラスである。 このインタフェイスの役割は、その他の機能と同様に内容種別文字列をキー とするハッシュマップのようなものである。 IReconciler のテンプレート実装は用途に応じて複数用意されている。 実装クラス一覧を図10に示す。 Reconciler がフルスペックの実装であるのに対し、MonoReconciler では内容種 別によらず同じ IReconcilingStrategy を返す。 Java エディタでは後者の MonoReconicler を継承した JavaReconciler を実装 している。

パーティション分割と内容種別の判定

本項では JavaEditor のパーティション分割に関連するクラスを概観する。 パーティション分割の詳細は、テキストのパーティション項を参照のこと。

Java エディタでは下記の 6 種類のパーティションを用意している。

これらのパーティションの内容種別は IJavaPartitions インタフェイスで管理 している。

JavaEditor ではパーティションのスキャンには RuleBasedPartitionScanner な どは利用しておらず、独自にスキャナクラスを実装している。 これは、ルールベースのスキャナでは十分な性能が確保できなかったためではな いかと想定される。 なお、トークンについては JFace フレームワークの Token クラスをそのまま利 用している。 パーティションのスキャンに関するクラスは下記のとおりである。

フォント装飾の実装

本項では JavaEditor のフォント装飾の実装について概観する。 フレームワークが提供する フォント装飾機能の詳細は、フォントの装飾項を参照 のこと。 また、パーティション分割と内容種別については既に パーティション分割と内容種別の判定項で述べたとおりである。 ここでは、パーティションごとの内容種別を決定した後の動作について説明する。

Java エディタでは、 JFace フレームワークで用意されているテンプレート実装に対して特に拡張の実 装は行なっておらず、そのまま利用している。 IPresentationDamager および IPresentationRepairer は、 DefaultDamagerRepairer を、また IPresentationReconciler は PresentationReconciler をそれぞれ利用している。 Java エディタ独自の実装としては、IPresentationDamager および IPresentationRepairer で利用する、パーティション内のトークン分析用のスキャ ナ群である。 表12 に Java エディタが用意しているパー ティション内のトークンのスキャナクラスを示す。

Java エディタでは、これらのスキャナをそれぞれ DefaultDamageRepairer に与 えることにより、Java プログラム本体や、コメント部分、JavaDoc などに特化 した IPresentationDamager および IPresentationRepairer のインスタンスを 作成している。 Damager および Repairer のインスタンスの生成と、IPresentationReconciler への登録は、 org.eclipse.jdt.ui.text パッケージの JavaSourceViewerConfiguration クラスの getPresentationReconciler メソッドで行われている。 また、個々のスキャナのインスタンスは org.eclipse.jdt.ui.text パッケージの JavaTextTools クラスで一括管理され ている。

エラー表示機能の実装

JDT のエラー表示はエディタとはかなり独立した機能として提供されている。 Java ソースのコンパイル結果は org.eclipse.jdt.core プラグインの dom ディ レクトリ内の org.eclipse.jdt.core.dom パッケージによって解析され、 エラーとして報告される。 個々のエラー情報は IProblem クラスに格納され、IProblem の配列で管理され る。

JDT のユーザインタフェイス部分では、core extension ディレクトリの org.eclipse.jdt.internal.corext.dom パッケージ等を解して、dom が生成した エラー情報を取得する。 これらのエラー情報は org.eclipse.jdt.internal.ui.text.correction パッケー ジでハンドリングされ、エディタの補完機能やマーカー表示などに反映される。

ソースコード整形機能の実装

本項では JavaEditor のソースコード整形に関連するクラスを概観する。 なおソースコード整形の詳細は、テキストの整形に関するクラス項を参 照のこと。

JFace が提供する整形機能のうち、主要なインタフェイスは IFormattingStrategy と IContentFormatter の２種である。 このうち、IFormattingStrategy については テキストの整形に関するクラス項 で述べたようにテンプレートクラスが 用意されていないため、Java エディタでは独自の実装クラス JavaFormattingStrategy を実装している。 このクラスの実体は、org.eclipse.jdt.ui プラグインの org.eclipse.jdt.internal.text.java パッケージにある。 なお、JavaFormattingStrategy の内部では JDT のコア部分が用意するコード整 形クラスICodeFormatter のインスタンスを取得して、そちらに処理を依頼して いる。 ICodeFormatter は org.eclipse.jdt.core プラグインに属しており、 コア部分の保持している Java プログラムパーサを利用して整形を行っている。

なお、IContentFormatter については、JFace が用意したテンプレート実装をそ のまま利用している。 IContentFormatter のインスタンスは JavaSourceViewerConfiguration が保持 しており、getContentFormatter メソッドで取得できる。

補完候補提示機能の実装

本項では JavaEditor の補完候補提示に関連するクラスを概観する。 なお補完候補提示機能の詳細は、補完候補の表示項を参 照のこと。

補完候補の提示には、IContentAssistProcessor, ICompletionProposal, IContextInformation, IContentAssistant の各インタフェイスを実装する必要 がある。 IContentAssistProcessor は独自の実装クラスとして JavaCompletionProcessor, JavaDocCompletionProcessor および JavaCorrectionProcessor を実装している。 これらの詳細を表13に示す。

このほかに、ICompletionProposal の実装クラス (図11)および IContextInformation の実装クラス (図12) が多数用意されている。 これらは数が膨大なため詳細は割愛する。

IContentAssistant については、JavaEditor ではテンプレート実装の ContentAssistant クラスをそのまま利用している。 しかし、JavaEditor の実装クラスである CompilationUnitEditor では、 ContentAssistant クラスを継承した JavaCorrectionAssistant を利用している。

JavaEditor が利用している ContentAssistant は JavaSourceViewerConfiguration が保持しており、getContentAssistant メソッ ドで取得できる。 一方で CompilationUnitEditor が利用する JavaCorrectionAssistant は CompletionUnitEditor の内部クラスの AdaptedSourceViewer で管理されてい る。

ソース説明のポップアップ表示機能の実装

本項では JavaEditor のポップアップ表示機能に関連するクラスを概観する。 なおポップアップ表示の詳細は、ポップアップの表示項を参 照のこと。

JFace が提供するポップアップ機能は IInformationProvide インタフェイスと IInformationPresenter インタフェイス を実装することで利用できる。 このうち IInformationProvide については ポップアップの表示項でも述べたように JFace フレームワークではテンプレート実装は提供されていない。 そこで、Java エディタでは独自に JavaElementProvider および JavaInformationProvider の実装クラスを用意している。

なお、IInformationPresenter については、JFace が用意したテンプレート実装 をそのまま利用している。 IInformationPresenter のインスタンスは JavaSourceViewerConfiguration が 保持しており、getInformationPresenter および getOutlinePresneter メソッ ドで取得できる。 getInformationPresenter は JavaSourceViewerConfiguration の親クラス SourceViewerConfiguration で定義されているメソッドであり、JFace の SourceViewer の設定に利用される。 一方で getOutlinePresenter は JavaSourceViewerConfiguration の独自のメソッ ドであり、JFace フレームワークでは利用されない。 このメソッドは JavaSourceViewer から呼ばれており、Java エディタ独自のポッ プアップ表示に利用されている。

Eclipse のフルビルド

ここでは Eclipse のソース全体から Eclipse のバイトコードを生成する方 法について述べる。ソースに改変を行った Eclipse のバイトコードを生成す るためには必ず一回はフルビルドを行う必要がある。

ソースツリーのフルビルドを行う際は、Eclipse ソースツリーのトップディレ クトリで下記のコマンドを実行する。

% cd ${eclipse}
% build -os <OS種別> -ws <ウィンドウシステム種別> [ -bc <rt.jarのパス> ]

ここで、${eclipse} は Eclipse のソースツリーのトップディレクトリである。 <rt.jarのパス>には Java のランタイムライブラリ(J2SDKに含まれる rt.jar)を指定する。なお、クロスコンパイルではない場合は、-bc オプション は不要である。 また、<OS種別>および<ウィンドウシステム種別>に指定する値を 表15に示す。

Eclipse のソースは全体で数十MByte に及ぶため、Eclipse 全体をビルドす ると処理系によっては１時間近くかかってしまい、極めて効率が悪い。 そこで、フルビルドの必要がない場合は、可能な限り次項で述べるプラグインご とのビルドを行うことを推奨する。

プラグインごとのビルド

ここでは特定のプラグインのみを単独でビルドする方法について説明する。 原則的には、個々のプラグインはそれほど密な関係にはないため、外部から 参照可能な API の仕様変更がない場合(プラグインの内部的な実装のみの変更の 場合)は、たいてい変更を行ったプラグインのみの再構築で動作する。 但し、この手順は全ての場合に適用可能できるわけではない。状況によってはプ ラグインのみのビルドでは適正に動作せず、全体をコンパイルし直す必要がある。

なお、本項で説明するのは厳密にはプラグイン単体でのビルドではなく、関連 性のあるプラグイン集合のビルドである。

# cd ${ECLIPSE}/features/org.eclipse.jdt-feature/
# ant clean
# ant -buildfile build.xml -Dos=<OS種別> -Dws=<ウィンドウシステム種別> -Dbootclasspath=<rt.jarのパス>

<OS種別>、 <ウィンドウシステム種別>、<rt.jarのパス>に 設定する値については前項と同じである(表15Eclipse のフルビルド項参照)。 2 行目で clean を実行しているが、これは、clean をせずにビルドした場合に うまく動作しないことがあったためである。実際に詳細な条件については調査を 行っていないが、改変内容によっては clean が必要となるようである。

楽観的 try 構文の概要

まずは、楽観的 try 構文について簡単に説明する。 なお、本節で対象とする楽観的 try 構文は前回の調査報告で実装を行ったもの と全く同じ仕様である。

楽観的 Try 構文は、API インタフェイス上は例外が発生し得るが、実際には例 外が発生し得ない場合のコーディングを楽にするシンタックスシュガーである。

ByteArrayOutputStream os = new ByteArrayOutputStream();
try __optimistic__ {
	os.close();
}

これは、意味的には下記のコードと等価である。

ByteArrayOutputStream os = new ByteArrayOutputStream();
try  {
	os.close();
} catch (Throwable th) {
}

つまり、__optimistic__を付加したtry文では、catch節やfinally節を省略する ことが可能である。

楽観的 try 構文の色付けの拡張

ここでは楽観的 try 構文に対して色付けの拡張を行う方法について説明する。

---

実装

なお、今回対象となる Eclipse のソースツリーに対しては、前回の調査報告 に記述した楽観的 try 構文に関するコンパイラ拡張が既に適用されているもの とする。

変更が未適応でも楽観的 Try 構文の色づけ自体は行われるが、 パースに失敗するためエラーなどのマーカーが表示される。

JavaCodeScanner は org.eclipse.jdt.ui プラグインの ui ディレクトリの org.eclipse.jdt.internal.ui.text.java パッケージにある。 予約語の判定は createRules メソッド(139行目)の中でスタティックメンバの String[] fgKeywords (83行目) と比較することで行っている。 従って、fgKeywords に "__optimistic__" を追加してやればよい。 下記に変更したソースを示す。

... public final class JavaCodeScanner extends AbstractJavaScanner { ... private static String[] fgKeywords= { "abstract", //$NON-NLS-1$ "break", //$NON-NLS-1$ "case", "catch", "class", "const", "continue", //$NON-NLS-5$ //$NON-NLS-4$ //$NON-NLS-3$ //$NON-NLS-2$ //$NON-NLS-1$ "default", "do", //$NON-NLS-2$ //$NON-NLS-1$ "else", "extends", //$NON-NLS-2$ //$NON-NLS-1$ "final", "finally", "for", //$NON-NLS-3$ //$NON-NLS-2$ //$NON-NLS-1$ "goto", //$NON-NLS-1$ "if", "implements", "import", "instanceof", "interface", //$NON-NLS-5$ //$NON-NLS-4$ //$NON-NLS-3$ //$NON-NLS-2$ //$NON-NLS-1$ "native", "new", //$NON-NLS-2$ //$NON-NLS-1$ "package", "private", "protected", "public", //$NON-NLS-4$ //$NON-NLS-3$ //$NON-NLS-2$ //$NON-NLS-1$ "return", //$NON-NLS-1$ "static", "super", "switch", "synchronized", //$NON-NLS-4$ //$NON-NLS-3$ //$NON-NLS-2$ //$NON-NLS-1$ "this", "throw", "throws", "transient", "try", //$NON-NLS-5$ //$NON-NLS-4$ //$NON-NLS-3$ //$NON-NLS-2$ //$NON-NLS-1$ "volatile", //$NON-NLS-1$ "while", //$NON-NLS-1$ // ************** for optimistic try ************** "__optimistic__" // ************************************************* }; private static String[] fgNewKeywords= { "assert" }; //$NON-NLS-1$ ...

以上の変更を適用した上で Eclipse を再構築することで、 楽観的 Try に対応した Eclipse が生成される。

マップ初期化子の概要

マップ初期化子は、既に値が登録された Map インスタンスを初期化する構文を 提供するものである。

Map colors = %{
	"red" => new Integer(0xff0000),
	"green" => new Integer(0x00ff00),
	"blue" => new Integer(0x0000ff)
};

上記のように記述すると、下記のコードと同じ動作をする。

Map colors = new HashMap();
colors.put("red", new Integer(0xff0000));
colors.put("green", new Integer(0x00ff00));
colors.put("blue", new Integer(0x0000ff));

マップ初期化子の色付けの拡張

ここではマップ初期化子部分についての色付けを行う。

---

実現方法

ここでは、マップ初期化子部分を通常の Java プログラムとは異なる部分と見立 てて、この部分を切り出す方法を採用する。 つまり、マップ初期化子部分を切り出し、この部分を独立したパーティションと して新たな内容種別を付与する。

マップ初期化子は Java のプログラムコードの一部であり、その間にコメ ント等が出現しうるので、ここで説明したような新たなパーティションとして切 り出す手法は適切ではない。 しかしながら、今回は pxml を実装した場合を想定し、新たなパーティションを 追加する方法の事前調査という位置づけで、あえてマップ初期化子部分を Java プログラム本文とは異なるパーティションとして切り出す方法を選択した。

パーティションの範囲および内容種別の判定は JavaPartitionScanner が行って いる。今回はさらに IJavaPartitions にパーティションの内容種別を追加した。 ただし、実際に内容種別を追加してしまうと、新たに追加されたパーティション 種別に対して、フォント装飾等の動作クラスを実装しなければならず、影響範囲 が大きいため、内容種別の定義文字列はコメントと同様のものを利用することと した。

---

実装

今回対象となる Eclipse のソースツリーは、前回の調査報告 に記述したマップ初期化子構文に関するコンパイラ拡張が既に適用されているも のとする。

変更が未適応の場合でもマップ初期化子構文の色づけは行われるが、 パースに失敗するためエラーなどのマーカーが表示される。

変更対象ファイルは、 org.eclipse.jdt.ui プラグインの ui ディレクトリの org.eclipse.jdt.internal.ui.text パッケージにある、 FastJavaPartitionScanner および IJavaPartitions である。

IJavaPartitions には新たなパーティション内容種別として JAVA_MAP_INITIALIZER を追加する。ただし、ここでは実体は JAVA_MULTI_LINE_COMMENT と同じ物を代入する。 ソースは下記のとおりである。

... public interface IJavaPartitions { public final static String JAVA_SINGLE_LINE_COMMENT= "__java_singleline_comment"; //$NON-NLS-1$ public final static String JAVA_MULTI_LINE_COMMENT= "__java_multiline_comment"; //$NON-NLS-1$ public final static String JAVA_DOC= "__java_javadoc"; //$NON-NLS-1$ public final static String JAVA_STRING= "__java_string"; //$NON-NLS-1$ public final static String JAVA_CHARACTER= "__java_character"; //$NON-NLS-1$ // ************** for map initializer ************** public final static String JAVA_MAP_INITIALIZER= JAVA_MULTI_LINE_COMMENT ; // ************************************************* }

続いて、実際にスキャンしている部分である FastJavaPartitionScanner を修正 する。 ここでの修正点は下記のとおりである。

• スタティック変数の追加

  クラス冒頭部分にスタティック変数を追記する。

  ... public class FastJavaPartitionScanner implements IPartitionTokenScanner, IJavaPartitions { // states private static final int JAVA= 0; private static final int SINGLE_LINE_COMMENT= 1; private static final int MULTI_LINE_COMMENT= 2; private static final int JAVADOC= 3; private static final int CHARACTER= 4; private static final int STRING= 5; // ************** for map initializer ************** private static final int MAP_INITIALIZER = 6; // ************************************************* // beginning of prefixes and postfixes private static final int NONE= 0; private static final int BACKSLASH= 1; // postfix for STRING and CHARACTER private static final int SLASH= 2; // prefix for SINGLE_LINE or MULTI_LINE or JAVADOC private static final int SLASH_STAR= 3; // prefix for MULTI_LINE_COMMENT or JAVADOC private static final int SLASH_STAR_STAR= 4; // prefix for MULTI_LINE_COMMENT or JAVADOC private static final int STAR= 5; // postfix for MULTI_LINE_COMMENT or JAVADOC private static final int CARRIAGE_RETURN=6; // postfix for STRING, CHARACTER and SINGLE_LINE_COMMENT // ************** for map initializer ************** private static final int PERCENT=7; private static final int PLUS=8; // ************************************************* /** The scanner. */ private final BufferedDocumentScanner fScanner= new BufferedDocumentScanner(1000); // faster implementation ...

• IToken[] fTokens (63行目) に上記で追加したスタティック変数を追加

  ... private final IToken[] fTokens= new IToken[] { new Token(null), new Token(JAVA_SINGLE_LINE_COMMENT), new Token(JAVA_MULTI_LINE_COMMENT), new Token(JAVA_DOC), new Token(JAVA_CHARACTER), new Token(JAVA_STRING), // ************** for map initializer ************** new Token(JAVA_MAP_INITIALIZER) // ************************************************* }; ...

• nextToken メソッド(75行目) のキャラクタの判定部分にパーセントを判定する コードを追加(190行目近辺)

  ... public IToken nextToken() { ... while (true) { ... switch (ch) { ... default: if (!fgEmulate && fLast == CARRIAGE_RETURN) { switch (fState) { case SINGLE_LINE_COMMENT: case CHARACTER: case STRING: int last; int newState; switch (ch) { case '/': last= SLASH; newState= JAVA; break; case '*': last= STAR; newState= JAVA; break; case '\'': last= NONE; newState= CHARACTER; break; case '"': last= NONE; newState= STRING; break; // ************** for map initializer ************** case '%': last= PERCENT; newState= JAVA; break; // ************************************************* case '\r': last= CARRIAGE_RETURN; newState= JAVA; break; case '\\': last= BACKSLASH; newState= JAVA; break; default: last= NONE; newState= JAVA; break; } fLast= NONE; // ignore fLast return preFix(fState, newState, last, 1); default: break; } } } ...

• nextToken メソッド(75行目) の Java プログラム中に出現するパーティション 開始位置の判定部分にコードを追加(252行目近辺)

  ... // states switch (fState) { case JAVA: switch (ch) { case '/': ... case '*': if (fLast == SLASH) { ... } else { consume(); break; } // ************** for map initializer ************** case '%': fTokenLength++; fLast= PERCENT; break; case '{': if (fLast == PERCENT) { if (fTokenLength - getLastLength(fLast) > 0) return preFix(JAVA, MAP_INITIALIZER, PLUS, 2); else { preFix(JAVA, MAP_INITIALIZER, PLUS, 2); fTokenOffset += fTokenLength; fTokenLength= fPrefixLength; break; } } else { consume(); break; } // ************************************************* case '\'': fLast= NONE; // ignore fLast if (fTokenLength > 0) return preFix(JAVA, CHARACTER, NONE, 1); else { preFix(JAVA, CHARACTER, NONE, 1); fTokenOffset += fTokenLength; fTokenLength= fPrefixLength; break; } case '"': ... default: consume(); break; } break; case SINGLE_LINE_COMMENT: consume(); break; case JAVADOC: ...

• nextToken メソッド(75行目) にマップ初期化子区間の終了判定の条件を追加 (337行目近辺)

  ... case JAVADOC: ... case MULTI_LINE_COMMENT: switch (ch) { case '*': if (fLast == SLASH_STAR) { fLast= SLASH_STAR_STAR; fTokenLength++; fState= JAVADOC; } else { fTokenLength++; fLast= STAR; } break; case '/': if (fLast == STAR) { return postFix(MULTI_LINE_COMMENT); } else { consume(); break; } default: consume(); break; } break; // ************** for map initializer ************** case MAP_INITIALIZER: switch (ch) { case '}': return postFix(MAP_INITIALIZER); default: consume(); break; } break; // ************************************************* case STRING: switch (ch) { case '\\': fLast= (fLast == BACKSLASH) ? NONE : BACKSLASH; fTokenLength++; break; case '\"': if (fLast != BACKSLASH) { return postFix(STRING); } else { consume(); break; } default: consume(); break; } break; case CHARACTER: ... } } } ...

• getState メソッド(442行目) の内容種別判定部分にマップ初期化子に関するも のを追加(461行目近辺)。

  ... private static final int getLastLength(int last) { switch (last) { default: return -1; case NONE: return 0; case CARRIAGE_RETURN: case BACKSLASH: case SLASH: case STAR: // ************** for map initializer ************** case PERCENT: // ************************************************* return 1; case SLASH_STAR: return 2; case SLASH_STAR_STAR: return 3; } } ...

以上の変更を適用した上で Eclipse を再構築することで、 マップ初期化子に対応した Eclipse が生成される。 なお詳細は、添付のソースを参照されたし。