Compiling Java code

The JDT plug-ins include an incremental and batch Java compiler for building Java .class files from source code. There is no direct API provided by the compiler. It is installed as a builder on Java projects. Compilation is triggered using standard platform build mechanisms.

The platform build mechanism is described in detail in resource builders .

Compiling code

You can programmatically compile the Java source files in a project using the build API.

   IProject myProject;
   IProgressMonitor myProgressMonitor;
   myProject.build(IncrementalProjectBuilder.INCREMENTAL_BUILD, myProgressMonitor);

For a Java project, this invokes the Java incremental project builder (along with any other incremental project builders that have been added to the project's build spec). The generated .class files are written to the designated output folder. In the case of a full batch build, all the .class files in the output folder are 'scrubbed' to ensure that no stale files are found. Make sure that you place all your .class files, for which you do not have corresponding source files, in separate class file folders on the classpath instead of the output folder.

Additional resource files are also copied to the output folder. You can control which resource files are copied using the resource filter. For example, to filter files ending with '.ignore' and folders named 'META-INF', use:

   Hashtable options = JavaCore.getOptions();
options.put(JavaCore.CORE_JAVA_BUILD_RESOURCE_COPY_FILTER, "*.ignore,META-INF/");
JavaCore.setOptions(options);

Filenames are filtered if they match one of the supplied patterns. Entire folders are filtered if their name matches one of the supplied folder names which end in a path separator.

The incremental and batch builders can also be configured to only generate a single error when the .classpath file has errors. This option is set by default and eliminates numerous errors, all usually caused by a missing jar file. See the CORE_JAVA_BUILD_INVALID_CLASSPATH option of JavaCore .

Using the ant javac adapter

The Eclipse compiler can be used inside an Ant script using the javac adapter. In order to use the Eclipse compiler, you simply need to define the build.compiler property in your script. Here is a small example.
<?xml version="1.0" encoding="UTF-8"?>
<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>
The syntax used for the javac Ant task can be found in the Ant javac task documentation . The current adapter supports the Javac Ant task 1.4.1. A 1.5 version will be available when Ant 1.5 is released.

Problem determination

JDT Core defines a specialized marker (marker type "org.eclipse.jdt.core.problem ") to denote compilation problems. To programmatically discover problems detected by the compiler, the standard platform marker protocol should be used. See resource markers for an overview of using markers.

The following snippet finds all Java problem markers in a compilation unit.

   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 problem markers are maintained by the Java project builder and are removed automatically as problems are resolved and the Java source is recompiled.

The problem id value is set by one of the constants in IProblem . The problem's id is reliable, but the message is localized and therefore can be changed according to the default locale. The constants defined in IProblem are self-descriptive.

An implementation of IProblemRequestor should be defined to collect the problems discovered during a Java operation. Working copies can be reconciled with problem detection if a IProblemRequestor has been supplied for the working copy creation. To achieve this, you can use the reconcile method. Here is an example:

  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);
You can add an action on the reported problems in the acceptProblem(IProblem) method. In this example, the reported problem will be that Zork cannot be resolved or is not a valid superclass and its id is IProblem.SuperclassNotFound .

Copyright IBM Corporation and others 2000, 2002. All Rights Reserved.