Java-Code kompilieren

Die JDT-Plug-ins umfassen einen Java-Compiler, mit dem Java-Klassendateien (.class) entweder schrittweise oder im Stapelmodus aus dem Quellcode erstellt werden können. Der Compiler stellt keine direkte API zur Verfügung. Sie wird als Erstellungsprogramm für Java-Projekte installiert. Die Kompilierung wird mit Hilfe von Standarderstellungsmechanismen der Plattform ausgelöst.

Der Erstellungsmechanismus der Plattform ist unter Programme für die schrittweise Projekterstellung ausführlich beschrieben.

Code kompilieren

Mit der Erstellungs-API können Sie die Java-Quellendateien in einem Projekt programmgestützt kompilieren.

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

Auf diese Weise wird das Programm zur schrittweisen Java-Projekterstellung für ein Java-Projekt aufgerufen (zusammen mit anderen Programmen zur schrittweisen Projekterstellung, die zur Erstellungsspezifikation des Projekts hinzugefügt wurden). Die generierten .class-Dateien werden in den designierten Ausgabeordner geschrieben. Zusätzliche Ressourcendateien werden ebenso in den Ausgabeordner kopiert. 

Im Falle einer vollständigen Stapelerstellung werden möglicherweise alle .class-Dateien im Ausgabeordner "bereinigt", um sicherzustellen, dass keine alten Dateien gefunden werden. Dies wird mit Hilfe einer JDT-Kernerstellungsprogrammoption (CORE_JAVA_BUILD_CLEAN_OUTPUT_FOLDER) gesteuert.  Der Standardwert für diese Option ist das Bereinigen der Ausgabeordner. Wenn diese Option nicht zurückgesetzt ist, müssen Sie sicherstellen, dass Sie alle Dateien mit der Erweiterung .class, für die Sie keine entsprechenden Quellendateien in einem separaten Klassendateiordner haben, in den Klassenpfad stellen und nicht in den Ausgabeordner.

Die inkrementellen und Stapelerstellungsprogramme können mit anderen Optionen konfiguriert werden, die steuern, welche Ressourcen in den Ausgabeordner kopiert werden. Das folgende Beispiel zeigt, wie ein Ressourcenfilter eingerichtet wird, so dass Dateien mit der Erweiterung '.ignore' und Ordner mit dem Namen 'META-INF' nicht in den Ausgabeordner kopiert werden.

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

Dateinamen werden herausgefiltert, wenn Sie mit einem der bereitgestellten Muster übereinstimmen. Ganze Ordner werden herausgefiltert, wenn Ihre Namen mit denen der bereitgestellten Ordnernamen übereinstimmen, die in einem Pfadseperator enden.

Die schrittweisen Erstellungsprogramme und die Stapelerstellungsprogramme können auch so konfiguriert werden, dass sie nur einen einzigen Fehler generieren, wenn die .classpath-Datei Fehler enthält. Diese Option wird standardmäßig eingerichtet und eliminiert zahlreiche Fehler.  Eine vollständige Liste der Optionen und Standardwerte für die Erstellungsprogramme finden Sie unter Optionen für JDT-Kernerstellungsprogramme.

Der Compiler kann auch unter Verwendung von JavaCore-Optionen konfiguriert werden. Sie können zum Beispiel die Wertigkeit definieren, die für unterschiedliche Arten von Fehlern verwendet werden soll, wenn diese während der Kompilierung auftreten.  Eine vollständige Liste der Optionen und Standardwerte für die Compiler finden Sie unter Optionen für JDT-Kerncompiler.

Bei der Konfiguration von Optionen für das Erstellungsprogramm oder den Compiler über das Programm sollten Sie den Bereich der Option angeben. Die Einstellung eines Ressourcenfilters kann zum Beispiel nur für ein bestimmtes Projekt gelten:

   
   Hashtable options = myProject.getOptions(false);  // get only the options set up in this project
   options.put(JavaCore.CORE_JAVA_BUILD_RESOURCE_COPY_FILTER, "*.ignore,META-INF/");
   myProject.setOptions(options);

Verwendung des Stapelcompilers

Finden des Stapelcompilers

Die Klasse des Stapelcompilers befindet sich in der internen Klasse des JDT-Kern-Plug-ins. Der Name der Klasse ist org.eclipse.jdt.internal.compiler.batch.Main. Sie befindet sich im Paket plugins/org.eclipse.jdt.core_3.2.0.jar. Seit Version 3.2 ist sie ebenfalls als separater Download verfügbar. Der Name der Datei lautet ecj.jar. Die entsprechende Quelle ist ebenfalls verfügbar. Zum Abrufen gehen Sie zu Seite herunterladen und suchen nach dem Abschnitt zum Thema JDT-Kernstapelcompiler. Diese JAR-Datei enthält den Stapelcompiler und den javac-ant-Adapter.

Auf diese Weise kann er als eigenständige Anwendung und innerhalb einer ant-Erstellung außerhalb von Eclipse verwendet werden.

Ausführen des Stapelcompilers

Welche Optionen stehen zur Verfügung?

Die Optionen mit orangefarbigem Hintergrund sind die empfohlenen Optionen.

Name Verwendung
Klassenpfad-Optionen
-bootclasspath <dir 1>;<dir 2>;...;<dir P> Dies ist eine Liste der Verzeichnisse oder JAR-Dateien, die für das Bootprogramm der Klassendateien vom Compiler verwendet werden. Standardmäßig werden die Bibliotheken der aktiven VM verwendet. Die Einträge werden durch das Pfadtrennzeichen der Plattform getrennt.
Jedes Verzeichnis oder jede Datei kann Zugriffsregeln für Typen zwischen '[' und ']' angeben.
-cp
-classpath <dir 1>;<dir 2>;...;<dir P>
Dies ist eine Liste der Verzeichnisse und JAR-Dateien, die zum Kompilieren der Quellendateien verwendet werden. Der Standardwert ist der Wert der Eigenschaft "java.class.path". Die Einträge werden durch das Pfadtrennzeichen der Plattform getrennt.
Jedes Verzeichnis oder jede Datei kann Zugriffsregeln für Typen zwischen '[' und ']' angeben. (Zum Beispiel [-X] für verbotenen Zugriff auf den Typ X, [~X] nicht empfohlener Zugriff auf den Typ X, [+p/X:-p/*] für verbotenen Zugriff auf alle Typen im Paket p, wobei der Zugriff auf p/X erlaubt ist).
-extdirs <dir 1>;<dir 2>;...;<dir P> Dies ist eine Liste der Verzeichnisse, die für die Angabe der Position der zip/jar-Erweiterungsdateien verwendet werden. Die Einträge werden durch das Pfadtrennzeichen der Plattform getrennt.
-endorseddirs <dir 1>;<dir 2>;...;<dir P> Dies ist eine Liste der Verzeichnisse, die zur Angabe der Position gebilligter zip/jar-Dateien verwendet werden. Die Einträge werden durch das Pfadtrennzeichen der Plattform getrennt.
-sourcepath <dir 1>;<dir 2>;...;<dir P> Dies ist eine Liste der Verzeichnisse, die zur Angabe der Quellendatei verwendet werden. Die Einträge werden durch das Pfadtrennzeichen der Plattform getrennt.
Jedes Verzeichnis kann Zugriffsregeln für Typen zwischen '[' und ']' angeben.
-d <dir 1>|none Dies wird verwendet um anzugeben, in welchem Verzeichnis Speicherauszüge der generierten .class-Dateien erstellt werden sollen. Wird dies übergangen, wird keine Paketverzeichnisstruktur erstellt.
Wenn Sie auf keinen Fall eine Datei mit der Erweiterung .class generieren wollen, verwenden Sie -d none.
-encoding <encoding name> Geben Sie das Standardformat für die Quellcodierung an (es kann auch angepasste Codierung für jede Datei einzeln angegeben werden, indem jeder Name der Quellendatei bzw. des Quellenordners mit einem Suffix [<encoding name>] versehen wird; zum Beispiel X.java[utf8]).
Optionen für Kompatibilität
-target 1.1|1.2|1.3|1.4|1.5|5|5.0|1.6|6|6.0 Dadurch wird die Zieleinstellung der .class-Datei angegeben. Folgende Werte sind möglich:
  • 1.1 (übergeordnete Version: 45 untergeordnete: 3)
  • 1.2 (übergeordnete Version: 46 untergeordnete: 0)
  • 1.3 (übergeordnete Version: 47 untergeordnete: 0)
  • 1.4 (übergeordnete Version: 48 untergeordnete: 0)
  • 1.5, 5 oder 5.0 (übergeordnete Version: 49 untergeordnete: 0)
  • 1.6, 6 oder 6.0 (übergeordnete Version: 50 untergeordnete: 0)
Die Standardwerte sind:
  • 1.1 in -1.3 mode
  • 1.2 in -1.4 mode
  • 1.5 in -1.5 mode
  • 1.6 in -1.6 mode
-1.3 Konformitätsstufe auf 1.3 festlegen. Implizit -source 1.3 -target 1.1.
-1.4 Konformitätsstufe auf 1.4 (Standardwert) festlegen. Implizit -source 1.3 -target 1.2.
-1.5 Konformitätsstufe auf 1.5 festlegen. Implizit -source 1.5 -target 1.5.
-1.6 Konformitätsstufe auf 1.6 festlegen. Implizit -source 1.6 -target 1.6.
-source 1.3|1.4|1.5|5|5.0|1.6|6|6.0 Diese Einstellung wird verwendet, um die vom Compiler erwarteten Quellenebenen anzugeben.
Folgende Werte sind möglich:
  • 1.3
  • 1.4
  • 1.5, 5 oder 5.0
  • 1.6, 6 oder 6.0
Die Standardwerte sind:
  • 1.3 in -1.3 mode
  • 1.3 in -1.4 mode
  • 1.5 in -1.5 mode
  • 1.6 in -1.6 mode
In 1.4 wird assert als Schlüsselwort behandelt. In 1.5 und 1.6 werden enum und assert als Schlüsselwörter behandelt.
Optionen für Warnung
-warn:
allDeprecation
allJavadoc
assertIdentifier
boxing
charConcat
conditionAssign
constructorName
dep-ann
deprecation
discouraged
emptyBlock
enumSwitch
fallthrough
fieldHiding
finalBound
finally
forbidden
hiding
incomplete-switch
indirectStatic
intfAnnotation
intfNonInherited
javadoc
localHiding
maskedCatchBlocks
nls
noEffectAssign
null
over-ann
paramAssign
pkgDefaultMethod
raw
semicolon
serial
specialParamHiding
static-access
staticReceiver
suppress
synthetic-access
syntheticAccess
tasks(<task1>|...|<taskN>)
typeHiding
unchecked
unnecessaryElse
unqualified-field-access
unqualifiedField
unused
unusedArgument
unusedImport
unusedLabel
unusedLocal
unusedPrivate
unusedThrown
uselessTypeCheck
varargsCast
warningToken
Legt die Stufe für Warnungen fest.
Beispiel: -warn:unusedLocal,deprecation

In Rot werden die Standardeinstellungen angegeben.

    -warn:none                               alle Warnungen inaktivieren
    -warn:<warnings separated by ,>    genau die aufgelisteten Warnungen aktivieren
    -warn:+<warnings separated by ,>   zusätzliche Warnungen aktivieren
    -warn:-<warnings separated by ,>   bestimmte Warnungen inaktivieren
allDeprecation Veraltung selbst innerhalb eines veralteten Codes
allJavadoc Ungültiges oder fehlendes Javadoc
assertIdentifier Vorkommen von assert verwendet als Kennung
boxing autoboxing-Umsetzung
charConcat wenn ein Zeichenbereich in einer Verkettung von Zeichenfolgen verwendet wird, ohne explizit in eine Zeichenfolge konvertiert worden zu sein
conditionAssign mögliche unbeabsichtigte Boolesche Zuordnung
constructorName Methode mit einem Konstruktornamen
dep-ann fehlende Anmerkung '@Deprecated'
deprecation Verwendung eines veralteten Typs oder Members außerhalb eines veralteten Codes
discouraged Verwendung von Typen, die einer nicht empfohlenen Zugriffsregel entsprechen
emptyBlock Nicht dokumentierter leerer Block
enumSwitch,
incomplete-switch
Unvollständiger enum-Switch
fallthrough Möglicher Auslassungsfall
fieldHiding Feld, das weitere Variable verdeckt
finalBound Typparameter mit Endbindung
finally finally-Block wird nicht normal beendet
forbidden Verwendung von Typen, die einer verbotenen Zugriffsregel entsprechen
hiding Makro für fieldHiding, localHiding, typeHiding und maskedCatchBlock
indirectStatic Indirekter Verweis auf statisches Member
intfAnnotation Anmerkungstyp wird als Superschnittstelle verwendet
intfNonInherited Kompatibilität mit nicht übernommener Schnittstelle
javadoc Ungültiges Javadoc
localHiding Lokale Variable, die weitere Variable verdeckt
maskedCatchBlocks Verdeckter catch-Block
nls Nicht-NLS Zeichenfolgeliteral (fehlende Tags //$NON-NLS-<n>)
noEffectAssign Zuordnung ohne Auswirkung
null Fehlende oder redundante Nullüberprüfung
over-ann Fehlende Anmerkung '@Override'
paramAssign Zuordnung zu einem Parameter
pkgDefaultMethod Versuch des Überschreibens der Standardmethode eines Pakets
raw Verwendung des unformatierten Typs (an Stelle des parametrisierten Typs)
semicolon Unnötiges Semikolon oder leere Anweisung
serial Fehlende serialVersionUID
specialParamHiding Konstruktor oder Setter-Parameter verdeckt anderes Feld
static-access Makro für indirectStatic und staticReceiver
staticReceiver Wenn ein nicht statischer Empfänger verwendet wird, um ein statisches Feld abzurufen oder eine statische Methode aufzurufen
suppress @SuppressWarnings aktivieren
syntheticAccess,
synthetic-access
Bei der Durchführung eines synthetischen Zugriffs für eine untergeordnete Klasse
tasks Unterstützung für Task-Tags im Quellcode aktivieren
typeHiding Typparameter verdeckt einen anderen Typ
unchecked Nicht überprüfte Typoperation
unnecessaryElse Nicht erforderliche ELSE-Klausel
unqualified-field-access,
unqualifiedField
Nicht qualifizierter Verweis auf Feld
unused Makro für unusedArgument, unusedImport, unusedLabel, unusedLocal, unusedPrivate und unusedThrown
unusedArgument Nicht verwendetes Methodenargument
unusedImport Nicht verwendeter Importverweis
unusedLabel Nicht verwendete Bezeichnung
unusedLocal Nicht verwendete lokale Variable
unusedPrivate Nicht verwendete Deklaration von privatem Member
unusedThrown Nicht verwendete ausgelöste Ausnahmebedingung
uselessTypeCheck Nicht erforderliche cast/instanceof-Operation
varargsCast Argument 'varargs' erfordert explizite Umsetzung
warningToken Nicht bearbeitetes Warnungs-Token in @SuppressWarnings

-nowarn Keine Warnung (entspricht -warn:none)
-deprecation Entspricht -warn:deprecation.
Optionen für Debug
-g[:none|:lines,vars,source] Debug-Attributstufen festlegen
-g Alle Debug-Informationen (entspricht -g:lines,vars,source)
-g:none Keine Debug-Informationen
-g:[lines,vars,source] Selektive Debug-Informationen
-preserveAllLocals Den Compiler explizit auffordern, alle lokalen Variablen beizubehalten (für Debug-Zwecke). Der Compiler entfernt nicht verwendete lokale Variablen, wenn diese Angabe fehlt.
Ignorierte Optionen (zur Kompatibilität mit javac-Optionen)
-J<option> Option an die virtuelle Maschine übergeben
-X<option> Vom Standard abweichende Option angeben. -Xemacs wird nicht ignoriert.
-X Vom Standard abweichende Optionen drucken und beenden.
-O Ausführungszeit optimieren
Erweiterte Optionen
@<file> Befehlszeilenargumente aus Datei lesen
-maxProblems <n> Maximale Anzahl an Fehlern pro Kompiliereinheit (standardmäßig 100)
-log <filename> Angabe einer Protokolldatei, in der ein Speicherauszug aller Ausgaben des Compilers erstellt wird. Dies ist sehr hilfreich, wenn Sie ein Debug für den Stapelcompiler ausführen oder eine Datei abrufen möchten, die alle Fehler und Warnungen aus einer Stapelerstellung enthält. Wenn die Erweiterung .xml lautet, wird das generierte Protokoll eine xml-Datei sein.
-Xemacs emacs-Darstellung verwenden, um Fehler- und Warnungspositionen in der Konsole und regulären Textprotokollen darzustellen. XML-Protokolle sind von dieser Option nicht betroffen. Wenn diese Option aktiv ist, wird die Nachricht:
2. WARNING in /workspace/X.java
(at line 8)...

wie folgt dargestellt:
/workspace/X.java:8: warning: The method...
-proceedOnError Kompilieren trotz Fehlern, Speicherauszugsklassendateien mit Fehlermethoden oder Fehlertypen fortsetzen. Dies ist nur dann zu empfehlen, wenn Sie Ihre Anwendung selbst dann ausführen möchten, wenn noch Fehler vorhanden sind.
-verbose Druckt, wenn angegeben, zugegriffene/verarbeitete Kompiliereinheiten in der Konsole oder der Protokolldatei.
-referenceInfo Verweisinformationen berechnen. Dies ist nur dann hilfreich, wenn eine Verbindung zu dem Erstellungsprogramm besteht. Andernfalls sind die Verweisinformationen nutzlos.
-progress Fortschritt anzeigen (nur im Protokollmodus -log).
-time Geschwindigkeitsdaten anzeigen.
-noExit Am Ende der Kompilierung System.exit(n) nicht aufrufen (n=0 , wenn kein Fehler).
-repeat <n> Kompiliervorgang wiederholen <n> Mal (Leistungsanalyse).
-inlineJSR Integrierter JSR-Bytecode (implizit wenn Ziel >= 1.5).
-enableJavadoc Verweise innerhalb von javadoc beachten.
Optionen für die Hilfe
-? -help Hilfenachricht anzeigen.
-v -version Build-Nummer des Compilers anzeigen. Dies ist sehr nützlich, um einen Programmfehler zu melden.
-showversion Build-Nummer des Compilers anzeigen und fortfahren. Dies ist sehr nützlich, um einen Programmfehler zu melden.

Beispiele

d:\temp -classpath rt.jar -time -g -d d:/tmp Es kompiliert alle Quellendatei in d:\temp und dessen Unterordnern. Der Klassenpfad ist einfach rt.jar. Es generiert alle Debug-Attribute und von allen generierten .class-Dateien wird ein Speicherauszug erstellt in d:\tmp. Die Geschwindigkeit des Compilers wird angezeigt, wenn der Stapelprozess abgeschlossen ist.
d:\temp\Test.java -classpath d:\temp;rt.jar -g:none Kompiliert nur Test.java und seine gegebenenfalls vorhandenen abhängigen Dateien im Verzeichnis d:\temp. Der Klassenpfad lautet d:\temp gefolgt von rt.jar. Das bedeutet, dass alle notwendigen Klassen zuerst in d:\temp und anschließend in rt.jar gesucht werden. Es werden keine Debug-Attribute generiert, und für alle generierten Dateien mit der Erweiterung .class wird ein Speicherauszug in d:\temp erstellt.

ant javac-Adapter verwenden

Der Eclipse-Compiler kann unter Verwendung des javac-Adapters innerhalb eines Ant-Scripts verwendet werden. Um den Eclipse-Compiler zu verwenden, definieren Sie einfach die Eigenschaft build.compiler in Ihrem Script. Beispiel:
<?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>
Die für die ant javac-Task verwendete Syntax finden Sie in der Dokumentation zur ant javac-Task. Der aktuelle Adapter unterstützt die Javac Ant_Task der Versionen 1.4.1 bis 1.6.5.

Wenn Sie eine Version höher als 1.5.0 verwenden, können Sie das verschachtelte Compilerargument-Element verwenden, um compiler-spezifische Optionen anzugeben.

...
<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>
    <compilerarg compiler="org.eclipse.jdt.core.JDTCompilerAdapter" line="-1.5 -warn:+boxing"/>
</javac>		
...

Um zu vermeiden, dass Sie vom Compiler abhängige Scripts erhalten, empfehlen wir die Verwendung des Compilerarguments mit der Einstellung org.eclipse.jdt.core.JDTCompilerAdapter. Ist dieses nicht eingestellt, kann das Script nur mit dem Eclipse-Compiler verwendet werden. Ist dieses eingestellt, wird das verschachtelte Compiler-Argument ignoriert, falls der Name anders ist als der Compilername, der durch die Eigenschaft build.compiler angegeben wird.

Probleme ermitteln

Der JDT-Kern definiert eine spezielle Markierung (Markierungstyp "org.eclipse.jdt.core.problem"), die auf Kompilierungsprobleme hinweist. Damit durch den Compiler festgestellte Probleme programmgestützt ermittelt werden können, sollte das Standardmarkierungsprotokoll der Plattform verwendet werden. Eine Übersicht über die Verwendung von Markierungen finden Sie unter Ressourcenmarkierungen.

Der folgende Ausschnitt sucht in einer Kompiliereinheit nach allen Java-Problemmarkierungen.

   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-Problemmarkierungen werden durch das Programm für die Java-Projekterstellung verwaltet und automatisch entfernt, sobald die Probleme gelöst wurden und die Java-Quelle erneut kompiliert wird.

Der Wert der Fehler-ID wird auf eine der in IProblem definierten Konstanten gesetzt. Die Fehler-ID ist zwar zuverlässig, die Nachricht wird jedoch lokalisiert und kann daher entsprechend der standardmäßigen Ländereinstellung geändert werden. Die in IProblem definierten Konstanten erklären sich selbst.

Eine Implementierung von IProblemRequestor sollte definiert werden, um die während einer Java-Verarbeitung aufgespürten Fehler zu sammeln. Arbeitskopien können mit der Fehlererkennung ausgeglichen werden, wenn ein IProblemRequestor für die Erstellung der Arbeitskopie zur Verfügung gestellt wurde. Zu diesem Zweck können Sie die Methode Ausgleich verwenden. Beispiel:

  ICompilationUnit unit = ..; // Kompiliereinheit abrufen
			
  // Requestor zum Sammeln erkannter Fehler erstellen
  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; } // erkennt Fehler, wenn aktiv
  };

  // für Quelle mit Fehler eine Arbeitskopie verwenden
  ICompilationUnit workingCopy = unit.getWorkingCopy(new WorkingCopyOwner() {}, problemRequestor, null);
  ((IOpenable)workingCopy).getBuffer().setContents("public class X extends Zork {}");

  // trigger reconciliation			
  workingCopy.reconcile(NO_AST, true, null, null);
Sie können mit der Methode acceptProblem (IProblem) eine Aktion für die gemeldeten Fehler hinzufügen. In diesem Beispiel ist die Fehlermeldung, dass Zork nicht aufgelöst werden kann oder keine gültige Superklasse ist. Die Fehler-ID ist IProblem.SuperclassNotFound.

Warnungen mit SuppressWarnings ausschließen

Java 5.0 bietet dem Benutzer die Option, Kompilierungswarnungen im Hinblick auf eine Untergruppe einer Kompiliereinheit mit der Anmerkung java.lang.SuppressWarning zu inaktivieren.

	@SuppressWarning("unused") public void foo() {
		String s;
	}

Ohne die Anmerkung würde der Compiler bemängeln, dass die lokale Variable s nie verwendet wird. Mit der Anmerkung ignoriert der Compiler diese Warnung ohne Reaktion lokal für die Methode foo. Dadurch wird aktiviert, dass die Warnungen an anderen Positionen derselben Kompiliereinheit oder desselben Projekts beibehalten werden.

Es folgt eine Liste der Tokens, die innerhalb einer Anmerkung SuppressWarning verwendet werden können: