ToolActToolAct

Java-Formatierungstool

Java-Eingabe
Ausgabe
Zeilen: 1Zeichen: 0Bytes: 0
Zeilen: 1Zeichen: 0

Was ist Java-Formatierung?

Der Java-Formatter ordnet Java-Code mit konsistenter Einrückung, Zeilenumbrüchen und Struktur neu an, damit Klassen, Methoden, Blöcke, Generics, Annotationen und Kontrollflüsse leichter lesbar werden. Das ist hilfreich bei kopiertem Code, generierten Ausschnitten, Code-Reviews, Lernmaterial und Dateien, die durch unterschiedliche Editor-Einstellungen uneinheitlich aussehen. Formatierung verbessert Lesbarkeit und Teamarbeit, ändert aber nicht automatisch die Programmlogik, beseitigt keine Compilerfehler und ersetzt keine Stilregeln eines Projekts. Bei produktiven Repositories sollte das Ergebnis mit dem vorhandenen Formatter, Build-Tool oder CI-Standard abgeglichen werden, damit keine unnötigen Diff-Blöcke entstehen. Besonders bei produktiven Daten oder Codebasen sollte das Ergebnis anschließend mit Parser, Tests oder Projektregeln geprüft werden.

So geht's

So geht's

  1. Java-Code im linken Eingabefeld einfügen oder eingeben
  2. Einrückungsgröße auswählen (2 Leerzeichen, 4 Leerzeichen oder Tabulator)
  3. Auf 'Formatieren' klicken, um Code zu verschönern, oder 'Komprimieren', um zu komprimieren
  4. Ergebnisse rechts einsehen (mit Syntaxhervorhebung)
  5. Auf 'Kopieren' klicken, um in die Zwischenablage zu kopieren

Beschreibung der Optionen

EinrückungsgrößeWählen Sie zwischen 2 Leerzeichen, 4 Leerzeichen oder Tabulator-Einrückung
FormatierenCode mit korrekter Einrückung und Zeilenumbrüchen verschönern
KomprimierenLeerzeichen und Kommentare entfernen, um die Dateigröße zu reduzieren

Code-Tipps

  • Formatierung verbessert die Lesbarkeit, kompiliert oder typisiert jedoch keinen Java-Code. Führen Sie daher nach der Bearbeitung Ihren normalen Build oder Ihre IDE-Prüfungen aus.
  • Das Komprimieren von Java-Quellcode ist selten für Produktions-Builds sinnvoll; bewahren Sie eine lesbare Formatierung für Reviews, Stack Traces und zukünftige Wartung.

Anwendungsfälle

Eingefügten Java-Code vor dem Code-Review bereinigenWenn ein Methodenkörper aus dem Chat, der Dokumentation oder einem Ticketkommentar mit inkonsistentem Abstand kopiert wurde, stellt dieser Formatter schnell lesbare Einrückungen und Zeilenumbrüche um geschweifte Klammern und Anweisungen wieder her. Er ist besonders nützlich für kleine Ausschnitte, die eine code-review-fähige Form erhalten sollen, ohne ein vollständiges IDE-Projekt zu öffnen.
Kompakte Beispiele für Dokumentation oder Fehlerberichte vorbereitenDer Minify-Modus entfernt Kommentare und überflüssige Leerzeichen, sodass ein Java-Beispiel in ein Issue-Feld, eine Log-Annotation oder eine Reproduktionsnotiz passt, ohne zu scrollen. Da Parsing und Minifizierung vollständig im Browser stattfinden, können interne Paketnamen, unfertige DTOs oder proprietärer Code aus einem privaten Branch umgeformt werden, ohne die Seite zu verlassen – wichtig, wenn ein Reproducer noch Kundenidentifikatoren enthält.
Offensichtliche Strukturfehler in kurzen Ausschnitten erkennenDie eingebaute Validierung prüft die Klammerbalance unter Berücksichtigung von Strings, Zeichenliteralen und Kommentaren – ein fehlende geschweifte oder runde Klammer wird erkannt, bevor du den Ausschnitt woanders einfügst. Es ist kein Compiler, aber ein schneller Plausibilitätscheck für Interviewaufgaben, Dokumentationsbeispiele und isolierte Hilfsmethoden.
Generierten Code an die Projekteinrückung anpassenWechsle zwischen 2-Leerzeichen-, 4-Leerzeichen- und Tabulator-Einrückung, damit generierte Getter, Lombok-Ausgaben oder IDE-Exporte zur umgebenden Datei passen. Überspringe die Anwendung auf ein ganzes Modul, bevor du den Google Java Style, Checkstyle oder Spotless-Standard des Teams geprüft hast – sonst erzeugt der Formatter-Durchlauf ein verrauschtes Diff.
Enum- und annotationsreiche Ausschnitte sicher formatierenEingefügte Enums mit Konstanten, Methoden und Annotation-Arrays kollabieren im Chat oft zu unlesbaren Textwänden. Formatiere sie so, dass jede Konstante und ihre Argumente in eigenen Zeilen stehen, und prüfe danach, ob Imports und der public-Modifikator noch vorhanden sind. Google Java Style verlangt 4-Leerzeichen-Einrückung mit 100 Zeichen Spaltenbreite, während Eclipses Standardprofil 2-Leerzeichen-Tabulatoren und Intelligls mitgelieferter Stil oft 120 Spalten nutzt – ohne vorherige Prüfung des Teamprofils erzeugt dieser Formatter Diffs, auch wenn der Code ansonsten gültig ist. Import-Reihenfolgen (statische Imports zuerst, dann java.*, dann javax.*, dann externe, dann lokale) sind ebenfalls stilabhängig, und Generics-Klammerschreibweisen wie Map<String, List<Integer>> versus die ältere Map <String, List<Integer>>-Form werden nach Google Style ohne Leerzeichen normalisiert.

Technisches Prinzip

Die Java-Formatierung basiert auf lexikalischer Analyse und AST-Konstruktion. Der Lexer scannt die Quelle zeichenweise und erzeugt Token: Schlüsselwörter (class, public, static und andere reservierte Wörter), Bezeichner (Variablen- und Klassennamen), Literale (Zahlen, Zeichenketten, Zeichen), Operatoren (+, -, ==, &&, ...), Trennzeichen ({ } ( ) ; ,) und Kommentare (//, /* */). Der Parser wandelt den Tokenstrom gemäß der Java Language Specification in einen abstrakten Syntaxbaum (AST) um und erkennt Klassendefinitionen, Methodenkörper, Anweisungsblöcke, Kontrollflussstrukturen, Annotationen und andere syntaktische Einheiten. Der Formatter durchläuft den AST und regeneriert den Code nach einem Stilführer wie Google Java Style: Einrückung steigt mit Blocktiefe, Zeilenbreite ist auf 100 Spalten begrenzt, Operatoren erhalten Leerzeichen auf beiden Seiten, Kommas werden von einem Leerzeichen gefolgt, und öffnende geschweifte Klammern bleiben auf derselben Zeile (K&R-Stil). Die Behandlung von Annotationen ist ein Sonderfall in der Java-Formatierung: Eine einzelne Annotation bleibt auf derselben Zeile wie die Methode; längere Annotationslisten werden über Zeilen gebrochen und an den Parametern ausgerichtet, wobei jede Annotation eine eigene Zeile erhält.

  • Lexikalische Analyse: Erkennung der 50 Java-Schlüsselwörter, Bezeichner, Literale, Operatoren und Kommentare und Ausgabe eines Tokenstroms.
  • AST-Konstruktion: Aufbau des AST nach JLS-Regeln mit korrekter Behandlung von Klassen, Methoden, Kontrollfluss, Lambdas und try-with-resources.
  • Einrückungsregeln: Google Style verwendet standardmäßig 4 Leerzeichen pro Ebene mit 100 Zeichen Spaltenbreite; Zeilen über dem Limit werden automatisch umgebrochen.
  • Zeilenumbruchstrategie: Lange Methodenketten, Parameterlisten und Annotationen werden an Kommas oder Punkten umgebrochen, wobei Fortsetzungszeilen am ersten Zeichen der vorherigen Zeile ausgerichtet werden.
  • Annotationsbehandlung: Eine einzelne Annotation bleibt auf derselben Zeile; mehrere Annotationen können in einer Zeile oder eine pro Zeile stehen, entschieden nach Länge und Parametrausrichtung.
  • Kommentar-Erhaltung: //- und /* */-Kommentare werden an ihren ursprünglichen Positionen beibehalten; Entfernung ist eine Option bei der Minifizierung.

Beispiele

Formatierung einer Klassendefinition

Eingabe:  public class User{private Long id;private String name;public User(Long id,String name){this.id=id;this.name=name;}}
Ausgabe:
public class User {
  private Long id;
  private String name;

  public User(Long id, String name) {
    this.id = id;
    this.name = name;
  }
}

Formatierung einer Methodenkette

Eingabe:  List<String> result=list.stream().filter(s->s.startsWith("a")).map(String::toUpperCase).sorted().collect(Collectors.toList());
Ausgabe:
List<String> result = list.stream()
    .filter(s -> s.startsWith("a"))
    .map(String::toUpperCase)
    .sorted()
    .collect(Collectors.toList());

Umbruch von Annotationen

Eingabe:  @Override public ResponseEntity<User> getUser(@PathVariable Long id,@RequestParam(defaultValue="10") int size){...}
Ausgabe:
@Override
public ResponseEntity<User> getUser(
    @PathVariable Long id,
    @RequestParam(defaultValue = "10") int size) {
  ...
}

FAQ

Welchen Java-Stil nutzt der Formatter?

Übliche Defaults sind Google Java Style oder die Sun/Oracle-Konventionen: 4 Leerzeichen Einrückung, K&R-Klammerstil, 100 Zeichen Zeilenbreite. Manche Builds bieten Optionen zum Wechseln. Die genauen Regeln einzelner Style Guides sind feinteilig - lass den Formatter laufen, lies das Ergebnis und friere die Konfiguration ein.

Versteht der Formatter modernes Java?

Hängt von der Parser-Version ab. Records, Sealed Classes, Switch Expressions, Text Blocks und Pattern Matching sind neuere Erweiterungen; ältere Parser kennen sie eventuell nicht. Probier ein Snippet - wenn es sauber formatiert wird, passt es; wirft es einen Fehler, schau dir die Parser-Version an.

Korrigiert er Imports oder ungenutzte Variablen?

Nein. Formatierung ändert nur Whitespace und Klammerplatzierung. Statische Analyse (Imports organisieren, Ungenutztes entfernen) braucht eine echte IDE oder ein Tool wie google-java-format mit deaktiviertem --skip-removing-unused-imports.

Wird mein Quellcode hochgeladen?

Nein. Die Formatierung läuft in deinem Browser über einen JS-basierten Java-Parser. Code wird nicht übertragen. Vermeide das Einfügen von firmeneigenem Code, wenn deine Sicherheitsrichtlinie jegliche Web-Tool-Exposition verbietet.

Erzeugt der Formatter dasselbe Ergebnis wie IntelliJ oder Eclipse?

Vermutlich nicht exakt. Jede IDE hat ihren eigenen Formatter mit Tausenden von Optionen. Nutze diesen hier für Ad-hoc-Formatierung; für Team-Konsistenz setz ein CI-erzwungenes Tool wie google-java-format oder Spotless im Build ein.

Kann er Java minifizieren?

Java ist eine kompilierte Sprache - Minifizierung greift nicht so wie bei JS. Class-File-Optimierung erledigen Compiler und ProGuard zur Build-Zeit. Diese Seite ist nur für Quellcode-Formatierung.

Warum hat mein Code zusätzliche Leerzeilen bekommen?

Viele Style Guides verlangen eine Leerzeile zwischen Klassenmitgliedern oder zwischen Methoden. Der Formatter fügt sie ein, um konform zu sein. Wenn du kompakten Code bevorzugst, überschreibe die entsprechenden Stiloptionen.