JDT プラグインには、ソース・コードから Java の .class ファイルをビルドするためのインクリメンタル Java コンパイラーおよびバッチ Java コンパイラーが含まれています。 このコンパイラーは、直接 API を提供していません。 直接 API は、Java プロジェクトに対するビルダーとしてインストールされます。 コンパイルは、プラットフォームの標準のビルド・メカニズムを使用して起動されます。
プラットフォームのビルド・メカニズムについては、 「リソース・ビルダー」で詳細に説明されています。
ビルド API を使用すると、プロジェクトの Java ソース・ファイルをプログラムでコンパイルすることができます。
IProject myProject; IProgressMonitor myProgressMonitor; myProject.build(IncrementalProjectBuilder.INCREMENTAL_BUILD, myProgressMonitor);
Java プロジェクトの場合、このコードにより Java インクリメンタル・プロジェクト・ビルダーが (プロジェクトのビルド・スペックに追加されている他のすべてのインクリメンタル・プロジェクト・ビルダーとともに) 起動されます。 生成された .class ファイルは、指定の出力フォルダーに書き込まれます。 フル・バッチ・ビルドの場合、不整合ファイルが見つからなくなるように出力フォルダー内のすべての .class ファイルが「修正」されます。 対応するソース・ファイルがない .class ファイルはすべて、出力フォルダーではなく、クラスパスの別のクラス・ファイル・フォルダーに入れてください。
その他のリソース・ファイルも出力フォルダーにコピーされます。
リソース・フィルターを使用して、どのリソース・ファイルをコピーするかを制御できます。
たとえば、'.ignore' で終わるファイルと 'META-INF' という名前のフォルダーをフィルターに掛ける場合は、次のようにします。
Hashtable options = JavaCore.getOptions();
options.put(JavaCore.CORE_JAVA_BUILD_RESOURCE_COPY_FILTER, "*.ignore,META-INF/");
JavaCore.setOptions(options);
指定されたいずれかのパターンにファイル名が一致する場合、ファイル名がフィルターに掛けられます。 パス区切り文字で終わる指定されたフォルダー名のいずれかとフォルダー名が一致する場合、 そのフォルダー全体がフィルターに掛けられます。
インクリメンタルおよびバッチ・ビルダーは、.classpath ファイルにエラーがあるときに 1 つのエラーのみを生成するように構成することもできます。 このオプションはデフォルトで設定され、多くのエラーを除去します。 これらのエラーの原因は通常 jar ファイルの欠落です。 JavaCore の CORE_JAVA_BUILD_INVALID_CLASSPATH オプションを参照してください。
<?xml version="1.0" encoding="UTF-8"?>javac Ant タスクで使用される構文は、 Ant javac タスク・ドキュメンテーションにあります。 現行アダプターは、Javac Ant タスク 1.4.1 をサポートしています。 Ant 1.5 がリリースされると、A 1.5 バージョンが使用可能になります。
<project name="compile" default="main" basedir="../.">
<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/> <property name="root" value="${basedir}/src"/> <property name="destdir" value="d:/temp/bin" /> <target name="main"> <javac srcdir="${root}" destdir="${destdir}" debug="on" nowarn="on" extdirs="d:/extdirs" source="1.4"> <classpath> <pathelement location="${basedir}/../org.eclipse.jdt.core/bin"/> </classpath> </javac> </target> </project>
JDT コアは、コンパイルの問題を示すための特別なマーカー (org.eclipse.jdt.core.problem というマーカー型) を定義します。 コンパイラーによって検出された問題をプログラムで発見するには、 プラットフォームの標準のマーカー・プロトコルを使用する必要があります。 マーカーの使用方法の概要については、 「リソース・マーカー」を参照してください。
以下のコードの断片により、コンパイル単位内のすべての Java 問題のマーカーが検出されます。
public IMarker[] findJavaProblemMarkers(ICompilationUnit cu)
throws CoreException {
IResource javaSourceFile = cu.getUnderlyingResource();
IMarker[] markers =
javaSourceFile.findMarkers(IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER,
true, IResource.DEPTH_INFINITE);
}
Java 問題マーカーは、Java プロジェクト・ビルダーによって保守され、問題が解決されて Java ソースが再コンパイルされると、自動的に除去されます。
問題の ID 値は、IProblem 内のいずれかの定数によって設定されます。 問題の ID は信頼性のあるものですが、メッセージはローカライズされ、デフォルト・ロケールに応じて変更されます。 IProblem に定義されている定数は自己記述です。
IProblemRequestor
のインプリメンテーションは、Java 操作中に検出された問題を収集するように定義する必要があります。
作業用コピーの作成に
IProblemRequestor
が与えられた場合、作業用コピーは問題検出と調整することができます。
これを行うには、
reconcile
メソッドを使用できます。
以下に例を示します。
ICompilationUnit unit = ..; // get some compilation unit
// create requestor for accumulating discovered problems
IProblemRequestor problemRequestor = new IProblemRequestor() {
public void acceptProblem(IProblem problem) {
System.out.println(problem.getID() + ": " + problem.getMessage());
}
public void beginReporting() {}
public void endReporting() {}
public boolean isActive() { return true; } // will detect problems if active
};
// use working copy to hold source with error
IWorkingCopy workingCopy = (IWorkingCopy)unit.getWorkingCopy(null, null, problemRequestor);
((IOpenable)workingCopy).getBuffer().setContents("public class X extends Zork {}");
// trigger reconciliation
workingCopy.reconcile(true, null);
acceptProblem(IProblem) メソッドで報告された問題について、処置を追加することができます。
この例では、報告された問題は、Zork を解決できないか、または有効なスーパークラスではないということと、問題の
ID が IProblem.SuperclassNotFound であるということです。