Java Best Practices - IO, HTTP, Formate, Security und Concurrency

Projekt: Java_Enterprise_Wissenspaket_Aydin_Polat_GESAMT_PROMPTS_INDEX_OK Stand: 2026-07-07 09:51 Umfang: 163 konkrete Best-Practice-Einträge mit deutschem Titel, englischem Fachbegriff, Priorität, Begründung, Fehlerbild, Ausgangspunkt-Code, Ziel-Code und Enterprise-Einordnung.

Planungs- und Weiterarbeitsnotizen sind bewusst nicht Teil des Fachinhalts. Die Codeblöcke sind normale Markdown-Codeblöcke mit konkretem Java-Code.

IO und klassische Streams13 Einträge

Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage.

BP-001 - Ressourcen bei Rechnungsimport zuverlässig schließen

Englischer technischer Begriff
Try-with-resources
Priorität
7/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Rechnungsimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Streams, Reader oder WatchServices werden nicht zuverlässig geschlossen; Handles bleiben offen und blockieren Deployments oder Batchläufe.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class Rechnungsimport001Bad {
    String firstLine(Path file) throws Exception {
        BufferedReader reader = Files.newBufferedReader(file);
        return reader.readLine(); // Reader bleibt bei Fehlern offen
    }
}
Ziel-Code
import java.io.BufferedReader;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;

final class Rechnungsimport001ResourceSafe {
    String firstLine(Path file) throws Exception {
        try (BufferedReader reader = Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line = reader.readLine();
            return line == null ? "" : line;
        }
    }
}
Enterprise-Einordnung
Für Rechnungsimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-002 - Gepufferte Verarbeitung für Partner-Feed

Englischer technischer Begriff
Buffered I/O
Priorität
7/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Partner-Feed schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Byteweise I/O erzeugt unnötig viele Systemaufrufe und schlechte Latenz.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class PartnerFeed002Bad {
    long sum(Path file) throws Exception {
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int b;
            while ((b = in.read()) != -1) total += b;
        }
        return total;
    }
}
Ziel-Code
import java.io.*;
import java.nio.file.*;

final class PartnerFeed002Buffered {
    long sum(Path file) throws Exception {
        byte[] buffer = new byte[32 * 1024];
        long total = 0;
        try (InputStream in = new BufferedInputStream(Files.newInputStream(file))) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                for (int i = 0; i < read; i++) total += buffer[i] & 0xff;
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Partner-Feed gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-003 - Große Dokumentenarchiv-Dateien streamen und begrenzen

Englischer technischer Begriff
Streaming I/O with Size Limit
Priorität
9/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Dokumentenarchiv schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die komplette Datei wird in den Heap geladen; unter Last entstehen OutOfMemoryError oder lange GC-Pausen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Dokumentenarchiv003Bad {
    byte[] load(Path file) throws Exception {
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Dokumentenarchiv003StreamingReader {
    long countBytes(Path file, long maxBytes) throws Exception {
        byte[] buffer = new byte[64 * 1024];
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                total += read;
                if (total > maxBytes) throw new IllegalStateException("Datei zu groß");
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Dokumentenarchiv gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-004 - Explizites Charset bei Audit-Export-Textdateien

Englischer technischer Begriff
Explicit Charset Handling
Priorität
7/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Audit-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Das Plattform-Default-Encoding wird stillschweigend verwendet; Umlaute, CSV-Trenner und Signaturen brechen zwischen Umgebungen.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class AuditExport004Bad {
    List<String> read(Path file) throws Exception {
        return Files.readAllLines(file); // Plattform-Default kann abweichen
    }
}
Ziel-Code
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class AuditExport004Utf8Reader {
    List<String> readUtf8(Path file) throws Exception {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }
}
Enterprise-Einordnung
Für Audit-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-005 - Atomar schreiben für Bankdatei

Englischer technischer Begriff
Atomic File Write
Priorität
10/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Bankdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die finale Datei wird direkt beschrieben; andere Prozesse lesen Zwischenstände oder defekte Dateien.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class Bankdatei005Bad {
    void publish(Path target, List<String> rows) throws Exception {
        Files.write(target, rows); // Leser sehen eventuell halbe Datei
    }
}
Ziel-Code
import java.io.BufferedWriter;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class Bankdatei005AtomicWriter {
    void publish(Path target, List<String> rows) throws Exception {
        Files.createDirectories(target.toAbsolutePath().getParent());
        Path tmp = Files.createTempFile(target.getParent(), target.getFileName().toString(), ".tmp");
        try (BufferedWriter writer = Files.newBufferedWriter(tmp, StandardCharsets.UTF_8)) {
            for (String row : rows) {
                writer.write(row);
                writer.newLine();
            }
        }
        Files.move(tmp, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
    }
}
Enterprise-Einordnung
Für Bankdatei gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-006 - Staging-Verzeichnis für Kundenstammdaten

Englischer technischer Begriff
Temporary Staging Area
Priorität
6/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Kundenstammdaten schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine Datei wird sofort veröffentlicht; Validierung, Hash und Aufräumen bei Fehlern fehlen.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class Kundenstammdaten006Bad {
    Path store(InputStream input, Path target) throws Exception {
        Files.copy(input, target, StandardCopyOption.REPLACE_EXISTING);
        return target;
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Kundenstammdaten006Staging {
    Path store(InputStream input, Path target) throws Exception {
        Files.createDirectories(target.getParent());
        Path staged = Files.createTempFile(target.getParent(), "stage-", ".part");
        try {
            Files.copy(input, staged, StandardCopyOption.REPLACE_EXISTING);
            Files.move(staged, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
            return target;
        } catch (Exception ex) {
            Files.deleteIfExists(staged);
            throw ex;
        }
    }
}
Enterprise-Einordnung
Für Kundenstammdaten gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-007 - Sichere Pfadauflösung für Bestellanhänge

Englischer technischer Begriff
Path Traversal Prevention
Priorität
10/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Bestellanhänge schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Benutzereingaben werden direkt als Pfad genutzt; relative Pfade, absolute Pfade oder Symlinks können außerhalb des erlaubten Bereichs landen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Bestellanhnge007Bad {
    byte[] read(String userName) throws Exception {
        Path file = Path.of("/srv/app/data/" + userName);
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.IOException;
import java.nio.file.*;

final class Bestellanhnge007PathGuard {
    private final Path root;

    Bestellanhnge007PathGuard(Path root) throws IOException {
        this.root = root.toRealPath();
    }

    byte[] readAllowed(String userName) throws IOException {
        Path candidate = root.resolve(userName).normalize();
        if (!candidate.startsWith(root)) {
            throw new SecurityException("Pfad verlässt Root: " + userName);
        }
        Path real = candidate.toRealPath(LinkOption.NOFOLLOW_LINKS);
        if (!real.startsWith(root)) {
            throw new SecurityException("Symlink verlässt Root: " + userName);
        }
        return Files.readAllBytes(real);
    }
}
Enterprise-Einordnung
Für Bestellanhänge gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-008 - Große Produktkatalog-Dateien streamen und begrenzen

Englischer technischer Begriff
Streaming I/O with Size Limit
Priorität
10/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Produktkatalog schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die komplette Datei wird in den Heap geladen; unter Last entstehen OutOfMemoryError oder lange GC-Pausen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Produktkatalog008Bad {
    byte[] load(Path file) throws Exception {
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Produktkatalog008StreamingReader {
    long countBytes(Path file, long maxBytes) throws Exception {
        byte[] buffer = new byte[64 * 1024];
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                total += read;
                if (total > maxBytes) throw new IllegalStateException("Datei zu groß");
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Produktkatalog gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-009 - Ressourcen bei Vertragsdokumente zuverlässig schließen

Englischer technischer Begriff
Try-with-resources
Priorität
6/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Vertragsdokumente schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Streams, Reader oder WatchServices werden nicht zuverlässig geschlossen; Handles bleiben offen und blockieren Deployments oder Batchläufe.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class Vertragsdokumente009Bad {
    String firstLine(Path file) throws Exception {
        BufferedReader reader = Files.newBufferedReader(file);
        return reader.readLine(); // Reader bleibt bei Fehlern offen
    }
}
Ziel-Code
import java.io.BufferedReader;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;

final class Vertragsdokumente009ResourceSafe {
    String firstLine(Path file) throws Exception {
        try (BufferedReader reader = Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line = reader.readLine();
            return line == null ? "" : line;
        }
    }
}
Enterprise-Einordnung
Für Vertragsdokumente gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-010 - Gepufferte Verarbeitung für Payment-Report

Englischer technischer Begriff
Buffered I/O
Priorität
7/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Payment-Report schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Byteweise I/O erzeugt unnötig viele Systemaufrufe und schlechte Latenz.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class PaymentReport010Bad {
    long sum(Path file) throws Exception {
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int b;
            while ((b = in.read()) != -1) total += b;
        }
        return total;
    }
}
Ziel-Code
import java.io.*;
import java.nio.file.*;

final class PaymentReport010Buffered {
    long sum(Path file) throws Exception {
        byte[] buffer = new byte[32 * 1024];
        long total = 0;
        try (InputStream in = new BufferedInputStream(Files.newInputStream(file))) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                for (int i = 0; i < read; i++) total += buffer[i] & 0xff;
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Payment-Report gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-011 - Explizites Charset bei Lagerbestand-Textdateien

Englischer technischer Begriff
Explicit Charset Handling
Priorität
7/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Lagerbestand schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Das Plattform-Default-Encoding wird stillschweigend verwendet; Umlaute, CSV-Trenner und Signaturen brechen zwischen Umgebungen.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class Lagerbestand011Bad {
    List<String> read(Path file) throws Exception {
        return Files.readAllLines(file); // Plattform-Default kann abweichen
    }
}
Ziel-Code
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class Lagerbestand011Utf8Reader {
    List<String> readUtf8(Path file) throws Exception {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }
}
Enterprise-Einordnung
Für Lagerbestand gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-012 - Atomar schreiben für Versandavis

Englischer technischer Begriff
Atomic File Write
Priorität
9/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Versandavis schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die finale Datei wird direkt beschrieben; andere Prozesse lesen Zwischenstände oder defekte Dateien.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class Versandavis012Bad {
    void publish(Path target, List<String> rows) throws Exception {
        Files.write(target, rows); // Leser sehen eventuell halbe Datei
    }
}
Ziel-Code
import java.io.BufferedWriter;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class Versandavis012AtomicWriter {
    void publish(Path target, List<String> rows) throws Exception {
        Files.createDirectories(target.toAbsolutePath().getParent());
        Path tmp = Files.createTempFile(target.getParent(), target.getFileName().toString(), ".tmp");
        try (BufferedWriter writer = Files.newBufferedWriter(tmp, StandardCharsets.UTF_8)) {
            for (String row : rows) {
                writer.write(row);
                writer.newLine();
            }
        }
        Files.move(tmp, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
    }
}
Enterprise-Einordnung
Für Versandavis gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-013 - Staging-Verzeichnis für Retourenimport

Englischer technischer Begriff
Temporary Staging Area
Priorität
7/10
Warum wichtig
Dateizugriff und Stream-Verarbeitung bilden oft die Grenze zu Fremdsystemen, Batch, Archiv und Dokumentenablage. Bei Retourenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine Datei wird sofort veröffentlicht; Validierung, Hash und Aufräumen bei Fehlern fehlen.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class Retourenimport013Bad {
    Path store(InputStream input, Path target) throws Exception {
        Files.copy(input, target, StandardCopyOption.REPLACE_EXISTING);
        return target;
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Retourenimport013Staging {
    Path store(InputStream input, Path target) throws Exception {
        Files.createDirectories(target.getParent());
        Path staged = Files.createTempFile(target.getParent(), "stage-", ".part");
        try {
            Files.copy(input, staged, StandardCopyOption.REPLACE_EXISTING);
            Files.move(staged, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
            return target;
        } catch (Exception ex) {
            Files.deleteIfExists(staged);
            throw ex;
        }
    }
}
Enterprise-Einordnung
Für Retourenimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
NIO, Path und FileChannel12 Einträge

NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers.

BP-014 - FileChannel-Transfer für Compliance-Export

Englischer technischer Begriff
NIO FileChannel Transfer
Priorität
7/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Compliance-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Große Kopien werden über byte[] oder unkontrollierte Helfer erledigt; Fortschritt, Größe und Fehlerkontext fehlen.
Ausgangspunkt-Code
import java.nio.file.*;

final class ComplianceExport014Bad {
    void copy(Path source, Path target) throws Exception {
        Files.write(target, Files.readAllBytes(source));
    }
}
Ziel-Code
import java.nio.channels.FileChannel;
import java.nio.file.*;

final class ComplianceExport014ChannelCopy {
    long copy(Path source, Path target) throws Exception {
        try (FileChannel in = FileChannel.open(source, StandardOpenOption.READ);
             FileChannel out = FileChannel.open(target, StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
            long pos = 0;
            while (pos < in.size()) {
                pos += in.transferTo(pos, in.size() - pos, out);
            }
            return pos;
        }
    }
}
Enterprise-Einordnung
Für Compliance-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-015 - Dateibaum für CRM-Synchronisation kontrolliert laufen

Englischer technischer Begriff
Files.walk with Bounds
Priorität
7/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei CRM-Synchronisation schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Files.walk wird nicht geschlossen oder läuft unbeschränkt; große Verzeichnisse werden zum Produktionsrisiko.
Ausgangspunkt-Code
import java.nio.file.*;

final class CRMSynchronisation015Bad {
    long count(Path root) throws Exception {
        return Files.walk(root).count(); // Stream wird nicht geschlossen
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.stream.Stream;

final class CRMSynchronisation015TreeScan {
    long countRegularFiles(Path root, int maxDepth) throws Exception {
        try (Stream<Path> paths = Files.walk(root, maxDepth)) {
            return paths.filter(Files::isRegularFile).count();
        }
    }
}
Enterprise-Einordnung
Für CRM-Synchronisation gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-016 - WatchService für Berechtigungsdump robust entprellen

Englischer technischer Begriff
WatchService Debouncing
Priorität
6/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Berechtigungsdump schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateisystemereignisse werden als vollständig verarbeitbare Datei interpretiert; Schreibvorgänge sind oft noch nicht abgeschlossen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Berechtigungsdump016Bad {
    void watch(Path dir) throws Exception {
        WatchService ws = FileSystems.getDefault().newWatchService();
        dir.register(ws, StandardWatchEventKinds.ENTRY_CREATE);
        WatchKey key = ws.take();
        for (WatchEvent<?> event : key.pollEvents()) System.out.println(event.context());
    }
}
Ziel-Code
import java.nio.file.*;
import java.time.Duration;
import java.util.HashSet;
import java.util.Set;

final class Berechtigungsdump016Watcher {
    Set<Path> pollCreated(Path dir, Duration quietTime) throws Exception {
        Set<Path> created = new HashSet<>();
        try (WatchService ws = FileSystems.getDefault().newWatchService()) {
            dir.register(ws, StandardWatchEventKinds.ENTRY_CREATE);
            WatchKey key = ws.poll(quietTime.toMillis(), java.util.concurrent.TimeUnit.MILLISECONDS);
            if (key != null) {
                for (WatchEvent<?> event : key.pollEvents()) created.add(dir.resolve((Path) event.context()));
                key.reset();
            }
        }
        return created;
    }
}
Enterprise-Einordnung
Für Berechtigungsdump gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-017 - Sichere Pfadauflösung für Reporting-Pipeline

Englischer technischer Begriff
Path Traversal Prevention
Priorität
10/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Reporting-Pipeline schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Benutzereingaben werden direkt als Pfad genutzt; relative Pfade, absolute Pfade oder Symlinks können außerhalb des erlaubten Bereichs landen.
Ausgangspunkt-Code
import java.nio.file.*;

final class ReportingPipeline017Bad {
    byte[] read(String userName) throws Exception {
        Path file = Path.of("/srv/app/data/" + userName);
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.IOException;
import java.nio.file.*;

final class ReportingPipeline017PathGuard {
    private final Path root;

    ReportingPipeline017PathGuard(Path root) throws IOException {
        this.root = root.toRealPath();
    }

    byte[] readAllowed(String userName) throws IOException {
        Path candidate = root.resolve(userName).normalize();
        if (!candidate.startsWith(root)) {
            throw new SecurityException("Pfad verlässt Root: " + userName);
        }
        Path real = candidate.toRealPath(LinkOption.NOFOLLOW_LINKS);
        if (!real.startsWith(root)) {
            throw new SecurityException("Symlink verlässt Root: " + userName);
        }
        return Files.readAllBytes(real);
    }
}
Enterprise-Einordnung
Für Reporting-Pipeline gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-018 - Atomar schreiben für Ticket-Anhang

Englischer technischer Begriff
Atomic File Write
Priorität
10/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Ticket-Anhang schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die finale Datei wird direkt beschrieben; andere Prozesse lesen Zwischenstände oder defekte Dateien.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class TicketAnhang018Bad {
    void publish(Path target, List<String> rows) throws Exception {
        Files.write(target, rows); // Leser sehen eventuell halbe Datei
    }
}
Ziel-Code
import java.io.BufferedWriter;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class TicketAnhang018AtomicWriter {
    void publish(Path target, List<String> rows) throws Exception {
        Files.createDirectories(target.toAbsolutePath().getParent());
        Path tmp = Files.createTempFile(target.getParent(), target.getFileName().toString(), ".tmp");
        try (BufferedWriter writer = Files.newBufferedWriter(tmp, StandardCharsets.UTF_8)) {
            for (String row : rows) {
                writer.write(row);
                writer.newLine();
            }
        }
        Files.move(tmp, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
    }
}
Enterprise-Einordnung
Für Ticket-Anhang gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-019 - FileChannel-Transfer für Preislistenimport

Englischer technischer Begriff
NIO FileChannel Transfer
Priorität
6/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Preislistenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Große Kopien werden über byte[] oder unkontrollierte Helfer erledigt; Fortschritt, Größe und Fehlerkontext fehlen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Preislistenimport019Bad {
    void copy(Path source, Path target) throws Exception {
        Files.write(target, Files.readAllBytes(source));
    }
}
Ziel-Code
import java.nio.channels.FileChannel;
import java.nio.file.*;

final class Preislistenimport019ChannelCopy {
    long copy(Path source, Path target) throws Exception {
        try (FileChannel in = FileChannel.open(source, StandardOpenOption.READ);
             FileChannel out = FileChannel.open(target, StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
            long pos = 0;
            while (pos < in.size()) {
                pos += in.transferTo(pos, in.size() - pos, out);
            }
            return pos;
        }
    }
}
Enterprise-Einordnung
Für Preislistenimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-020 - Dateibaum für Mandantenablage kontrolliert laufen

Englischer technischer Begriff
Files.walk with Bounds
Priorität
7/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Mandantenablage schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Files.walk wird nicht geschlossen oder läuft unbeschränkt; große Verzeichnisse werden zum Produktionsrisiko.
Ausgangspunkt-Code
import java.nio.file.*;

final class Mandantenablage020Bad {
    long count(Path root) throws Exception {
        return Files.walk(root).count(); // Stream wird nicht geschlossen
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.stream.Stream;

final class Mandantenablage020TreeScan {
    long countRegularFiles(Path root, int maxDepth) throws Exception {
        try (Stream<Path> paths = Files.walk(root, maxDepth)) {
            return paths.filter(Files::isRegularFile).count();
        }
    }
}
Enterprise-Einordnung
Für Mandantenablage gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-021 - Staging-Verzeichnis für Batch-Ergebnis

Englischer technischer Begriff
Temporary Staging Area
Priorität
7/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Batch-Ergebnis schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine Datei wird sofort veröffentlicht; Validierung, Hash und Aufräumen bei Fehlern fehlen.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class BatchErgebnis021Bad {
    Path store(InputStream input, Path target) throws Exception {
        Files.copy(input, target, StandardCopyOption.REPLACE_EXISTING);
        return target;
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class BatchErgebnis021Staging {
    Path store(InputStream input, Path target) throws Exception {
        Files.createDirectories(target.getParent());
        Path staged = Files.createTempFile(target.getParent(), "stage-", ".part");
        try {
            Files.copy(input, staged, StandardCopyOption.REPLACE_EXISTING);
            Files.move(staged, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
            return target;
        } catch (Exception ex) {
            Files.deleteIfExists(staged);
            throw ex;
        }
    }
}
Enterprise-Einordnung
Für Batch-Ergebnis gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-022 - WatchService für EDI-Austausch robust entprellen

Englischer technischer Begriff
WatchService Debouncing
Priorität
6/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei EDI-Austausch schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateisystemereignisse werden als vollständig verarbeitbare Datei interpretiert; Schreibvorgänge sind oft noch nicht abgeschlossen.
Ausgangspunkt-Code
import java.nio.file.*;

final class EDIAustausch022Bad {
    void watch(Path dir) throws Exception {
        WatchService ws = FileSystems.getDefault().newWatchService();
        dir.register(ws, StandardWatchEventKinds.ENTRY_CREATE);
        WatchKey key = ws.take();
        for (WatchEvent<?> event : key.pollEvents()) System.out.println(event.context());
    }
}
Ziel-Code
import java.nio.file.*;
import java.time.Duration;
import java.util.HashSet;
import java.util.Set;

final class EDIAustausch022Watcher {
    Set<Path> pollCreated(Path dir, Duration quietTime) throws Exception {
        Set<Path> created = new HashSet<>();
        try (WatchService ws = FileSystems.getDefault().newWatchService()) {
            dir.register(ws, StandardWatchEventKinds.ENTRY_CREATE);
            WatchKey key = ws.poll(quietTime.toMillis(), java.util.concurrent.TimeUnit.MILLISECONDS);
            if (key != null) {
                for (WatchEvent<?> event : key.pollEvents()) created.add(dir.resolve((Path) event.context()));
                key.reset();
            }
        }
        return created;
    }
}
Enterprise-Einordnung
Für EDI-Austausch gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-023 - Große Benachrichtigungsjob-Dateien streamen und begrenzen

Englischer technischer Begriff
Streaming I/O with Size Limit
Priorität
10/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Benachrichtigungsjob schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die komplette Datei wird in den Heap geladen; unter Last entstehen OutOfMemoryError oder lange GC-Pausen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Benachrichtigungsjob023Bad {
    byte[] load(Path file) throws Exception {
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Benachrichtigungsjob023StreamingReader {
    long countBytes(Path file, long maxBytes) throws Exception {
        byte[] buffer = new byte[64 * 1024];
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                total += read;
                if (total > maxBytes) throw new IllegalStateException("Datei zu groß");
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Benachrichtigungsjob gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-024 - Explizites Charset bei Archiv-Retention-Textdateien

Englischer technischer Begriff
Explicit Charset Handling
Priorität
7/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Archiv-Retention schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Das Plattform-Default-Encoding wird stillschweigend verwendet; Umlaute, CSV-Trenner und Signaturen brechen zwischen Umgebungen.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class ArchivRetention024Bad {
    List<String> read(Path file) throws Exception {
        return Files.readAllLines(file); // Plattform-Default kann abweichen
    }
}
Ziel-Code
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class ArchivRetention024Utf8Reader {
    List<String> readUtf8(Path file) throws Exception {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }
}
Enterprise-Einordnung
Für Archiv-Retention gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-025 - Ressourcen bei Suchindex-Import zuverlässig schließen

Englischer technischer Begriff
Try-with-resources
Priorität
6/10
Warum wichtig
NIO ist die robuste Basis für moderne Dateisystemoperationen, große Dateien, Watcher und effiziente Transfers. Bei Suchindex-Import schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Streams, Reader oder WatchServices werden nicht zuverlässig geschlossen; Handles bleiben offen und blockieren Deployments oder Batchläufe.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class SuchindexImport025Bad {
    String firstLine(Path file) throws Exception {
        BufferedReader reader = Files.newBufferedReader(file);
        return reader.readLine(); // Reader bleibt bei Fehlern offen
    }
}
Ziel-Code
import java.io.BufferedReader;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;

final class SuchindexImport025ResourceSafe {
    String firstLine(Path file) throws Exception {
        try (BufferedReader reader = Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line = reader.readLine();
            return line == null ? "" : line;
        }
    }
}
Enterprise-Einordnung
Für Suchindex-Import gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Files API und Datei-Lifecycle12 Einträge

Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden.

BP-026 - Atomar schreiben für Abrechnungsbeleg

Englischer technischer Begriff
Atomic File Write
Priorität
10/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Abrechnungsbeleg schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die finale Datei wird direkt beschrieben; andere Prozesse lesen Zwischenstände oder defekte Dateien.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class Abrechnungsbeleg026Bad {
    void publish(Path target, List<String> rows) throws Exception {
        Files.write(target, rows); // Leser sehen eventuell halbe Datei
    }
}
Ziel-Code
import java.io.BufferedWriter;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class Abrechnungsbeleg026AtomicWriter {
    void publish(Path target, List<String> rows) throws Exception {
        Files.createDirectories(target.toAbsolutePath().getParent());
        Path tmp = Files.createTempFile(target.getParent(), target.getFileName().toString(), ".tmp");
        try (BufferedWriter writer = Files.newBufferedWriter(tmp, StandardCharsets.UTF_8)) {
            for (String row : rows) {
                writer.write(row);
                writer.newLine();
            }
        }
        Files.move(tmp, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
    }
}
Enterprise-Einordnung
Für Abrechnungsbeleg gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-027 - Staging-Verzeichnis für Steuerdatei

Englischer technischer Begriff
Temporary Staging Area
Priorität
7/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Steuerdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine Datei wird sofort veröffentlicht; Validierung, Hash und Aufräumen bei Fehlern fehlen.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class Steuerdatei027Bad {
    Path store(InputStream input, Path target) throws Exception {
        Files.copy(input, target, StandardCopyOption.REPLACE_EXISTING);
        return target;
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Steuerdatei027Staging {
    Path store(InputStream input, Path target) throws Exception {
        Files.createDirectories(target.getParent());
        Path staged = Files.createTempFile(target.getParent(), "stage-", ".part");
        try {
            Files.copy(input, staged, StandardCopyOption.REPLACE_EXISTING);
            Files.move(staged, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
            return target;
        } catch (Exception ex) {
            Files.deleteIfExists(staged);
            throw ex;
        }
    }
}
Enterprise-Einordnung
Für Steuerdatei gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-028 - Dateibaum für Legacy-Migration kontrolliert laufen

Englischer technischer Begriff
Files.walk with Bounds
Priorität
6/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Legacy-Migration schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Files.walk wird nicht geschlossen oder läuft unbeschränkt; große Verzeichnisse werden zum Produktionsrisiko.
Ausgangspunkt-Code
import java.nio.file.*;

final class LegacyMigration028Bad {
    long count(Path root) throws Exception {
        return Files.walk(root).count(); // Stream wird nicht geschlossen
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.stream.Stream;

final class LegacyMigration028TreeScan {
    long countRegularFiles(Path root, int maxDepth) throws Exception {
        try (Stream<Path> paths = Files.walk(root, maxDepth)) {
            return paths.filter(Files::isRegularFile).count();
        }
    }
}
Enterprise-Einordnung
Für Legacy-Migration gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-029 - Sichere Pfadauflösung für Kubernetes-Config

Englischer technischer Begriff
Path Traversal Prevention
Priorität
10/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Kubernetes-Config schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Benutzereingaben werden direkt als Pfad genutzt; relative Pfade, absolute Pfade oder Symlinks können außerhalb des erlaubten Bereichs landen.
Ausgangspunkt-Code
import java.nio.file.*;

final class KubernetesConfig029Bad {
    byte[] read(String userName) throws Exception {
        Path file = Path.of("/srv/app/data/" + userName);
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.IOException;
import java.nio.file.*;

final class KubernetesConfig029PathGuard {
    private final Path root;

    KubernetesConfig029PathGuard(Path root) throws IOException {
        this.root = root.toRealPath();
    }

    byte[] readAllowed(String userName) throws IOException {
        Path candidate = root.resolve(userName).normalize();
        if (!candidate.startsWith(root)) {
            throw new SecurityException("Pfad verlässt Root: " + userName);
        }
        Path real = candidate.toRealPath(LinkOption.NOFOLLOW_LINKS);
        if (!real.startsWith(root)) {
            throw new SecurityException("Symlink verlässt Root: " + userName);
        }
        return Files.readAllBytes(real);
    }
}
Enterprise-Einordnung
Für Kubernetes-Config gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-030 - Große OpenShift-Secret-Export-Dateien streamen und begrenzen

Englischer technischer Begriff
Streaming I/O with Size Limit
Priorität
10/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei OpenShift-Secret-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die komplette Datei wird in den Heap geladen; unter Last entstehen OutOfMemoryError oder lange GC-Pausen.
Ausgangspunkt-Code
import java.nio.file.*;

final class OpenShiftSecretExport030Bad {
    byte[] load(Path file) throws Exception {
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class OpenShiftSecretExport030StreamingReader {
    long countBytes(Path file, long maxBytes) throws Exception {
        byte[] buffer = new byte[64 * 1024];
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                total += read;
                if (total > maxBytes) throw new IllegalStateException("Datei zu groß");
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für OpenShift-Secret-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-031 - Explizites Charset bei Fehlerprotokoll-Textdateien

Englischer technischer Begriff
Explicit Charset Handling
Priorität
6/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Fehlerprotokoll schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Das Plattform-Default-Encoding wird stillschweigend verwendet; Umlaute, CSV-Trenner und Signaturen brechen zwischen Umgebungen.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class Fehlerprotokoll031Bad {
    List<String> read(Path file) throws Exception {
        return Files.readAllLines(file); // Plattform-Default kann abweichen
    }
}
Ziel-Code
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class Fehlerprotokoll031Utf8Reader {
    List<String> readUtf8(Path file) throws Exception {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }
}
Enterprise-Einordnung
Für Fehlerprotokoll gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-032 - Ressourcen bei Mandanten-Backup zuverlässig schließen

Englischer technischer Begriff
Try-with-resources
Priorität
7/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Mandanten-Backup schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Streams, Reader oder WatchServices werden nicht zuverlässig geschlossen; Handles bleiben offen und blockieren Deployments oder Batchläufe.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class MandantenBackup032Bad {
    String firstLine(Path file) throws Exception {
        BufferedReader reader = Files.newBufferedReader(file);
        return reader.readLine(); // Reader bleibt bei Fehlern offen
    }
}
Ziel-Code
import java.io.BufferedReader;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;

final class MandantenBackup032ResourceSafe {
    String firstLine(Path file) throws Exception {
        try (BufferedReader reader = Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line = reader.readLine();
            return line == null ? "" : line;
        }
    }
}
Enterprise-Einordnung
Für Mandanten-Backup gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-033 - Gepufferte Verarbeitung für Schnittstellenprotokoll

Englischer technischer Begriff
Buffered I/O
Priorität
7/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Schnittstellenprotokoll schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Byteweise I/O erzeugt unnötig viele Systemaufrufe und schlechte Latenz.
Ausgangspunkt-Code
import java.io.*;
import java.nio.file.*;

final class Schnittstellenprotokoll033Bad {
    long sum(Path file) throws Exception {
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int b;
            while ((b = in.read()) != -1) total += b;
        }
        return total;
    }
}
Ziel-Code
import java.io.*;
import java.nio.file.*;

final class Schnittstellenprotokoll033Buffered {
    long sum(Path file) throws Exception {
        byte[] buffer = new byte[32 * 1024];
        long total = 0;
        try (InputStream in = new BufferedInputStream(Files.newInputStream(file))) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                for (int i = 0; i < read; i++) total += buffer[i] & 0xff;
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Schnittstellenprotokoll gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-034 - FileChannel-Transfer für Job-Checkpoint

Englischer technischer Begriff
NIO FileChannel Transfer
Priorität
6/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Job-Checkpoint schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Große Kopien werden über byte[] oder unkontrollierte Helfer erledigt; Fortschritt, Größe und Fehlerkontext fehlen.
Ausgangspunkt-Code
import java.nio.file.*;

final class JobCheckpoint034Bad {
    void copy(Path source, Path target) throws Exception {
        Files.write(target, Files.readAllBytes(source));
    }
}
Ziel-Code
import java.nio.channels.FileChannel;
import java.nio.file.*;

final class JobCheckpoint034ChannelCopy {
    long copy(Path source, Path target) throws Exception {
        try (FileChannel in = FileChannel.open(source, StandardOpenOption.READ);
             FileChannel out = FileChannel.open(target, StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
            long pos = 0;
            while (pos < in.size()) {
                pos += in.transferTo(pos, in.size() - pos, out);
            }
            return pos;
        }
    }
}
Enterprise-Einordnung
Für Job-Checkpoint gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-035 - Atomar schreiben für Event-Replay

Englischer technischer Begriff
Atomic File Write
Priorität
10/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Event-Replay schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die finale Datei wird direkt beschrieben; andere Prozesse lesen Zwischenstände oder defekte Dateien.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class EventReplay035Bad {
    void publish(Path target, List<String> rows) throws Exception {
        Files.write(target, rows); // Leser sehen eventuell halbe Datei
    }
}
Ziel-Code
import java.io.BufferedWriter;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class EventReplay035AtomicWriter {
    void publish(Path target, List<String> rows) throws Exception {
        Files.createDirectories(target.toAbsolutePath().getParent());
        Path tmp = Files.createTempFile(target.getParent(), target.getFileName().toString(), ".tmp");
        try (BufferedWriter writer = Files.newBufferedWriter(tmp, StandardCharsets.UTF_8)) {
            for (String row : rows) {
                writer.write(row);
                writer.newLine();
            }
        }
        Files.move(tmp, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
    }
}
Enterprise-Einordnung
Für Event-Replay gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-036 - Staging-Verzeichnis für Data-Lake-Export

Englischer technischer Begriff
Temporary Staging Area
Priorität
7/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Data-Lake-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine Datei wird sofort veröffentlicht; Validierung, Hash und Aufräumen bei Fehlern fehlen.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class DataLakeExport036Bad {
    Path store(InputStream input, Path target) throws Exception {
        Files.copy(input, target, StandardCopyOption.REPLACE_EXISTING);
        return target;
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class DataLakeExport036Staging {
    Path store(InputStream input, Path target) throws Exception {
        Files.createDirectories(target.getParent());
        Path staged = Files.createTempFile(target.getParent(), "stage-", ".part");
        try {
            Files.copy(input, staged, StandardCopyOption.REPLACE_EXISTING);
            Files.move(staged, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
            return target;
        } catch (Exception ex) {
            Files.deleteIfExists(staged);
            throw ex;
        }
    }
}
Enterprise-Einordnung
Für Data-Lake-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-037 - Dateibaum für Kassenabschluss kontrolliert laufen

Englischer technischer Begriff
Files.walk with Bounds
Priorität
6/10
Warum wichtig
Die Files API macht Dateioperationen lesbar, muss aber konsequent mit Limits, atomaren Moves und Fehlerkontext genutzt werden. Bei Kassenabschluss schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Files.walk wird nicht geschlossen oder läuft unbeschränkt; große Verzeichnisse werden zum Produktionsrisiko.
Ausgangspunkt-Code
import java.nio.file.*;

final class Kassenabschluss037Bad {
    long count(Path root) throws Exception {
        return Files.walk(root).count(); // Stream wird nicht geschlossen
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.stream.Stream;

final class Kassenabschluss037TreeScan {
    long countRegularFiles(Path root, int maxDepth) throws Exception {
        try (Stream<Path> paths = Files.walk(root, maxDepth)) {
            return paths.filter(Files::isRegularFile).count();
        }
    }
}
Enterprise-Einordnung
Für Kassenabschluss gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
HTTP, Upload und Download13 Einträge

Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen.

BP-038 - HTTP-Timeouts für Produktbild

Englischer technischer Begriff
HTTP Client Timeouts
Priorität
9/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Produktbild schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Remote Calls haben keine Grenzen; ein langsamer Partner blockiert Threads und löst Kaskadeneffekte aus.
Ausgangspunkt-Code
import java.net.URL;

final class Produktbild038Bad {
    String call(String url) throws Exception {
        return new String(new URL(url).openStream().readAllBytes());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.time.Duration;

final class Produktbild038HttpClient {
    String call(URI uri) throws Exception {
        HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(3)).build();
        HttpRequest request = HttpRequest.newBuilder(uri).timeout(Duration.ofSeconds(5)).GET().build();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        if (response.statusCode() >= 400) throw new IllegalStateException("HTTP " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für Produktbild gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-039 - HTTP-Statuscodes bei Adressexport nicht ignorieren

Englischer technischer Begriff
HTTP Status Handling
Priorität
9/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Adressexport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
404, 409 oder 500 werden wie erfolgreiche Antworten verarbeitet.
Ausgangspunkt-Code
import java.net.http.*;

final class Adressexport039Bad {
    String body(HttpResponse<String> response) {
        return response.body(); // 404/500 wird wie Erfolg behandelt
    }
}
Ziel-Code
import java.net.http.HttpResponse;

final class Adressexport039StatusMapper {
    String requireSuccess(HttpResponse<String> response) {
        int status = response.statusCode();
        if (status == 404) throw new IllegalArgumentException("Partnerdaten nicht gefunden");
        if (status < 200 || status >= 300) throw new IllegalStateException("Remote Fehler: " + status);
        return response.body();
    }
}
Enterprise-Einordnung
Für Adressexport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-040 - HTTP-Download für Lizenzbericht streamen

Englischer technischer Begriff
Streaming HTTP Download
Priorität
6/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Lizenzbericht schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Downloads werden komplett als byte[] gehalten; große Antworten belasten Heap und Latenz.
Ausgangspunkt-Code
import java.net.http.*;
import java.nio.file.*;

final class Lizenzbericht040Bad {
    void download(HttpResponse<byte[]> response, Path target) throws Exception {
        Files.write(target, response.body());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.nio.file.*;

final class Lizenzbericht040Download {
    Path downloadToFile(URI uri, Path target) throws Exception {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder(uri).GET().build();
        HttpResponse<Path> response = client.send(request, HttpResponse.BodyHandlers.ofFile(target));
        if (response.statusCode() != 200) throw new IllegalStateException("Download fehlgeschlagen: " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für Lizenzbericht gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-041 - Upload von Schulungsunterlage validieren

Englischer technischer Begriff
Upload Validation
Priorität
10/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Schulungsunterlage schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateiname, Typ, Größe und Zielpfad werden nicht begrenzt.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class Schulungsunterlage041Bad {
    void upload(InputStream in, String fileName) throws Exception {
        Files.copy(in, Path.of("/uploads", fileName));
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Schulungsunterlage041UploadGuard {
    Path upload(InputStream in, String fileName, long maxBytes) throws Exception {
        String safe = fileName.replaceAll("[^a-zA-Z0-9._-]", "_");
        if (!safe.endsWith(".csv")) throw new SecurityException("Nur CSV erlaubt");
        Path target = Path.of("/uploads").resolve(safe).normalize();
        long copied = Files.copy(in, target, StandardCopyOption.REPLACE_EXISTING);
        if (copied > maxBytes) {
            Files.deleteIfExists(target);
            throw new IllegalStateException("Upload zu groß");
        }
        return target;
    }
}
Enterprise-Einordnung
Für Schulungsunterlage gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-042 - Sichere Download-Header für Dokumentenfreigabe

Englischer technischer Begriff
Safe Download Headers
Priorität
7/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Dokumentenfreigabe schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateinamen gelangen ungefiltert in Header; Header Injection oder kaputte Sonderzeichen sind möglich.
Ausgangspunkt-Code
final class Dokumentenfreigabe042Bad {
    String header(String fileName) {
        return "attachment; filename=" + fileName;
    }
}
Ziel-Code
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

final class Dokumentenfreigabe042DownloadHeader {
    String contentDisposition(String fileName) {
        String safeName = fileName.replaceAll("[\r\n\"]", "_");
        String encoded = URLEncoder.encode(safeName, StandardCharsets.UTF_8).replace("+", "%20");
        return "attachment; filename="" + safeName + ""; filename*=UTF-8''" + encoded;
    }
}
Enterprise-Einordnung
Für Dokumentenfreigabe gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-043 - HTTP-Timeouts für Signaturdatei

Englischer technischer Begriff
HTTP Client Timeouts
Priorität
8/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Signaturdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Remote Calls haben keine Grenzen; ein langsamer Partner blockiert Threads und löst Kaskadeneffekte aus.
Ausgangspunkt-Code
import java.net.URL;

final class Signaturdatei043Bad {
    String call(String url) throws Exception {
        return new String(new URL(url).openStream().readAllBytes());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.time.Duration;

final class Signaturdatei043HttpClient {
    String call(URI uri) throws Exception {
        HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(3)).build();
        HttpRequest request = HttpRequest.newBuilder(uri).timeout(Duration.ofSeconds(5)).GET().build();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        if (response.statusCode() >= 400) throw new IllegalStateException("HTTP " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für Signaturdatei gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-044 - HTTP-Statuscodes bei PDF-Erzeugung nicht ignorieren

Englischer technischer Begriff
HTTP Status Handling
Priorität
9/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei PDF-Erzeugung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
404, 409 oder 500 werden wie erfolgreiche Antworten verarbeitet.
Ausgangspunkt-Code
import java.net.http.*;

final class PDFErzeugung044Bad {
    String body(HttpResponse<String> response) {
        return response.body(); // 404/500 wird wie Erfolg behandelt
    }
}
Ziel-Code
import java.net.http.HttpResponse;

final class PDFErzeugung044StatusMapper {
    String requireSuccess(HttpResponse<String> response) {
        int status = response.statusCode();
        if (status == 404) throw new IllegalArgumentException("Partnerdaten nicht gefunden");
        if (status < 200 || status >= 300) throw new IllegalStateException("Remote Fehler: " + status);
        return response.body();
    }
}
Enterprise-Einordnung
Für PDF-Erzeugung gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-045 - HTTP-Download für Berichtsdownload streamen

Englischer technischer Begriff
Streaming HTTP Download
Priorität
7/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Berichtsdownload schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Downloads werden komplett als byte[] gehalten; große Antworten belasten Heap und Latenz.
Ausgangspunkt-Code
import java.net.http.*;
import java.nio.file.*;

final class Berichtsdownload045Bad {
    void download(HttpResponse<byte[]> response, Path target) throws Exception {
        Files.write(target, response.body());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.nio.file.*;

final class Berichtsdownload045Download {
    Path downloadToFile(URI uri, Path target) throws Exception {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder(uri).GET().build();
        HttpResponse<Path> response = client.send(request, HttpResponse.BodyHandlers.ofFile(target));
        if (response.statusCode() != 200) throw new IllegalStateException("Download fehlgeschlagen: " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für Berichtsdownload gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-046 - Upload von REST-Adapter validieren

Englischer technischer Begriff
Upload Validation
Priorität
9/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei REST-Adapter schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateiname, Typ, Größe und Zielpfad werden nicht begrenzt.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class RESTAdapter046Bad {
    void upload(InputStream in, String fileName) throws Exception {
        Files.copy(in, Path.of("/uploads", fileName));
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class RESTAdapter046UploadGuard {
    Path upload(InputStream in, String fileName, long maxBytes) throws Exception {
        String safe = fileName.replaceAll("[^a-zA-Z0-9._-]", "_");
        if (!safe.endsWith(".csv")) throw new SecurityException("Nur CSV erlaubt");
        Path target = Path.of("/uploads").resolve(safe).normalize();
        long copied = Files.copy(in, target, StandardCopyOption.REPLACE_EXISTING);
        if (copied > maxBytes) {
            Files.deleteIfExists(target);
            throw new IllegalStateException("Upload zu groß");
        }
        return target;
    }
}
Enterprise-Einordnung
Für REST-Adapter gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-047 - Sichere Download-Header für SOAP-Migration

Englischer technischer Begriff
Safe Download Headers
Priorität
7/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei SOAP-Migration schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateinamen gelangen ungefiltert in Header; Header Injection oder kaputte Sonderzeichen sind möglich.
Ausgangspunkt-Code
final class SOAPMigration047Bad {
    String header(String fileName) {
        return "attachment; filename=" + fileName;
    }
}
Ziel-Code
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

final class SOAPMigration047DownloadHeader {
    String contentDisposition(String fileName) {
        String safeName = fileName.replaceAll("[\r\n\"]", "_");
        String encoded = URLEncoder.encode(safeName, StandardCharsets.UTF_8).replace("+", "%20");
        return "attachment; filename="" + safeName + ""; filename*=UTF-8''" + encoded;
    }
}
Enterprise-Einordnung
Für SOAP-Migration gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-048 - HTTP-Timeouts für JMS-Brücke

Englischer technischer Begriff
HTTP Client Timeouts
Priorität
9/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei JMS-Brücke schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Remote Calls haben keine Grenzen; ein langsamer Partner blockiert Threads und löst Kaskadeneffekte aus.
Ausgangspunkt-Code
import java.net.URL;

final class JMSBrcke048Bad {
    String call(String url) throws Exception {
        return new String(new URL(url).openStream().readAllBytes());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.time.Duration;

final class JMSBrcke048HttpClient {
    String call(URI uri) throws Exception {
        HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(3)).build();
        HttpRequest request = HttpRequest.newBuilder(uri).timeout(Duration.ofSeconds(5)).GET().build();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        if (response.statusCode() >= 400) throw new IllegalStateException("HTTP " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für JMS-Brücke gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-049 - HTTP-Statuscodes bei Benutzerexport nicht ignorieren

Englischer technischer Begriff
HTTP Status Handling
Priorität
8/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Benutzerexport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
404, 409 oder 500 werden wie erfolgreiche Antworten verarbeitet.
Ausgangspunkt-Code
import java.net.http.*;

final class Benutzerexport049Bad {
    String body(HttpResponse<String> response) {
        return response.body(); // 404/500 wird wie Erfolg behandelt
    }
}
Ziel-Code
import java.net.http.HttpResponse;

final class Benutzerexport049StatusMapper {
    String requireSuccess(HttpResponse<String> response) {
        int status = response.statusCode();
        if (status == 404) throw new IllegalArgumentException("Partnerdaten nicht gefunden");
        if (status < 200 || status >= 300) throw new IllegalStateException("Remote Fehler: " + status);
        return response.body();
    }
}
Enterprise-Einordnung
Für Benutzerexport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-050 - HTTP-Download für Rollenimport streamen

Englischer technischer Begriff
Streaming HTTP Download
Priorität
7/10
Warum wichtig
Remote-Aufrufe brauchen Timeouts, Statusprüfung, Streaming und klare Grenzen, damit Ausfälle nicht ins System kippen. Bei Rollenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Downloads werden komplett als byte[] gehalten; große Antworten belasten Heap und Latenz.
Ausgangspunkt-Code
import java.net.http.*;
import java.nio.file.*;

final class Rollenimport050Bad {
    void download(HttpResponse<byte[]> response, Path target) throws Exception {
        Files.write(target, response.body());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.nio.file.*;

final class Rollenimport050Download {
    Path downloadToFile(URI uri, Path target) throws Exception {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder(uri).GET().build();
        HttpResponse<Path> response = client.send(request, HttpResponse.BodyHandlers.ofFile(target));
        if (response.statusCode() != 200) throw new IllegalStateException("Download fehlgeschlagen: " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für Rollenimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Serialization, XML, JSON und CSV15 Einträge

Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden.

BP-051 - JSON für Konfigurationsimport speicherschonend lesen

Englischer technischer Begriff
Streaming JSON Parsing
Priorität
7/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Konfigurationsimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
JSON wird mit String-Suche oder Full-DOM-Verarbeitung missbraucht; große Dateien und Randfälle brechen.
Ausgangspunkt-Code
final class Konfigurationsimport051Bad {
    int countCustomers(String json) {
        return json.split("customerId").length - 1; // fragile Textsuche
    }
}
Ziel-Code
import java.io.Reader;

final class Konfigurationsimport051JsonReader {
    int countObjects(Reader reader) throws Exception {
        int objects = 0;
        int ch;
        boolean inString = false;
        while ((ch = reader.read()) != -1) {
            if (ch == '"') inString = !inString;
            if (!inString && ch == '{') objects++;
        }
        return objects;
    }
}
Enterprise-Einordnung
Für Konfigurationsimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-052 - XML für Import-Quarantäne gegen XXE härten

Englischer technischer Begriff
Secure XML Parsing
Priorität
10/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Import-Quarantäne schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
XML-Parser erlauben externe Entitäten; XXE kann lokale Dateien lesen oder Netzaufrufe erzeugen.
Ausgangspunkt-Code
import javax.xml.parsers.DocumentBuilderFactory;

final class ImportQuarantne052Bad {
    DocumentBuilderFactory factory() {
        return DocumentBuilderFactory.newInstance();
    }
}
Ziel-Code
import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;

final class ImportQuarantne052XmlFactory {
    DocumentBuilderFactory secureFactory() throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
        return factory;
    }
}
Enterprise-Einordnung
Für Import-Quarantäne gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-053 - CSV-Zeilen für Freigabe-Workflow fachlich validieren

Englischer technischer Begriff
CSV Validation
Priorität
6/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Freigabe-Workflow schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
split(",") ohne Spaltenzahl, Leerwertprüfung und fachliche Typen macht Imports instabil.
Ausgangspunkt-Code
final class FreigabeWorkflow053Bad {
    String[] parse(String line) {
        return line.split(",");
    }
}
Ziel-Code
import java.math.BigDecimal;

final class FreigabeWorkflow053CsvParser {
    Record parse(String line) {
        String[] columns = line.split(",", -1);
        if (columns.length != 3) throw new IllegalArgumentException("3 Spalten erwartet");
        if (columns[0].isBlank()) throw new IllegalArgumentException("Id fehlt");
        BigDecimal amount = new BigDecimal(columns[2].trim());
        return new Record(columns[0].trim(), columns[1].trim(), amount);
    }
    record Record(String id, String name, BigDecimal amount) {}
}
Enterprise-Einordnung
Für Freigabe-Workflow gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-054 - Java-Deserialisierung bei Cache-Aktualisierung begrenzen

Englischer technischer Begriff
Serialization Filter
Priorität
9/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Cache-Aktualisierung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ObjectInputStream akzeptiert beliebige Objektgraphen; Deserialisierung wird zur Angriffsfläche.
Ausgangspunkt-Code
import java.io.*;

final class CacheAktualisierung054Bad {
    Object read(InputStream in) throws Exception {
        return new ObjectInputStream(in).readObject();
    }
}
Ziel-Code
import java.io.*;

final class CacheAktualisierung054Deserializer {
    Object read(InputStream in) throws Exception {
        try (ObjectInputStream ois = new ObjectInputStream(in)) {
            ois.setObjectInputFilter(info -> info.depth() > 8 || info.references() > 1000
                    ? ObjectInputFilter.Status.REJECTED
                    : ObjectInputFilter.Status.UNDECIDED);
            return ois.readObject();
        }
    }
}
Enterprise-Einordnung
Für Cache-Aktualisierung gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-055 - ZIP-Import für Suchvorschläge gegen Zip Slip schützen

Englischer technischer Begriff
Zip Slip Prevention
Priorität
10/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Suchvorschläge schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ZIP-Einträge werden ohne Normalisierung extrahiert und können außerhalb des Zielverzeichnisses schreiben.
Ausgangspunkt-Code
import java.util.zip.ZipEntry;

final class Suchvorschlge055Bad {
    String targetName(ZipEntry entry) {
        return "/import/" + entry.getName();
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.zip.ZipEntry;

final class Suchvorschlge055ZipGuard {
    Path target(Path root, ZipEntry entry) {
        Path target = root.resolve(entry.getName()).normalize();
        if (!target.startsWith(root.normalize())) {
            throw new SecurityException("Zip Slip: " + entry.getName());
        }
        return target;
    }
}
Enterprise-Einordnung
Für Suchvorschläge gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-056 - JSON für Preisberechnung speicherschonend lesen

Englischer technischer Begriff
Streaming JSON Parsing
Priorität
6/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Preisberechnung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
JSON wird mit String-Suche oder Full-DOM-Verarbeitung missbraucht; große Dateien und Randfälle brechen.
Ausgangspunkt-Code
final class Preisberechnung056Bad {
    int countCustomers(String json) {
        return json.split("customerId").length - 1; // fragile Textsuche
    }
}
Ziel-Code
import java.io.Reader;

final class Preisberechnung056JsonReader {
    int countObjects(Reader reader) throws Exception {
        int objects = 0;
        int ch;
        boolean inString = false;
        while ((ch = reader.read()) != -1) {
            if (ch == '"') inString = !inString;
            if (!inString && ch == '{') objects++;
        }
        return objects;
    }
}
Enterprise-Einordnung
Für Preisberechnung gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-057 - XML für Bestandsreservierung gegen XXE härten

Englischer technischer Begriff
Secure XML Parsing
Priorität
10/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Bestandsreservierung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
XML-Parser erlauben externe Entitäten; XXE kann lokale Dateien lesen oder Netzaufrufe erzeugen.
Ausgangspunkt-Code
import javax.xml.parsers.DocumentBuilderFactory;

final class Bestandsreservierung057Bad {
    DocumentBuilderFactory factory() {
        return DocumentBuilderFactory.newInstance();
    }
}
Ziel-Code
import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;

final class Bestandsreservierung057XmlFactory {
    DocumentBuilderFactory secureFactory() throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
        return factory;
    }
}
Enterprise-Einordnung
Für Bestandsreservierung gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-058 - CSV-Zeilen für Monitoring-Export fachlich validieren

Englischer technischer Begriff
CSV Validation
Priorität
7/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Monitoring-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
split(",") ohne Spaltenzahl, Leerwertprüfung und fachliche Typen macht Imports instabil.
Ausgangspunkt-Code
final class MonitoringExport058Bad {
    String[] parse(String line) {
        return line.split(",");
    }
}
Ziel-Code
import java.math.BigDecimal;

final class MonitoringExport058CsvParser {
    Record parse(String line) {
        String[] columns = line.split(",", -1);
        if (columns.length != 3) throw new IllegalArgumentException("3 Spalten erwartet");
        if (columns[0].isBlank()) throw new IllegalArgumentException("Id fehlt");
        BigDecimal amount = new BigDecimal(columns[2].trim());
        return new Record(columns[0].trim(), columns[1].trim(), amount);
    }
    record Record(String id, String name, BigDecimal amount) {}
}
Enterprise-Einordnung
Für Monitoring-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-059 - Java-Deserialisierung bei Metrik-Sampler begrenzen

Englischer technischer Begriff
Serialization Filter
Priorität
8/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Metrik-Sampler schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ObjectInputStream akzeptiert beliebige Objektgraphen; Deserialisierung wird zur Angriffsfläche.
Ausgangspunkt-Code
import java.io.*;

final class MetrikSampler059Bad {
    Object read(InputStream in) throws Exception {
        return new ObjectInputStream(in).readObject();
    }
}
Ziel-Code
import java.io.*;

final class MetrikSampler059Deserializer {
    Object read(InputStream in) throws Exception {
        try (ObjectInputStream ois = new ObjectInputStream(in)) {
            ois.setObjectInputFilter(info -> info.depth() > 8 || info.references() > 1000
                    ? ObjectInputFilter.Status.REJECTED
                    : ObjectInputFilter.Status.UNDECIDED);
            return ois.readObject();
        }
    }
}
Enterprise-Einordnung
Für Metrik-Sampler gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-060 - ZIP-Import für SLA-Prüfung gegen Zip Slip schützen

Englischer technischer Begriff
Zip Slip Prevention
Priorität
10/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei SLA-Prüfung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ZIP-Einträge werden ohne Normalisierung extrahiert und können außerhalb des Zielverzeichnisses schreiben.
Ausgangspunkt-Code
import java.util.zip.ZipEntry;

final class SLAPrfung060Bad {
    String targetName(ZipEntry entry) {
        return "/import/" + entry.getName();
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.zip.ZipEntry;

final class SLAPrfung060ZipGuard {
    Path target(Path root, ZipEntry entry) {
        Path target = root.resolve(entry.getName()).normalize();
        if (!target.startsWith(root.normalize())) {
            throw new SecurityException("Zip Slip: " + entry.getName());
        }
        return target;
    }
}
Enterprise-Einordnung
Für SLA-Prüfung gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-061 - JSON für Partner-Download speicherschonend lesen

Englischer technischer Begriff
Streaming JSON Parsing
Priorität
7/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Partner-Download schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
JSON wird mit String-Suche oder Full-DOM-Verarbeitung missbraucht; große Dateien und Randfälle brechen.
Ausgangspunkt-Code
final class PartnerDownload061Bad {
    int countCustomers(String json) {
        return json.split("customerId").length - 1; // fragile Textsuche
    }
}
Ziel-Code
import java.io.Reader;

final class PartnerDownload061JsonReader {
    int countObjects(Reader reader) throws Exception {
        int objects = 0;
        int ch;
        boolean inString = false;
        while ((ch = reader.read()) != -1) {
            if (ch == '"') inString = !inString;
            if (!inString && ch == '{') objects++;
        }
        return objects;
    }
}
Enterprise-Einordnung
Für Partner-Download gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-062 - XML für Rechnungsimport gegen XXE härten

Englischer technischer Begriff
Secure XML Parsing
Priorität
9/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Rechnungsimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
XML-Parser erlauben externe Entitäten; XXE kann lokale Dateien lesen oder Netzaufrufe erzeugen.
Ausgangspunkt-Code
import javax.xml.parsers.DocumentBuilderFactory;

final class Rechnungsimport062Bad {
    DocumentBuilderFactory factory() {
        return DocumentBuilderFactory.newInstance();
    }
}
Ziel-Code
import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;

final class Rechnungsimport062XmlFactory {
    DocumentBuilderFactory secureFactory() throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
        return factory;
    }
}
Enterprise-Einordnung
Für Rechnungsimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-063 - CSV-Zeilen für Partner-Feed fachlich validieren

Englischer technischer Begriff
CSV Validation
Priorität
7/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Partner-Feed schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
split(",") ohne Spaltenzahl, Leerwertprüfung und fachliche Typen macht Imports instabil.
Ausgangspunkt-Code
final class PartnerFeed063Bad {
    String[] parse(String line) {
        return line.split(",");
    }
}
Ziel-Code
import java.math.BigDecimal;

final class PartnerFeed063CsvParser {
    Record parse(String line) {
        String[] columns = line.split(",", -1);
        if (columns.length != 3) throw new IllegalArgumentException("3 Spalten erwartet");
        if (columns[0].isBlank()) throw new IllegalArgumentException("Id fehlt");
        BigDecimal amount = new BigDecimal(columns[2].trim());
        return new Record(columns[0].trim(), columns[1].trim(), amount);
    }
    record Record(String id, String name, BigDecimal amount) {}
}
Enterprise-Einordnung
Für Partner-Feed gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-064 - Java-Deserialisierung bei Dokumentenarchiv begrenzen

Englischer technischer Begriff
Serialization Filter
Priorität
9/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Dokumentenarchiv schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ObjectInputStream akzeptiert beliebige Objektgraphen; Deserialisierung wird zur Angriffsfläche.
Ausgangspunkt-Code
import java.io.*;

final class Dokumentenarchiv064Bad {
    Object read(InputStream in) throws Exception {
        return new ObjectInputStream(in).readObject();
    }
}
Ziel-Code
import java.io.*;

final class Dokumentenarchiv064Deserializer {
    Object read(InputStream in) throws Exception {
        try (ObjectInputStream ois = new ObjectInputStream(in)) {
            ois.setObjectInputFilter(info -> info.depth() > 8 || info.references() > 1000
                    ? ObjectInputFilter.Status.REJECTED
                    : ObjectInputFilter.Status.UNDECIDED);
            return ois.readObject();
        }
    }
}
Enterprise-Einordnung
Für Dokumentenarchiv gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-065 - ZIP-Import für Audit-Export gegen Zip Slip schützen

Englischer technischer Begriff
Zip Slip Prevention
Priorität
9/10
Warum wichtig
Datenformate sind Integrationsgrenzen. Parser müssen sicher, speicherschonend und fachlich validiert eingesetzt werden. Bei Audit-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ZIP-Einträge werden ohne Normalisierung extrahiert und können außerhalb des Zielverzeichnisses schreiben.
Ausgangspunkt-Code
import java.util.zip.ZipEntry;

final class AuditExport065Bad {
    String targetName(ZipEntry entry) {
        return "/import/" + entry.getName();
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.zip.ZipEntry;

final class AuditExport065ZipGuard {
    Path target(Path root, ZipEntry entry) {
        Path target = root.resolve(entry.getName()).normalize();
        if (!target.startsWith(root.normalize())) {
            throw new SecurityException("Zip Slip: " + entry.getName());
        }
        return target;
    }
}
Enterprise-Einordnung
Für Audit-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Security bei Dateioperationen14 Einträge

Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden.

BP-066 - Sichere Pfadauflösung für Bankdatei

Englischer technischer Begriff
Path Traversal Prevention
Priorität
10/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Bankdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Benutzereingaben werden direkt als Pfad genutzt; relative Pfade, absolute Pfade oder Symlinks können außerhalb des erlaubten Bereichs landen.
Ausgangspunkt-Code
import java.nio.file.*;

final class Bankdatei066Bad {
    byte[] read(String userName) throws Exception {
        Path file = Path.of("/srv/app/data/" + userName);
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.IOException;
import java.nio.file.*;

final class Bankdatei066PathGuard {
    private final Path root;

    Bankdatei066PathGuard(Path root) throws IOException {
        this.root = root.toRealPath();
    }

    byte[] readAllowed(String userName) throws IOException {
        Path candidate = root.resolve(userName).normalize();
        if (!candidate.startsWith(root)) {
            throw new SecurityException("Pfad verlässt Root: " + userName);
        }
        Path real = candidate.toRealPath(LinkOption.NOFOLLOW_LINKS);
        if (!real.startsWith(root)) {
            throw new SecurityException("Symlink verlässt Root: " + userName);
        }
        return Files.readAllBytes(real);
    }
}
Enterprise-Einordnung
Für Bankdatei gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-067 - ZIP-Import für Kundenstammdaten gegen Zip Slip schützen

Englischer technischer Begriff
Zip Slip Prevention
Priorität
10/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Kundenstammdaten schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ZIP-Einträge werden ohne Normalisierung extrahiert und können außerhalb des Zielverzeichnisses schreiben.
Ausgangspunkt-Code
import java.util.zip.ZipEntry;

final class Kundenstammdaten067Bad {
    String targetName(ZipEntry entry) {
        return "/import/" + entry.getName();
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.zip.ZipEntry;

final class Kundenstammdaten067ZipGuard {
    Path target(Path root, ZipEntry entry) {
        Path target = root.resolve(entry.getName()).normalize();
        if (!target.startsWith(root.normalize())) {
            throw new SecurityException("Zip Slip: " + entry.getName());
        }
        return target;
    }
}
Enterprise-Einordnung
Für Kundenstammdaten gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-068 - Upload von Bestellanhänge validieren

Englischer technischer Begriff
Upload Validation
Priorität
9/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Bestellanhänge schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateiname, Typ, Größe und Zielpfad werden nicht begrenzt.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class Bestellanhnge068Bad {
    void upload(InputStream in, String fileName) throws Exception {
        Files.copy(in, Path.of("/uploads", fileName));
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Bestellanhnge068UploadGuard {
    Path upload(InputStream in, String fileName, long maxBytes) throws Exception {
        String safe = fileName.replaceAll("[^a-zA-Z0-9._-]", "_");
        if (!safe.endsWith(".csv")) throw new SecurityException("Nur CSV erlaubt");
        Path target = Path.of("/uploads").resolve(safe).normalize();
        long copied = Files.copy(in, target, StandardCopyOption.REPLACE_EXISTING);
        if (copied > maxBytes) {
            Files.deleteIfExists(target);
            throw new IllegalStateException("Upload zu groß");
        }
        return target;
    }
}
Enterprise-Einordnung
Für Bestellanhänge gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-069 - Sichere Download-Header für Produktkatalog

Englischer technischer Begriff
Safe Download Headers
Priorität
7/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Produktkatalog schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateinamen gelangen ungefiltert in Header; Header Injection oder kaputte Sonderzeichen sind möglich.
Ausgangspunkt-Code
final class Produktkatalog069Bad {
    String header(String fileName) {
        return "attachment; filename=" + fileName;
    }
}
Ziel-Code
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

final class Produktkatalog069DownloadHeader {
    String contentDisposition(String fileName) {
        String safeName = fileName.replaceAll("[\r\n\"]", "_");
        String encoded = URLEncoder.encode(safeName, StandardCharsets.UTF_8).replace("+", "%20");
        return "attachment; filename="" + safeName + ""; filename*=UTF-8''" + encoded;
    }
}
Enterprise-Einordnung
Für Produktkatalog gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-070 - XML für Vertragsdokumente gegen XXE härten

Englischer technischer Begriff
Secure XML Parsing
Priorität
10/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Vertragsdokumente schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
XML-Parser erlauben externe Entitäten; XXE kann lokale Dateien lesen oder Netzaufrufe erzeugen.
Ausgangspunkt-Code
import javax.xml.parsers.DocumentBuilderFactory;

final class Vertragsdokumente070Bad {
    DocumentBuilderFactory factory() {
        return DocumentBuilderFactory.newInstance();
    }
}
Ziel-Code
import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;

final class Vertragsdokumente070XmlFactory {
    DocumentBuilderFactory secureFactory() throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
        factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
        return factory;
    }
}
Enterprise-Einordnung
Für Vertragsdokumente gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-071 - Java-Deserialisierung bei Payment-Report begrenzen

Englischer technischer Begriff
Serialization Filter
Priorität
8/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Payment-Report schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ObjectInputStream akzeptiert beliebige Objektgraphen; Deserialisierung wird zur Angriffsfläche.
Ausgangspunkt-Code
import java.io.*;

final class PaymentReport071Bad {
    Object read(InputStream in) throws Exception {
        return new ObjectInputStream(in).readObject();
    }
}
Ziel-Code
import java.io.*;

final class PaymentReport071Deserializer {
    Object read(InputStream in) throws Exception {
        try (ObjectInputStream ois = new ObjectInputStream(in)) {
            ois.setObjectInputFilter(info -> info.depth() > 8 || info.references() > 1000
                    ? ObjectInputFilter.Status.REJECTED
                    : ObjectInputFilter.Status.UNDECIDED);
            return ois.readObject();
        }
    }
}
Enterprise-Einordnung
Für Payment-Report gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-072 - Staging-Verzeichnis für Lagerbestand

Englischer technischer Begriff
Temporary Staging Area
Priorität
7/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Lagerbestand schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine Datei wird sofort veröffentlicht; Validierung, Hash und Aufräumen bei Fehlern fehlen.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class Lagerbestand072Bad {
    Path store(InputStream input, Path target) throws Exception {
        Files.copy(input, target, StandardCopyOption.REPLACE_EXISTING);
        return target;
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class Lagerbestand072Staging {
    Path store(InputStream input, Path target) throws Exception {
        Files.createDirectories(target.getParent());
        Path staged = Files.createTempFile(target.getParent(), "stage-", ".part");
        try {
            Files.copy(input, staged, StandardCopyOption.REPLACE_EXISTING);
            Files.move(staged, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
            return target;
        } catch (Exception ex) {
            Files.deleteIfExists(staged);
            throw ex;
        }
    }
}
Enterprise-Einordnung
Für Lagerbestand gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-073 - Dateibaum für Versandavis kontrolliert laufen

Englischer technischer Begriff
Files.walk with Bounds
Priorität
7/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Versandavis schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Files.walk wird nicht geschlossen oder läuft unbeschränkt; große Verzeichnisse werden zum Produktionsrisiko.
Ausgangspunkt-Code
import java.nio.file.*;

final class Versandavis073Bad {
    long count(Path root) throws Exception {
        return Files.walk(root).count(); // Stream wird nicht geschlossen
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.stream.Stream;

final class Versandavis073TreeScan {
    long countRegularFiles(Path root, int maxDepth) throws Exception {
        try (Stream<Path> paths = Files.walk(root, maxDepth)) {
            return paths.filter(Files::isRegularFile).count();
        }
    }
}
Enterprise-Einordnung
Für Versandavis gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-074 - Atomar schreiben für Retourenimport

Englischer technischer Begriff
Atomic File Write
Priorität
9/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Retourenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die finale Datei wird direkt beschrieben; andere Prozesse lesen Zwischenstände oder defekte Dateien.
Ausgangspunkt-Code
import java.nio.file.*;
import java.util.List;

final class Retourenimport074Bad {
    void publish(Path target, List<String> rows) throws Exception {
        Files.write(target, rows); // Leser sehen eventuell halbe Datei
    }
}
Ziel-Code
import java.io.BufferedWriter;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.List;

final class Retourenimport074AtomicWriter {
    void publish(Path target, List<String> rows) throws Exception {
        Files.createDirectories(target.toAbsolutePath().getParent());
        Path tmp = Files.createTempFile(target.getParent(), target.getFileName().toString(), ".tmp");
        try (BufferedWriter writer = Files.newBufferedWriter(tmp, StandardCharsets.UTF_8)) {
            for (String row : rows) {
                writer.write(row);
                writer.newLine();
            }
        }
        Files.move(tmp, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
    }
}
Enterprise-Einordnung
Für Retourenimport gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-075 - Große Compliance-Export-Dateien streamen und begrenzen

Englischer technischer Begriff
Streaming I/O with Size Limit
Priorität
10/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Compliance-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Die komplette Datei wird in den Heap geladen; unter Last entstehen OutOfMemoryError oder lange GC-Pausen.
Ausgangspunkt-Code
import java.nio.file.*;

final class ComplianceExport075Bad {
    byte[] load(Path file) throws Exception {
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class ComplianceExport075StreamingReader {
    long countBytes(Path file, long maxBytes) throws Exception {
        byte[] buffer = new byte[64 * 1024];
        long total = 0;
        try (InputStream in = Files.newInputStream(file)) {
            int read;
            while ((read = in.read(buffer)) != -1) {
                total += read;
                if (total > maxBytes) throw new IllegalStateException("Datei zu groß");
            }
        }
        return total;
    }
}
Enterprise-Einordnung
Für Compliance-Export gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-076 - Sichere Pfadauflösung für CRM-Synchronisation

Englischer technischer Begriff
Path Traversal Prevention
Priorität
10/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei CRM-Synchronisation schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Benutzereingaben werden direkt als Pfad genutzt; relative Pfade, absolute Pfade oder Symlinks können außerhalb des erlaubten Bereichs landen.
Ausgangspunkt-Code
import java.nio.file.*;

final class CRMSynchronisation076Bad {
    byte[] read(String userName) throws Exception {
        Path file = Path.of("/srv/app/data/" + userName);
        return Files.readAllBytes(file);
    }
}
Ziel-Code
import java.io.IOException;
import java.nio.file.*;

final class CRMSynchronisation076PathGuard {
    private final Path root;

    CRMSynchronisation076PathGuard(Path root) throws IOException {
        this.root = root.toRealPath();
    }

    byte[] readAllowed(String userName) throws IOException {
        Path candidate = root.resolve(userName).normalize();
        if (!candidate.startsWith(root)) {
            throw new SecurityException("Pfad verlässt Root: " + userName);
        }
        Path real = candidate.toRealPath(LinkOption.NOFOLLOW_LINKS);
        if (!real.startsWith(root)) {
            throw new SecurityException("Symlink verlässt Root: " + userName);
        }
        return Files.readAllBytes(real);
    }
}
Enterprise-Einordnung
Für CRM-Synchronisation gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-077 - ZIP-Import für Berechtigungsdump gegen Zip Slip schützen

Englischer technischer Begriff
Zip Slip Prevention
Priorität
9/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Berechtigungsdump schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
ZIP-Einträge werden ohne Normalisierung extrahiert und können außerhalb des Zielverzeichnisses schreiben.
Ausgangspunkt-Code
import java.util.zip.ZipEntry;

final class Berechtigungsdump077Bad {
    String targetName(ZipEntry entry) {
        return "/import/" + entry.getName();
    }
}
Ziel-Code
import java.nio.file.*;
import java.util.zip.ZipEntry;

final class Berechtigungsdump077ZipGuard {
    Path target(Path root, ZipEntry entry) {
        Path target = root.resolve(entry.getName()).normalize();
        if (!target.startsWith(root.normalize())) {
            throw new SecurityException("Zip Slip: " + entry.getName());
        }
        return target;
    }
}
Enterprise-Einordnung
Für Berechtigungsdump gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-078 - Upload von Reporting-Pipeline validieren

Englischer technischer Begriff
Upload Validation
Priorität
10/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Reporting-Pipeline schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateiname, Typ, Größe und Zielpfad werden nicht begrenzt.
Ausgangspunkt-Code
import java.io.InputStream;
import java.nio.file.*;

final class ReportingPipeline078Bad {
    void upload(InputStream in, String fileName) throws Exception {
        Files.copy(in, Path.of("/uploads", fileName));
    }
}
Ziel-Code
import java.io.InputStream;
import java.nio.file.*;

final class ReportingPipeline078UploadGuard {
    Path upload(InputStream in, String fileName, long maxBytes) throws Exception {
        String safe = fileName.replaceAll("[^a-zA-Z0-9._-]", "_");
        if (!safe.endsWith(".csv")) throw new SecurityException("Nur CSV erlaubt");
        Path target = Path.of("/uploads").resolve(safe).normalize();
        long copied = Files.copy(in, target, StandardCopyOption.REPLACE_EXISTING);
        if (copied > maxBytes) {
            Files.deleteIfExists(target);
            throw new IllegalStateException("Upload zu groß");
        }
        return target;
    }
}
Enterprise-Einordnung
Für Reporting-Pipeline gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-079 - Sichere Download-Header für Ticket-Anhang

Englischer technischer Begriff
Safe Download Headers
Priorität
7/10
Warum wichtig
Dateioperationen sind Sicherheitsgrenzen. Pfade, Symlinks, Archive, Namen, Rechte und Inhalte müssen bewusst kontrolliert werden. Bei Ticket-Anhang schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Dateinamen gelangen ungefiltert in Header; Header Injection oder kaputte Sonderzeichen sind möglich.
Ausgangspunkt-Code
final class TicketAnhang079Bad {
    String header(String fileName) {
        return "attachment; filename=" + fileName;
    }
}
Ziel-Code
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

final class TicketAnhang079DownloadHeader {
    String contentDisposition(String fileName) {
        String safeName = fileName.replaceAll("[\r\n\"]", "_");
        String encoded = URLEncoder.encode(safeName, StandardCharsets.UTF_8).replace("+", "%20");
        return "attachment; filename="" + safeName + ""; filename*=UTF-8''" + encoded;
    }
}
Enterprise-Einordnung
Für Ticket-Anhang gehört diese Regel in die Infrastructure-/Adapter-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Concurrency Grundlagen12 Einträge

Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit.

BP-080 - Unveränderliche Snapshots für Preislistenimport

Englischer technischer Begriff
Immutable Snapshot
Priorität
8/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Preislistenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Interne Collections werden nach außen gegeben; andere Threads ändern Zustand unkontrolliert.
Ausgangspunkt-Code
import java.util.*;

final class Preislistenimport080Bad {
    private final List<String> rows = new ArrayList<>();
    List<String> rows() { return rows; }
}
Ziel-Code
import java.util.*;

final class Preislistenimport080Snapshot {
    private final List<String> rows;
    Preislistenimport080Snapshot(List<String> rows) { this.rows = List.copyOf(rows); }
    List<String> rows() { return rows; }
}
Enterprise-Einordnung
Für Preislistenimport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-081 - volatile Stop-Flag für Mandantenablage-Worker

Englischer technischer Begriff
Volatile Visibility
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Mandantenablage schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Ein Stop-Flag ist nicht sichtbar zwischen Threads; Worker laufen weiter.
Ausgangspunkt-Code
final class Mandantenablage081Bad implements Runnable {
    private boolean running = true;
    public void run() { while (running) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Ziel-Code
final class Mandantenablage081Worker implements Runnable {
    private volatile boolean running = true;
    public void run() { while (running && !Thread.currentThread().isInterrupted()) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Enterprise-Einordnung
Für Mandantenablage gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-082 - Atomic-Kennzahlen für Batch-Ergebnis

Englischer technischer Begriff
Atomic Variables
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Batch-Ergebnis schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Zähler werden mit ++ aktualisiert; unter Last gehen Inkremente verloren.
Ausgangspunkt-Code
final class BatchErgebnis082Bad {
    private int success;
    void increment() { success++; }
    int success() { return success; }
}
Ziel-Code
import java.util.concurrent.atomic.AtomicInteger;

final class BatchErgebnis082Metrics {
    private final AtomicInteger success = new AtomicInteger();
    void increment() { success.incrementAndGet(); }
    int success() { return success.get(); }
}
Enterprise-Einordnung
Für Batch-Ergebnis gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-083 - Locks bei EDI-Austausch immer im finally freigeben

Englischer technischer Begriff
Lock try/finally
Priorität
9/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei EDI-Austausch schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
unlock() steht nicht im finally; eine Exception sperrt den kritischen Abschnitt dauerhaft.
Ausgangspunkt-Code
import java.util.concurrent.locks.ReentrantLock;

final class EDIAustausch083Bad {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        riskyWrite();
        lock.unlock();
    }
    void riskyWrite() { throw new RuntimeException("boom"); }
}
Ziel-Code
import java.util.concurrent.locks.ReentrantLock;

final class EDIAustausch083Locked {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        try {
            riskyWrite();
        } finally {
            lock.unlock();
        }
    }
    void riskyWrite() { /* Fachänderung */ }
}
Enterprise-Einordnung
Für EDI-Austausch gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-084 - ReadWriteLock für leseintensive Benachrichtigungsjob-Caches

Englischer technischer Begriff
ReadWriteLock
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Benachrichtigungsjob schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Gemeinsam genutzte Maps werden ohne Synchronisation gelesen und geschrieben.
Ausgangspunkt-Code
import java.util.*;

final class Benachrichtigungsjob084Bad {
    private final Map<String, String> cache = new HashMap<>();
    String get(String key) { return cache.get(key); }
}
Ziel-Code
import java.util.*;
import java.util.concurrent.locks.*;

final class Benachrichtigungsjob084Cache {
    private final Map<String, String> cache = new HashMap<>();
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    String get(String key) {
        lock.readLock().lock();
        try { return cache.get(key); } finally { lock.readLock().unlock(); }
    }
    void put(String key, String value) {
        lock.writeLock().lock();
        try { cache.put(key, value); } finally { lock.writeLock().unlock(); }
    }
}
Enterprise-Einordnung
Für Benachrichtigungsjob gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-085 - BlockingQueue für Archiv-Retention-Worker

Englischer technischer Begriff
Producer Consumer Queue
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Archiv-Retention schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine ArrayList wird als Queue missbraucht; remove(0), Race Conditions und busy waiting folgen.
Ausgangspunkt-Code
import java.util.*;

final class ArchivRetention085Bad {
    private final List<String> jobs = new ArrayList<>();
    void add(String job) { jobs.add(job); }
    String take() { return jobs.remove(0); }
}
Ziel-Code
import java.util.concurrent.*;

final class ArchivRetention085QueueWorker {
    private final BlockingQueue<String> jobs = new ArrayBlockingQueue<>(100);
    boolean submit(String job) { return jobs.offer(job); }
    String take() throws InterruptedException { return jobs.take(); }
}
Enterprise-Einordnung
Für Archiv-Retention gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-086 - Semaphore-Backpressure für Suchindex-Import

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Suchindex-Import schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class SuchindexImport086Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class SuchindexImport086Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Suchindex-Import gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-087 - Poison Pill zum Stoppen von Abrechnungsbeleg-Workern

Englischer technischer Begriff
Poison Pill
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Abrechnungsbeleg schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Worker werden hart gestoppt oder per Interrupt ohne Protokoll beendet.
Ausgangspunkt-Code
final class Abrechnungsbeleg087Bad {
    void stop(Thread worker) {
        worker.stop();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Abrechnungsbeleg087PoisonPill {
    private static final String STOP = "__STOP__";
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void stop() throws InterruptedException { queue.put(STOP); }
    void runLoop() throws InterruptedException {
        while (true) {
            String item = queue.take();
            if (STOP.equals(item)) break;
            process(item);
        }
    }
    void process(String item) { }
}
Enterprise-Einordnung
Für Abrechnungsbeleg gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-088 - Queue-Überlauf bei Steuerdatei bewusst ablehnen

Englischer technischer Begriff
Bounded Queue Rejection
Priorität
6/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Steuerdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine unbounded Queue sammelt unbegrenzt Jobs und verschiebt Fehler in den Speicher.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Steuerdatei088Bad {
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void submit(String job) throws InterruptedException { queue.put(job); }
}
Ziel-Code
import java.util.concurrent.*;

final class Steuerdatei088BoundedQueue {
    private final BlockingQueue<String> queue = new ArrayBlockingQueue<>(500);
    boolean submit(String job) {
        return queue.offer(job); // false ist bewusstes Backpressure-Signal
    }
}
Enterprise-Einordnung
Für Steuerdatei gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-089 - Nebenläufige Legacy-Migration-Tests mit Latches starten

Englischer technischer Begriff
CountDownLatch Concurrent Test
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Legacy-Migration schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Sleep-basierte Tests sind zufällig und prüfen Race Conditions nicht deterministisch.
Ausgangspunkt-Code
final class LegacyMigration089BadTest {
    void testRace() throws Exception {
        new Thread(() -> serviceCall()).start();
        Thread.sleep(100);
    }
    void serviceCall() { }
}
Ziel-Code
import java.util.concurrent.*;

final class LegacyMigration089LatchTest {
    void testTwoThreadsStartTogether() throws Exception {
        CountDownLatch start = new CountDownLatch(1);
        ExecutorService pool = Executors.newFixedThreadPool(2);
        Future<?> a = pool.submit(() -> awaitAndCall(start));
        Future<?> b = pool.submit(() -> awaitAndCall(start));
        start.countDown();
        a.get(1, TimeUnit.SECONDS);
        b.get(1, TimeUnit.SECONDS);
        pool.shutdownNow();
    }
    void awaitAndCall(CountDownLatch start) { try { start.await(); serviceCall(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }
    void serviceCall() { }
}
Enterprise-Einordnung
Für Legacy-Migration gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-090 - Concurrent Tests für Kubernetes-Config mit Timeout absichern

Englischer technischer Begriff
Timeout-based Concurrent Test
Priorität
9/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei Kubernetes-Config schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Tests warten unbegrenzt auf Future-Ergebnisse und blockieren die Pipeline.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class KubernetesConfig090BadTest {
    void waitsForever(Future<String> future) throws Exception {
        future.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class KubernetesConfig090TimeoutTest {
    String waitsWithLimit(Future<String> future) throws Exception {
        return future.get(2, TimeUnit.SECONDS);
    }
}
Enterprise-Einordnung
Für Kubernetes-Config gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-091 - Unveränderliche Snapshots für OpenShift-Secret-Export

Englischer technischer Begriff
Immutable Snapshot
Priorität
7/10
Warum wichtig
Nebenläufigkeit braucht klare Ownership, unveränderliche Daten, saubere Stop-Signale und kontrollierte Sichtbarkeit. Bei OpenShift-Secret-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Interne Collections werden nach außen gegeben; andere Threads ändern Zustand unkontrolliert.
Ausgangspunkt-Code
import java.util.*;

final class OpenShiftSecretExport091Bad {
    private final List<String> rows = new ArrayList<>();
    List<String> rows() { return rows; }
}
Ziel-Code
import java.util.*;

final class OpenShiftSecretExport091Snapshot {
    private final List<String> rows;
    OpenShiftSecretExport091Snapshot(List<String> rows) { this.rows = List.copyOf(rows); }
    List<String> rows() { return rows; }
}
Enterprise-Einordnung
Für OpenShift-Secret-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
ExecutorService und Thread Pools12 Einträge

Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme.

BP-092 - ExecutorService bei Fehlerprotokoll geordnet beenden

Englischer technischer Begriff
Graceful Executor Shutdown
Priorität
8/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Fehlerprotokoll schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Pools werden gestartet, aber nie sauber beendet; Tests, Deployments und Jobs hängen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Fehlerprotokoll092Bad {
    ExecutorService start() {
        return Executors.newFixedThreadPool(8); // kein Shutdown-Pfad
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class Fehlerprotokoll092ExecutorLifecycle {
    void shutdown(ExecutorService executor, Duration timeout) throws InterruptedException {
        executor.shutdown();
        if (!executor.awaitTermination(timeout.toMillis(), TimeUnit.MILLISECONDS)) {
            executor.shutdownNow();
        }
    }
}
Enterprise-Einordnung
Für Fehlerprotokoll gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-093 - Bounded Executor für Mandanten-Backup

Englischer technischer Begriff
Bounded Executor / Bulkhead
Priorität
9/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Mandanten-Backup schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Unbegrenzte Queues oder Cached Pools verstecken Überlast, bis Speicher oder Downstream ausfallen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class MandantenBackup093Bad {
    ExecutorService pool() {
        return Executors.newCachedThreadPool();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class MandantenBackup093BoundedExecutor {
    ExecutorService pool() {
        return new ThreadPoolExecutor(4, 8, 30, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(200),
                new ThreadPoolExecutor.CallerRunsPolicy());
    }
}
Enterprise-Einordnung
Für Mandanten-Backup gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-094 - Schnelle Ergebnisse bei Schnittstellenprotokoll mit CompletionService holen

Englischer technischer Begriff
ExecutorCompletionService
Priorität
6/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Schnittstellenprotokoll schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Futures werden seriell oder erst am Ende ausgewertet; schnelle Ergebnisse bleiben ungenutzt.
Ausgangspunkt-Code
import java.util.List;
import java.util.concurrent.*;

final class Schnittstellenprotokoll094Bad {
    void waitAll(ExecutorService pool, List<Callable<String>> tasks) throws Exception {
        for (Future<String> f : pool.invokeAll(tasks)) f.get();
    }
}
Ziel-Code
import java.util.List;
import java.util.concurrent.*;

final class Schnittstellenprotokoll094Completion {
    String firstFinished(ExecutorService pool, List<Callable<String>> tasks) throws Exception {
        CompletionService<String> service = new ExecutorCompletionService<>(pool);
        for (Callable<String> task : tasks) service.submit(task);
        return service.take().get();
    }
}
Enterprise-Einordnung
Für Schnittstellenprotokoll gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-095 - Scheduler für Job-Checkpoint ohne Timer-Fallen

Englischer technischer Begriff
ScheduledExecutorService
Priorität
7/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Job-Checkpoint schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Timer oder fixe sleeps ersetzen kontrollierte Scheduler; Fehler stoppen Jobs unbemerkt.
Ausgangspunkt-Code
import java.util.Timer;

final class JobCheckpoint095Bad {
    void schedule(Runnable job) {
        new Timer().schedule(new java.util.TimerTask() { public void run() { job.run(); } }, 1000, 1000);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class JobCheckpoint095Scheduler {
    ScheduledExecutorService schedule(Runnable job) {
        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
        scheduler.scheduleWithFixedDelay(job, 1, 5, TimeUnit.SECONDS);
        return scheduler;
    }
}
Enterprise-Einordnung
Für Job-Checkpoint gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-096 - Semaphore-Backpressure für Event-Replay

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Event-Replay schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class EventReplay096Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class EventReplay096Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Event-Replay gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-097 - Queue-Überlauf bei Data-Lake-Export bewusst ablehnen

Englischer technischer Begriff
Bounded Queue Rejection
Priorität
6/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Data-Lake-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine unbounded Queue sammelt unbegrenzt Jobs und verschiebt Fehler in den Speicher.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class DataLakeExport097Bad {
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void submit(String job) throws InterruptedException { queue.put(job); }
}
Ziel-Code
import java.util.concurrent.*;

final class DataLakeExport097BoundedQueue {
    private final BlockingQueue<String> queue = new ArrayBlockingQueue<>(500);
    boolean submit(String job) {
        return queue.offer(job); // false ist bewusstes Backpressure-Signal
    }
}
Enterprise-Einordnung
Für Data-Lake-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-098 - ExecutorService bei Kassenabschluss geordnet beenden

Englischer technischer Begriff
Graceful Executor Shutdown
Priorität
8/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Kassenabschluss schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Pools werden gestartet, aber nie sauber beendet; Tests, Deployments und Jobs hängen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Kassenabschluss098Bad {
    ExecutorService start() {
        return Executors.newFixedThreadPool(8); // kein Shutdown-Pfad
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class Kassenabschluss098ExecutorLifecycle {
    void shutdown(ExecutorService executor, Duration timeout) throws InterruptedException {
        executor.shutdown();
        if (!executor.awaitTermination(timeout.toMillis(), TimeUnit.MILLISECONDS)) {
            executor.shutdownNow();
        }
    }
}
Enterprise-Einordnung
Für Kassenabschluss gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-099 - Bounded Executor für Produktbild

Englischer technischer Begriff
Bounded Executor / Bulkhead
Priorität
9/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Produktbild schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Unbegrenzte Queues oder Cached Pools verstecken Überlast, bis Speicher oder Downstream ausfallen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Produktbild099Bad {
    ExecutorService pool() {
        return Executors.newCachedThreadPool();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Produktbild099BoundedExecutor {
    ExecutorService pool() {
        return new ThreadPoolExecutor(4, 8, 30, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(200),
                new ThreadPoolExecutor.CallerRunsPolicy());
    }
}
Enterprise-Einordnung
Für Produktbild gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-100 - Schnelle Ergebnisse bei Adressexport mit CompletionService holen

Englischer technischer Begriff
ExecutorCompletionService
Priorität
6/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Adressexport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Futures werden seriell oder erst am Ende ausgewertet; schnelle Ergebnisse bleiben ungenutzt.
Ausgangspunkt-Code
import java.util.List;
import java.util.concurrent.*;

final class Adressexport100Bad {
    void waitAll(ExecutorService pool, List<Callable<String>> tasks) throws Exception {
        for (Future<String> f : pool.invokeAll(tasks)) f.get();
    }
}
Ziel-Code
import java.util.List;
import java.util.concurrent.*;

final class Adressexport100Completion {
    String firstFinished(ExecutorService pool, List<Callable<String>> tasks) throws Exception {
        CompletionService<String> service = new ExecutorCompletionService<>(pool);
        for (Callable<String> task : tasks) service.submit(task);
        return service.take().get();
    }
}
Enterprise-Einordnung
Für Adressexport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-101 - Scheduler für Lizenzbericht ohne Timer-Fallen

Englischer technischer Begriff
ScheduledExecutorService
Priorität
7/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Lizenzbericht schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Timer oder fixe sleeps ersetzen kontrollierte Scheduler; Fehler stoppen Jobs unbemerkt.
Ausgangspunkt-Code
import java.util.Timer;

final class Lizenzbericht101Bad {
    void schedule(Runnable job) {
        new Timer().schedule(new java.util.TimerTask() { public void run() { job.run(); } }, 1000, 1000);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Lizenzbericht101Scheduler {
    ScheduledExecutorService schedule(Runnable job) {
        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
        scheduler.scheduleWithFixedDelay(job, 1, 5, TimeUnit.SECONDS);
        return scheduler;
    }
}
Enterprise-Einordnung
Für Lizenzbericht gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-102 - Semaphore-Backpressure für Schulungsunterlage

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Schulungsunterlage schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Schulungsunterlage102Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Schulungsunterlage102Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Schulungsunterlage gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-103 - Queue-Überlauf bei Dokumentenfreigabe bewusst ablehnen

Englischer technischer Begriff
Bounded Queue Rejection
Priorität
6/10
Warum wichtig
Thread Pools sind Kapazitätsgrenzen. Ohne Backpressure, Shutdown und Metriken entstehen schleichende Produktionsprobleme. Bei Dokumentenfreigabe schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine unbounded Queue sammelt unbegrenzt Jobs und verschiebt Fehler in den Speicher.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Dokumentenfreigabe103Bad {
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void submit(String job) throws InterruptedException { queue.put(job); }
}
Ziel-Code
import java.util.concurrent.*;

final class Dokumentenfreigabe103BoundedQueue {
    private final BlockingQueue<String> queue = new ArrayBlockingQueue<>(500);
    boolean submit(String job) {
        return queue.offer(job); // false ist bewusstes Backpressure-Signal
    }
}
Enterprise-Einordnung
Für Dokumentenfreigabe gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
CompletableFuture und asynchrone Pipelines12 Einträge

Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln.

BP-104 - CompletableFuture-Timeouts für Signaturdatei

Englischer technischer Begriff
CompletableFuture Timeout
Priorität
8/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Signaturdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
get() ohne Timeout blockiert unbegrenzt und macht den asynchronen Vorteil zunichte.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Signaturdatei104Bad {
    String load(CompletableFuture<String> future) throws Exception {
        return future.get();
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class Signaturdatei104FutureTimeout {
    CompletableFuture<String> withTimeout(CompletableFuture<String> source, Duration timeout) {
        return source.orTimeout(timeout.toMillis(), TimeUnit.MILLISECONDS)
                .exceptionally(ex -> "fallback");
    }
}
Enterprise-Einordnung
Für Signaturdatei gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-105 - CompletableFuture-Ergebnisse für PDF-Erzeugung kombinieren

Englischer technischer Begriff
CompletableFuture Combination
Priorität
7/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei PDF-Erzeugung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Futures werden mit get() zusammengeführt; dadurch entstehen Blockaden statt asynchroner Komposition.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class PDFErzeugung105Bad {
    String combine(CompletableFuture<String> a, CompletableFuture<String> b) throws Exception {
        return a.get() + b.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class PDFErzeugung105FutureCombine {
    CompletableFuture<String> combine(CompletableFuture<String> customer, CompletableFuture<String> order) {
        return customer.thenCombine(order, (c, o) -> c + ":" + o);
    }
}
Enterprise-Einordnung
Für PDF-Erzeugung gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-106 - Fehler in CompletableFuture-Pipelines für Berichtsdownload behandeln

Englischer technischer Begriff
CompletableFuture Error Handling
Priorität
6/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Berichtsdownload schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Fehlerpfade fehlen; eine einzelne Exception zerstört die ganze Pipeline ohne fachlichen Ersatzwert.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Berichtsdownload106Bad {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Berichtsdownload106FutureErrors {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase)
                .handle((value, error) -> error == null ? value : "ERSATZWERT");
    }
}
Enterprise-Einordnung
Für Berichtsdownload gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-107 - Bounded Executor für REST-Adapter

Englischer technischer Begriff
Bounded Executor / Bulkhead
Priorität
9/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei REST-Adapter schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Unbegrenzte Queues oder Cached Pools verstecken Überlast, bis Speicher oder Downstream ausfallen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class RESTAdapter107Bad {
    ExecutorService pool() {
        return Executors.newCachedThreadPool();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class RESTAdapter107BoundedExecutor {
    ExecutorService pool() {
        return new ThreadPoolExecutor(4, 8, 30, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(200),
                new ThreadPoolExecutor.CallerRunsPolicy());
    }
}
Enterprise-Einordnung
Für REST-Adapter gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-108 - Semaphore-Backpressure für SOAP-Migration

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei SOAP-Migration schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class SOAPMigration108Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class SOAPMigration108Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für SOAP-Migration gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-109 - CompletableFuture-Timeouts für JMS-Brücke

Englischer technischer Begriff
CompletableFuture Timeout
Priorität
7/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei JMS-Brücke schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
get() ohne Timeout blockiert unbegrenzt und macht den asynchronen Vorteil zunichte.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class JMSBrcke109Bad {
    String load(CompletableFuture<String> future) throws Exception {
        return future.get();
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class JMSBrcke109FutureTimeout {
    CompletableFuture<String> withTimeout(CompletableFuture<String> source, Duration timeout) {
        return source.orTimeout(timeout.toMillis(), TimeUnit.MILLISECONDS)
                .exceptionally(ex -> "fallback");
    }
}
Enterprise-Einordnung
Für JMS-Brücke gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-110 - CompletableFuture-Ergebnisse für Benutzerexport kombinieren

Englischer technischer Begriff
CompletableFuture Combination
Priorität
7/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Benutzerexport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Futures werden mit get() zusammengeführt; dadurch entstehen Blockaden statt asynchroner Komposition.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Benutzerexport110Bad {
    String combine(CompletableFuture<String> a, CompletableFuture<String> b) throws Exception {
        return a.get() + b.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Benutzerexport110FutureCombine {
    CompletableFuture<String> combine(CompletableFuture<String> customer, CompletableFuture<String> order) {
        return customer.thenCombine(order, (c, o) -> c + ":" + o);
    }
}
Enterprise-Einordnung
Für Benutzerexport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-111 - Fehler in CompletableFuture-Pipelines für Rollenimport behandeln

Englischer technischer Begriff
CompletableFuture Error Handling
Priorität
7/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Rollenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Fehlerpfade fehlen; eine einzelne Exception zerstört die ganze Pipeline ohne fachlichen Ersatzwert.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Rollenimport111Bad {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Rollenimport111FutureErrors {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase)
                .handle((value, error) -> error == null ? value : "ERSATZWERT");
    }
}
Enterprise-Einordnung
Für Rollenimport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-112 - Schnelle Ergebnisse bei Konfigurationsimport mit CompletionService holen

Englischer technischer Begriff
ExecutorCompletionService
Priorität
6/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Konfigurationsimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Futures werden seriell oder erst am Ende ausgewertet; schnelle Ergebnisse bleiben ungenutzt.
Ausgangspunkt-Code
import java.util.List;
import java.util.concurrent.*;

final class Konfigurationsimport112Bad {
    void waitAll(ExecutorService pool, List<Callable<String>> tasks) throws Exception {
        for (Future<String> f : pool.invokeAll(tasks)) f.get();
    }
}
Ziel-Code
import java.util.List;
import java.util.concurrent.*;

final class Konfigurationsimport112Completion {
    String firstFinished(ExecutorService pool, List<Callable<String>> tasks) throws Exception {
        CompletionService<String> service = new ExecutorCompletionService<>(pool);
        for (Callable<String> task : tasks) service.submit(task);
        return service.take().get();
    }
}
Enterprise-Einordnung
Für Konfigurationsimport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-113 - CompletableFuture-Timeouts für Import-Quarantäne

Englischer technischer Begriff
CompletableFuture Timeout
Priorität
8/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Import-Quarantäne schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
get() ohne Timeout blockiert unbegrenzt und macht den asynchronen Vorteil zunichte.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class ImportQuarantne113Bad {
    String load(CompletableFuture<String> future) throws Exception {
        return future.get();
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class ImportQuarantne113FutureTimeout {
    CompletableFuture<String> withTimeout(CompletableFuture<String> source, Duration timeout) {
        return source.orTimeout(timeout.toMillis(), TimeUnit.MILLISECONDS)
                .exceptionally(ex -> "fallback");
    }
}
Enterprise-Einordnung
Für Import-Quarantäne gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-114 - CompletableFuture-Ergebnisse für Freigabe-Workflow kombinieren

Englischer technischer Begriff
CompletableFuture Combination
Priorität
7/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Freigabe-Workflow schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Futures werden mit get() zusammengeführt; dadurch entstehen Blockaden statt asynchroner Komposition.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class FreigabeWorkflow114Bad {
    String combine(CompletableFuture<String> a, CompletableFuture<String> b) throws Exception {
        return a.get() + b.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class FreigabeWorkflow114FutureCombine {
    CompletableFuture<String> combine(CompletableFuture<String> customer, CompletableFuture<String> order) {
        return customer.thenCombine(order, (c, o) -> c + ":" + o);
    }
}
Enterprise-Einordnung
Für Freigabe-Workflow gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-115 - Fehler in CompletableFuture-Pipelines für Cache-Aktualisierung behandeln

Englischer technischer Begriff
CompletableFuture Error Handling
Priorität
6/10
Warum wichtig
Asynchrone Pipelines müssen Fehler, Timeouts, Executor-Wahl und Kombinationslogik explizit behandeln. Bei Cache-Aktualisierung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Fehlerpfade fehlen; eine einzelne Exception zerstört die ganze Pipeline ohne fachlichen Ersatzwert.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class CacheAktualisierung115Bad {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class CacheAktualisierung115FutureErrors {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase)
                .handle((value, error) -> error == null ? value : "ERSATZWERT");
    }
}
Enterprise-Einordnung
Für Cache-Aktualisierung gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Virtual Threads12 Einträge

Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage.

BP-116 - Virtual Threads für blockierende Suchvorschläge-Workloads nutzen

Englischer technischer Begriff
Virtual Threads
Priorität
7/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Suchvorschläge schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Virtual Threads werden als Ersatz für Kapazitätsplanung missverstanden.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Suchvorschlge116Bad {
    ExecutorService pool() {
        return Executors.newFixedThreadPool(200);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Suchvorschlge116VirtualThreads {
    ExecutorService requestExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}
Enterprise-Einordnung
Für Suchvorschläge gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-117 - Virtual Threads bei Preisberechnung mit Bulkhead begrenzen

Englischer technischer Begriff
Virtual Thread Bulkhead
Priorität
9/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Preisberechnung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Jede Aufgabe wird gestartet, obwohl Datenbank, HTTP-Partner oder Storage nur begrenzt parallel arbeiten können.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Preisberechnung117Bad {
    void submit(ExecutorService executor, Runnable task) {
        executor.submit(task); // keine Grenze für Downstream
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Preisberechnung117VirtualBulkhead {
    private final Semaphore permits = new Semaphore(50);

    void submit(ExecutorService executor, Runnable task) {
        executor.submit(() -> {
            if (!permits.tryAcquire()) throw new RejectedExecutionException("Bulkhead voll");
            try { task.run(); } finally { permits.release(); }
        });
    }
}
Enterprise-Einordnung
Für Preisberechnung gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-118 - HTTP-Timeouts für Bestandsreservierung

Englischer technischer Begriff
HTTP Client Timeouts
Priorität
8/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Bestandsreservierung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Remote Calls haben keine Grenzen; ein langsamer Partner blockiert Threads und löst Kaskadeneffekte aus.
Ausgangspunkt-Code
import java.net.URL;

final class Bestandsreservierung118Bad {
    String call(String url) throws Exception {
        return new String(new URL(url).openStream().readAllBytes());
    }
}
Ziel-Code
import java.net.URI;
import java.net.http.*;
import java.time.Duration;

final class Bestandsreservierung118HttpClient {
    String call(URI uri) throws Exception {
        HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(3)).build();
        HttpRequest request = HttpRequest.newBuilder(uri).timeout(Duration.ofSeconds(5)).GET().build();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        if (response.statusCode() >= 400) throw new IllegalStateException("HTTP " + response.statusCode());
        return response.body();
    }
}
Enterprise-Einordnung
Für Bestandsreservierung gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-119 - Semaphore-Backpressure für Monitoring-Export

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Monitoring-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class MonitoringExport119Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class MonitoringExport119Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Monitoring-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-120 - BlockingQueue für Metrik-Sampler-Worker

Englischer technischer Begriff
Producer Consumer Queue
Priorität
8/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Metrik-Sampler schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine ArrayList wird als Queue missbraucht; remove(0), Race Conditions und busy waiting folgen.
Ausgangspunkt-Code
import java.util.*;

final class MetrikSampler120Bad {
    private final List<String> jobs = new ArrayList<>();
    void add(String job) { jobs.add(job); }
    String take() { return jobs.remove(0); }
}
Ziel-Code
import java.util.concurrent.*;

final class MetrikSampler120QueueWorker {
    private final BlockingQueue<String> jobs = new ArrayBlockingQueue<>(100);
    boolean submit(String job) { return jobs.offer(job); }
    String take() throws InterruptedException { return jobs.take(); }
}
Enterprise-Einordnung
Für Metrik-Sampler gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-121 - Virtual Threads für blockierende SLA-Prüfung-Workloads nutzen

Englischer technischer Begriff
Virtual Threads
Priorität
6/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei SLA-Prüfung schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Virtual Threads werden als Ersatz für Kapazitätsplanung missverstanden.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class SLAPrfung121Bad {
    ExecutorService pool() {
        return Executors.newFixedThreadPool(200);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class SLAPrfung121VirtualThreads {
    ExecutorService requestExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}
Enterprise-Einordnung
Für SLA-Prüfung gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-122 - Virtual Threads bei Partner-Download mit Bulkhead begrenzen

Englischer technischer Begriff
Virtual Thread Bulkhead
Priorität
9/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Partner-Download schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Jede Aufgabe wird gestartet, obwohl Datenbank, HTTP-Partner oder Storage nur begrenzt parallel arbeiten können.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class PartnerDownload122Bad {
    void submit(ExecutorService executor, Runnable task) {
        executor.submit(task); // keine Grenze für Downstream
    }
}
Ziel-Code
import java.util.concurrent.*;

final class PartnerDownload122VirtualBulkhead {
    private final Semaphore permits = new Semaphore(50);

    void submit(ExecutorService executor, Runnable task) {
        executor.submit(() -> {
            if (!permits.tryAcquire()) throw new RejectedExecutionException("Bulkhead voll");
            try { task.run(); } finally { permits.release(); }
        });
    }
}
Enterprise-Einordnung
Für Partner-Download gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-123 - ExecutorService bei Rechnungsimport geordnet beenden

Englischer technischer Begriff
Graceful Executor Shutdown
Priorität
8/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Rechnungsimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Pools werden gestartet, aber nie sauber beendet; Tests, Deployments und Jobs hängen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Rechnungsimport123Bad {
    ExecutorService start() {
        return Executors.newFixedThreadPool(8); // kein Shutdown-Pfad
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class Rechnungsimport123ExecutorLifecycle {
    void shutdown(ExecutorService executor, Duration timeout) throws InterruptedException {
        executor.shutdown();
        if (!executor.awaitTermination(timeout.toMillis(), TimeUnit.MILLISECONDS)) {
            executor.shutdownNow();
        }
    }
}
Enterprise-Einordnung
Für Rechnungsimport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-124 - Concurrent Tests für Partner-Feed mit Timeout absichern

Englischer technischer Begriff
Timeout-based Concurrent Test
Priorität
8/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Partner-Feed schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Tests warten unbegrenzt auf Future-Ergebnisse und blockieren die Pipeline.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class PartnerFeed124BadTest {
    void waitsForever(Future<String> future) throws Exception {
        future.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class PartnerFeed124TimeoutTest {
    String waitsWithLimit(Future<String> future) throws Exception {
        return future.get(2, TimeUnit.SECONDS);
    }
}
Enterprise-Einordnung
Für Partner-Feed gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-125 - Virtual Threads für blockierende Dokumentenarchiv-Workloads nutzen

Englischer technischer Begriff
Virtual Threads
Priorität
7/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Dokumentenarchiv schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Virtual Threads werden als Ersatz für Kapazitätsplanung missverstanden.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Dokumentenarchiv125Bad {
    ExecutorService pool() {
        return Executors.newFixedThreadPool(200);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Dokumentenarchiv125VirtualThreads {
    ExecutorService requestExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}
Enterprise-Einordnung
Für Dokumentenarchiv gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-126 - Virtual Threads bei Audit-Export mit Bulkhead begrenzen

Englischer technischer Begriff
Virtual Thread Bulkhead
Priorität
9/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Audit-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Jede Aufgabe wird gestartet, obwohl Datenbank, HTTP-Partner oder Storage nur begrenzt parallel arbeiten können.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class AuditExport126Bad {
    void submit(ExecutorService executor, Runnable task) {
        executor.submit(task); // keine Grenze für Downstream
    }
}
Ziel-Code
import java.util.concurrent.*;

final class AuditExport126VirtualBulkhead {
    private final Semaphore permits = new Semaphore(50);

    void submit(ExecutorService executor, Runnable task) {
        executor.submit(() -> {
            if (!permits.tryAcquire()) throw new RejectedExecutionException("Bulkhead voll");
            try { task.run(); } finally { permits.release(); }
        });
    }
}
Enterprise-Einordnung
Für Audit-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-127 - Semaphore-Backpressure für Bankdatei

Englischer technischer Begriff
Semaphore Backpressure
Priorität
8/10
Warum wichtig
Virtual Threads vereinfachen blockierende Workloads, ersetzen aber keine Kapazitätslimits für Datenbank, HTTP oder Storage. Bei Bankdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Bankdatei127Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Bankdatei127Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Bankdatei gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Locks, Atomic und volatile12 Einträge

Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks.

BP-128 - Locks bei Kundenstammdaten immer im finally freigeben

Englischer technischer Begriff
Lock try/finally
Priorität
9/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Kundenstammdaten schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
unlock() steht nicht im finally; eine Exception sperrt den kritischen Abschnitt dauerhaft.
Ausgangspunkt-Code
import java.util.concurrent.locks.ReentrantLock;

final class Kundenstammdaten128Bad {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        riskyWrite();
        lock.unlock();
    }
    void riskyWrite() { throw new RuntimeException("boom"); }
}
Ziel-Code
import java.util.concurrent.locks.ReentrantLock;

final class Kundenstammdaten128Locked {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        try {
            riskyWrite();
        } finally {
            lock.unlock();
        }
    }
    void riskyWrite() { /* Fachänderung */ }
}
Enterprise-Einordnung
Für Kundenstammdaten gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-129 - ReadWriteLock für leseintensive Bestellanhänge-Caches

Englischer technischer Begriff
ReadWriteLock
Priorität
7/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Bestellanhänge schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Gemeinsam genutzte Maps werden ohne Synchronisation gelesen und geschrieben.
Ausgangspunkt-Code
import java.util.*;

final class Bestellanhnge129Bad {
    private final Map<String, String> cache = new HashMap<>();
    String get(String key) { return cache.get(key); }
}
Ziel-Code
import java.util.*;
import java.util.concurrent.locks.*;

final class Bestellanhnge129Cache {
    private final Map<String, String> cache = new HashMap<>();
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    String get(String key) {
        lock.readLock().lock();
        try { return cache.get(key); } finally { lock.readLock().unlock(); }
    }
    void put(String key, String value) {
        lock.writeLock().lock();
        try { cache.put(key, value); } finally { lock.writeLock().unlock(); }
    }
}
Enterprise-Einordnung
Für Bestellanhänge gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-130 - Atomic-Kennzahlen für Produktkatalog

Englischer technischer Begriff
Atomic Variables
Priorität
7/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Produktkatalog schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Zähler werden mit ++ aktualisiert; unter Last gehen Inkremente verloren.
Ausgangspunkt-Code
final class Produktkatalog130Bad {
    private int success;
    void increment() { success++; }
    int success() { return success; }
}
Ziel-Code
import java.util.concurrent.atomic.AtomicInteger;

final class Produktkatalog130Metrics {
    private final AtomicInteger success = new AtomicInteger();
    void increment() { success.incrementAndGet(); }
    int success() { return success.get(); }
}
Enterprise-Einordnung
Für Produktkatalog gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-131 - volatile Stop-Flag für Vertragsdokumente-Worker

Englischer technischer Begriff
Volatile Visibility
Priorität
7/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Vertragsdokumente schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Ein Stop-Flag ist nicht sichtbar zwischen Threads; Worker laufen weiter.
Ausgangspunkt-Code
final class Vertragsdokumente131Bad implements Runnable {
    private boolean running = true;
    public void run() { while (running) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Ziel-Code
final class Vertragsdokumente131Worker implements Runnable {
    private volatile boolean running = true;
    public void run() { while (running && !Thread.currentThread().isInterrupted()) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Enterprise-Einordnung
Für Vertragsdokumente gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-132 - Unveränderliche Snapshots für Payment-Report

Englischer technischer Begriff
Immutable Snapshot
Priorität
8/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Payment-Report schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Interne Collections werden nach außen gegeben; andere Threads ändern Zustand unkontrolliert.
Ausgangspunkt-Code
import java.util.*;

final class PaymentReport132Bad {
    private final List<String> rows = new ArrayList<>();
    List<String> rows() { return rows; }
}
Ziel-Code
import java.util.*;

final class PaymentReport132Snapshot {
    private final List<String> rows;
    PaymentReport132Snapshot(List<String> rows) { this.rows = List.copyOf(rows); }
    List<String> rows() { return rows; }
}
Enterprise-Einordnung
Für Payment-Report gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-133 - Locks bei Lagerbestand immer im finally freigeben

Englischer technischer Begriff
Lock try/finally
Priorität
8/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Lagerbestand schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
unlock() steht nicht im finally; eine Exception sperrt den kritischen Abschnitt dauerhaft.
Ausgangspunkt-Code
import java.util.concurrent.locks.ReentrantLock;

final class Lagerbestand133Bad {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        riskyWrite();
        lock.unlock();
    }
    void riskyWrite() { throw new RuntimeException("boom"); }
}
Ziel-Code
import java.util.concurrent.locks.ReentrantLock;

final class Lagerbestand133Locked {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        try {
            riskyWrite();
        } finally {
            lock.unlock();
        }
    }
    void riskyWrite() { /* Fachänderung */ }
}
Enterprise-Einordnung
Für Lagerbestand gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-134 - ReadWriteLock für leseintensive Versandavis-Caches

Englischer technischer Begriff
ReadWriteLock
Priorität
7/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Versandavis schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Gemeinsam genutzte Maps werden ohne Synchronisation gelesen und geschrieben.
Ausgangspunkt-Code
import java.util.*;

final class Versandavis134Bad {
    private final Map<String, String> cache = new HashMap<>();
    String get(String key) { return cache.get(key); }
}
Ziel-Code
import java.util.*;
import java.util.concurrent.locks.*;

final class Versandavis134Cache {
    private final Map<String, String> cache = new HashMap<>();
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    String get(String key) {
        lock.readLock().lock();
        try { return cache.get(key); } finally { lock.readLock().unlock(); }
    }
    void put(String key, String value) {
        lock.writeLock().lock();
        try { cache.put(key, value); } finally { lock.writeLock().unlock(); }
    }
}
Enterprise-Einordnung
Für Versandavis gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-135 - Atomic-Kennzahlen für Retourenimport

Englischer technischer Begriff
Atomic Variables
Priorität
8/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Retourenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Zähler werden mit ++ aktualisiert; unter Last gehen Inkremente verloren.
Ausgangspunkt-Code
final class Retourenimport135Bad {
    private int success;
    void increment() { success++; }
    int success() { return success; }
}
Ziel-Code
import java.util.concurrent.atomic.AtomicInteger;

final class Retourenimport135Metrics {
    private final AtomicInteger success = new AtomicInteger();
    void increment() { success.incrementAndGet(); }
    int success() { return success.get(); }
}
Enterprise-Einordnung
Für Retourenimport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-136 - volatile Stop-Flag für Compliance-Export-Worker

Englischer technischer Begriff
Volatile Visibility
Priorität
6/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Compliance-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Ein Stop-Flag ist nicht sichtbar zwischen Threads; Worker laufen weiter.
Ausgangspunkt-Code
final class ComplianceExport136Bad implements Runnable {
    private boolean running = true;
    public void run() { while (running) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Ziel-Code
final class ComplianceExport136Worker implements Runnable {
    private volatile boolean running = true;
    public void run() { while (running && !Thread.currentThread().isInterrupted()) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Enterprise-Einordnung
Für Compliance-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-137 - Unveränderliche Snapshots für CRM-Synchronisation

Englischer technischer Begriff
Immutable Snapshot
Priorität
8/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei CRM-Synchronisation schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Interne Collections werden nach außen gegeben; andere Threads ändern Zustand unkontrolliert.
Ausgangspunkt-Code
import java.util.*;

final class CRMSynchronisation137Bad {
    private final List<String> rows = new ArrayList<>();
    List<String> rows() { return rows; }
}
Ziel-Code
import java.util.*;

final class CRMSynchronisation137Snapshot {
    private final List<String> rows;
    CRMSynchronisation137Snapshot(List<String> rows) { this.rows = List.copyOf(rows); }
    List<String> rows() { return rows; }
}
Enterprise-Einordnung
Für CRM-Synchronisation gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-138 - Locks bei Berechtigungsdump immer im finally freigeben

Englischer technischer Begriff
Lock try/finally
Priorität
9/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Berechtigungsdump schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
unlock() steht nicht im finally; eine Exception sperrt den kritischen Abschnitt dauerhaft.
Ausgangspunkt-Code
import java.util.concurrent.locks.ReentrantLock;

final class Berechtigungsdump138Bad {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        riskyWrite();
        lock.unlock();
    }
    void riskyWrite() { throw new RuntimeException("boom"); }
}
Ziel-Code
import java.util.concurrent.locks.ReentrantLock;

final class Berechtigungsdump138Locked {
    private final ReentrantLock lock = new ReentrantLock();
    void update() {
        lock.lock();
        try {
            riskyWrite();
        } finally {
            lock.unlock();
        }
    }
    void riskyWrite() { /* Fachänderung */ }
}
Enterprise-Einordnung
Für Berechtigungsdump gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-139 - ReadWriteLock für leseintensive Reporting-Pipeline-Caches

Englischer technischer Begriff
ReadWriteLock
Priorität
6/10
Warum wichtig
Synchronisation muss möglichst klein, korrekt und nachvollziehbar sein. Falsche Locks verursachen Race Conditions oder Deadlocks. Bei Reporting-Pipeline schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Gemeinsam genutzte Maps werden ohne Synchronisation gelesen und geschrieben.
Ausgangspunkt-Code
import java.util.*;

final class ReportingPipeline139Bad {
    private final Map<String, String> cache = new HashMap<>();
    String get(String key) { return cache.get(key); }
}
Ziel-Code
import java.util.*;
import java.util.concurrent.locks.*;

final class ReportingPipeline139Cache {
    private final Map<String, String> cache = new HashMap<>();
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    String get(String key) {
        lock.readLock().lock();
        try { return cache.get(key); } finally { lock.readLock().unlock(); }
    }
    void put(String key, String value) {
        lock.writeLock().lock();
        try { cache.put(key, value); } finally { lock.writeLock().unlock(); }
    }
}
Enterprise-Einordnung
Für Reporting-Pipeline gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
BlockingQueue, Backpressure und Worker12 Einträge

Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie.

BP-140 - BlockingQueue für Ticket-Anhang-Worker

Englischer technischer Begriff
Producer Consumer Queue
Priorität
8/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Ticket-Anhang schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine ArrayList wird als Queue missbraucht; remove(0), Race Conditions und busy waiting folgen.
Ausgangspunkt-Code
import java.util.*;

final class TicketAnhang140Bad {
    private final List<String> jobs = new ArrayList<>();
    void add(String job) { jobs.add(job); }
    String take() { return jobs.remove(0); }
}
Ziel-Code
import java.util.concurrent.*;

final class TicketAnhang140QueueWorker {
    private final BlockingQueue<String> jobs = new ArrayBlockingQueue<>(100);
    boolean submit(String job) { return jobs.offer(job); }
    String take() throws InterruptedException { return jobs.take(); }
}
Enterprise-Einordnung
Für Ticket-Anhang gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-141 - Poison Pill zum Stoppen von Preislistenimport-Workern

Englischer technischer Begriff
Poison Pill
Priorität
7/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Preislistenimport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Worker werden hart gestoppt oder per Interrupt ohne Protokoll beendet.
Ausgangspunkt-Code
final class Preislistenimport141Bad {
    void stop(Thread worker) {
        worker.stop();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Preislistenimport141PoisonPill {
    private static final String STOP = "__STOP__";
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void stop() throws InterruptedException { queue.put(STOP); }
    void runLoop() throws InterruptedException {
        while (true) {
            String item = queue.take();
            if (STOP.equals(item)) break;
            process(item);
        }
    }
    void process(String item) { }
}
Enterprise-Einordnung
Für Preislistenimport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-142 - Semaphore-Backpressure für Mandantenablage

Englischer technischer Begriff
Semaphore Backpressure
Priorität
8/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Mandantenablage schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Mandantenablage142Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Mandantenablage142Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Mandantenablage gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-143 - Queue-Überlauf bei Batch-Ergebnis bewusst ablehnen

Englischer technischer Begriff
Bounded Queue Rejection
Priorität
7/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Batch-Ergebnis schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine unbounded Queue sammelt unbegrenzt Jobs und verschiebt Fehler in den Speicher.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class BatchErgebnis143Bad {
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void submit(String job) throws InterruptedException { queue.put(job); }
}
Ziel-Code
import java.util.concurrent.*;

final class BatchErgebnis143BoundedQueue {
    private final BlockingQueue<String> queue = new ArrayBlockingQueue<>(500);
    boolean submit(String job) {
        return queue.offer(job); // false ist bewusstes Backpressure-Signal
    }
}
Enterprise-Einordnung
Für Batch-Ergebnis gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-144 - Bounded Executor für EDI-Austausch

Englischer technischer Begriff
Bounded Executor / Bulkhead
Priorität
9/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei EDI-Austausch schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Unbegrenzte Queues oder Cached Pools verstecken Überlast, bis Speicher oder Downstream ausfallen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class EDIAustausch144Bad {
    ExecutorService pool() {
        return Executors.newCachedThreadPool();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class EDIAustausch144BoundedExecutor {
    ExecutorService pool() {
        return new ThreadPoolExecutor(4, 8, 30, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(200),
                new ThreadPoolExecutor.CallerRunsPolicy());
    }
}
Enterprise-Einordnung
Für EDI-Austausch gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-145 - BlockingQueue für Benachrichtigungsjob-Worker

Englischer technischer Begriff
Producer Consumer Queue
Priorität
7/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Benachrichtigungsjob schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine ArrayList wird als Queue missbraucht; remove(0), Race Conditions und busy waiting folgen.
Ausgangspunkt-Code
import java.util.*;

final class Benachrichtigungsjob145Bad {
    private final List<String> jobs = new ArrayList<>();
    void add(String job) { jobs.add(job); }
    String take() { return jobs.remove(0); }
}
Ziel-Code
import java.util.concurrent.*;

final class Benachrichtigungsjob145QueueWorker {
    private final BlockingQueue<String> jobs = new ArrayBlockingQueue<>(100);
    boolean submit(String job) { return jobs.offer(job); }
    String take() throws InterruptedException { return jobs.take(); }
}
Enterprise-Einordnung
Für Benachrichtigungsjob gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-146 - Poison Pill zum Stoppen von Archiv-Retention-Workern

Englischer technischer Begriff
Poison Pill
Priorität
7/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Archiv-Retention schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Worker werden hart gestoppt oder per Interrupt ohne Protokoll beendet.
Ausgangspunkt-Code
final class ArchivRetention146Bad {
    void stop(Thread worker) {
        worker.stop();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class ArchivRetention146PoisonPill {
    private static final String STOP = "__STOP__";
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void stop() throws InterruptedException { queue.put(STOP); }
    void runLoop() throws InterruptedException {
        while (true) {
            String item = queue.take();
            if (STOP.equals(item)) break;
            process(item);
        }
    }
    void process(String item) { }
}
Enterprise-Einordnung
Für Archiv-Retention gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-147 - Semaphore-Backpressure für Suchindex-Import

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Suchindex-Import schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class SuchindexImport147Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class SuchindexImport147Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Suchindex-Import gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-148 - Queue-Überlauf bei Abrechnungsbeleg bewusst ablehnen

Englischer technischer Begriff
Bounded Queue Rejection
Priorität
6/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Abrechnungsbeleg schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine unbounded Queue sammelt unbegrenzt Jobs und verschiebt Fehler in den Speicher.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Abrechnungsbeleg148Bad {
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void submit(String job) throws InterruptedException { queue.put(job); }
}
Ziel-Code
import java.util.concurrent.*;

final class Abrechnungsbeleg148BoundedQueue {
    private final BlockingQueue<String> queue = new ArrayBlockingQueue<>(500);
    boolean submit(String job) {
        return queue.offer(job); // false ist bewusstes Backpressure-Signal
    }
}
Enterprise-Einordnung
Für Abrechnungsbeleg gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-149 - Bounded Executor für Steuerdatei

Englischer technischer Begriff
Bounded Executor / Bulkhead
Priorität
9/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Steuerdatei schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Unbegrenzte Queues oder Cached Pools verstecken Überlast, bis Speicher oder Downstream ausfallen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Steuerdatei149Bad {
    ExecutorService pool() {
        return Executors.newCachedThreadPool();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Steuerdatei149BoundedExecutor {
    ExecutorService pool() {
        return new ThreadPoolExecutor(4, 8, 30, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(200),
                new ThreadPoolExecutor.CallerRunsPolicy());
    }
}
Enterprise-Einordnung
Für Steuerdatei gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-150 - BlockingQueue für Legacy-Migration-Worker

Englischer technischer Begriff
Producer Consumer Queue
Priorität
8/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Legacy-Migration schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine ArrayList wird als Queue missbraucht; remove(0), Race Conditions und busy waiting folgen.
Ausgangspunkt-Code
import java.util.*;

final class LegacyMigration150Bad {
    private final List<String> jobs = new ArrayList<>();
    void add(String job) { jobs.add(job); }
    String take() { return jobs.remove(0); }
}
Ziel-Code
import java.util.concurrent.*;

final class LegacyMigration150QueueWorker {
    private final BlockingQueue<String> jobs = new ArrayBlockingQueue<>(100);
    boolean submit(String job) { return jobs.offer(job); }
    String take() throws InterruptedException { return jobs.take(); }
}
Enterprise-Einordnung
Für Legacy-Migration gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-151 - Poison Pill zum Stoppen von Kubernetes-Config-Workern

Englischer technischer Begriff
Poison Pill
Priorität
6/10
Warum wichtig
Queues entkoppeln Produzenten und Konsumenten, brauchen aber Grenzen, Stop-Mechanik und Fehlerstrategie. Bei Kubernetes-Config schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Worker werden hart gestoppt oder per Interrupt ohne Protokoll beendet.
Ausgangspunkt-Code
final class KubernetesConfig151Bad {
    void stop(Thread worker) {
        worker.stop();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class KubernetesConfig151PoisonPill {
    private static final String STOP = "__STOP__";
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>();
    void stop() throws InterruptedException { queue.put(STOP); }
    void runLoop() throws InterruptedException {
        while (true) {
            String item = queue.take();
            if (STOP.equals(item)) break;
            process(item);
        }
    }
    void process(String item) { }
}
Enterprise-Einordnung
Für Kubernetes-Config gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Concurrent Testing12 Einträge

Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall.

BP-152 - Nebenläufige OpenShift-Secret-Export-Tests mit Latches starten

Englischer technischer Begriff
CountDownLatch Concurrent Test
Priorität
7/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei OpenShift-Secret-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Sleep-basierte Tests sind zufällig und prüfen Race Conditions nicht deterministisch.
Ausgangspunkt-Code
final class OpenShiftSecretExport152BadTest {
    void testRace() throws Exception {
        new Thread(() -> serviceCall()).start();
        Thread.sleep(100);
    }
    void serviceCall() { }
}
Ziel-Code
import java.util.concurrent.*;

final class OpenShiftSecretExport152LatchTest {
    void testTwoThreadsStartTogether() throws Exception {
        CountDownLatch start = new CountDownLatch(1);
        ExecutorService pool = Executors.newFixedThreadPool(2);
        Future<?> a = pool.submit(() -> awaitAndCall(start));
        Future<?> b = pool.submit(() -> awaitAndCall(start));
        start.countDown();
        a.get(1, TimeUnit.SECONDS);
        b.get(1, TimeUnit.SECONDS);
        pool.shutdownNow();
    }
    void awaitAndCall(CountDownLatch start) { try { start.await(); serviceCall(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }
    void serviceCall() { }
}
Enterprise-Einordnung
Für OpenShift-Secret-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-153 - Concurrent Tests für Fehlerprotokoll mit Timeout absichern

Englischer technischer Begriff
Timeout-based Concurrent Test
Priorität
9/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Fehlerprotokoll schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Tests warten unbegrenzt auf Future-Ergebnisse und blockieren die Pipeline.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Fehlerprotokoll153BadTest {
    void waitsForever(Future<String> future) throws Exception {
        future.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Fehlerprotokoll153TimeoutTest {
    String waitsWithLimit(Future<String> future) throws Exception {
        return future.get(2, TimeUnit.SECONDS);
    }
}
Enterprise-Einordnung
Für Fehlerprotokoll gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-154 - Fehler in CompletableFuture-Pipelines für Mandanten-Backup behandeln

Englischer technischer Begriff
CompletableFuture Error Handling
Priorität
6/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Mandanten-Backup schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Fehlerpfade fehlen; eine einzelne Exception zerstört die ganze Pipeline ohne fachlichen Ersatzwert.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class MandantenBackup154Bad {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase);
    }
}
Ziel-Code
import java.util.concurrent.*;

final class MandantenBackup154FutureErrors {
    CompletableFuture<String> call(CompletableFuture<String> future) {
        return future.thenApply(String::toUpperCase)
                .handle((value, error) -> error == null ? value : "ERSATZWERT");
    }
}
Enterprise-Einordnung
Für Mandanten-Backup gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-155 - ExecutorService bei Schnittstellenprotokoll geordnet beenden

Englischer technischer Begriff
Graceful Executor Shutdown
Priorität
8/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Schnittstellenprotokoll schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Pools werden gestartet, aber nie sauber beendet; Tests, Deployments und Jobs hängen.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Schnittstellenprotokoll155Bad {
    ExecutorService start() {
        return Executors.newFixedThreadPool(8); // kein Shutdown-Pfad
    }
}
Ziel-Code
import java.time.Duration;
import java.util.concurrent.*;

final class Schnittstellenprotokoll155ExecutorLifecycle {
    void shutdown(ExecutorService executor, Duration timeout) throws InterruptedException {
        executor.shutdown();
        if (!executor.awaitTermination(timeout.toMillis(), TimeUnit.MILLISECONDS)) {
            executor.shutdownNow();
        }
    }
}
Enterprise-Einordnung
Für Schnittstellenprotokoll gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-156 - volatile Stop-Flag für Job-Checkpoint-Worker

Englischer technischer Begriff
Volatile Visibility
Priorität
7/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Job-Checkpoint schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Ein Stop-Flag ist nicht sichtbar zwischen Threads; Worker laufen weiter.
Ausgangspunkt-Code
final class JobCheckpoint156Bad implements Runnable {
    private boolean running = true;
    public void run() { while (running) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Ziel-Code
final class JobCheckpoint156Worker implements Runnable {
    private volatile boolean running = true;
    public void run() { while (running && !Thread.currentThread().isInterrupted()) doWork(); }
    void stop() { running = false; }
    void doWork() { }
}
Enterprise-Einordnung
Für Job-Checkpoint gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-157 - Atomic-Kennzahlen für Event-Replay

Englischer technischer Begriff
Atomic Variables
Priorität
7/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Event-Replay schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Zähler werden mit ++ aktualisiert; unter Last gehen Inkremente verloren.
Ausgangspunkt-Code
final class EventReplay157Bad {
    private int success;
    void increment() { success++; }
    int success() { return success; }
}
Ziel-Code
import java.util.concurrent.atomic.AtomicInteger;

final class EventReplay157Metrics {
    private final AtomicInteger success = new AtomicInteger();
    void increment() { success.incrementAndGet(); }
    int success() { return success.get(); }
}
Enterprise-Einordnung
Für Event-Replay gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-158 - Nebenläufige Data-Lake-Export-Tests mit Latches starten

Englischer technischer Begriff
CountDownLatch Concurrent Test
Priorität
7/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Data-Lake-Export schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Sleep-basierte Tests sind zufällig und prüfen Race Conditions nicht deterministisch.
Ausgangspunkt-Code
final class DataLakeExport158BadTest {
    void testRace() throws Exception {
        new Thread(() -> serviceCall()).start();
        Thread.sleep(100);
    }
    void serviceCall() { }
}
Ziel-Code
import java.util.concurrent.*;

final class DataLakeExport158LatchTest {
    void testTwoThreadsStartTogether() throws Exception {
        CountDownLatch start = new CountDownLatch(1);
        ExecutorService pool = Executors.newFixedThreadPool(2);
        Future<?> a = pool.submit(() -> awaitAndCall(start));
        Future<?> b = pool.submit(() -> awaitAndCall(start));
        start.countDown();
        a.get(1, TimeUnit.SECONDS);
        b.get(1, TimeUnit.SECONDS);
        pool.shutdownNow();
    }
    void awaitAndCall(CountDownLatch start) { try { start.await(); serviceCall(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }
    void serviceCall() { }
}
Enterprise-Einordnung
Für Data-Lake-Export gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-159 - Concurrent Tests für Kassenabschluss mit Timeout absichern

Englischer technischer Begriff
Timeout-based Concurrent Test
Priorität
9/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Kassenabschluss schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Tests warten unbegrenzt auf Future-Ergebnisse und blockieren die Pipeline.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Kassenabschluss159BadTest {
    void waitsForever(Future<String> future) throws Exception {
        future.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Kassenabschluss159TimeoutTest {
    String waitsWithLimit(Future<String> future) throws Exception {
        return future.get(2, TimeUnit.SECONDS);
    }
}
Enterprise-Einordnung
Für Kassenabschluss gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-160 - BlockingQueue für Produktbild-Worker

Englischer technischer Begriff
Producer Consumer Queue
Priorität
7/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Produktbild schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Eine ArrayList wird als Queue missbraucht; remove(0), Race Conditions und busy waiting folgen.
Ausgangspunkt-Code
import java.util.*;

final class Produktbild160Bad {
    private final List<String> jobs = new ArrayList<>();
    void add(String job) { jobs.add(job); }
    String take() { return jobs.remove(0); }
}
Ziel-Code
import java.util.concurrent.*;

final class Produktbild160QueueWorker {
    private final BlockingQueue<String> jobs = new ArrayBlockingQueue<>(100);
    boolean submit(String job) { return jobs.offer(job); }
    String take() throws InterruptedException { return jobs.take(); }
}
Enterprise-Einordnung
Für Produktbild gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-161 - Semaphore-Backpressure für Adressexport

Englischer technischer Begriff
Semaphore Backpressure
Priorität
9/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Adressexport schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Alle Aufträge werden angenommen; Überlast wird erst durch Timeouts oder Systemausfälle sichtbar.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Adressexport161Bad {
    void call(ExecutorService pool, Runnable task) {
        pool.submit(task); // unbegrenzt viele parallele Remote Calls
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Adressexport161Backpressure {
    private final Semaphore permits = new Semaphore(20);
    void call(Runnable remoteCall) {
        if (!permits.tryAcquire()) throw new RejectedExecutionException("Zu viele parallele Aufrufe");
        try { remoteCall.run(); } finally { permits.release(); }
    }
}
Enterprise-Einordnung
Für Adressexport gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-162 - Nebenläufige Lizenzbericht-Tests mit Latches starten

Englischer technischer Begriff
CountDownLatch Concurrent Test
Priorität
7/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Lizenzbericht schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Sleep-basierte Tests sind zufällig und prüfen Race Conditions nicht deterministisch.
Ausgangspunkt-Code
final class Lizenzbericht162BadTest {
    void testRace() throws Exception {
        new Thread(() -> serviceCall()).start();
        Thread.sleep(100);
    }
    void serviceCall() { }
}
Ziel-Code
import java.util.concurrent.*;

final class Lizenzbericht162LatchTest {
    void testTwoThreadsStartTogether() throws Exception {
        CountDownLatch start = new CountDownLatch(1);
        ExecutorService pool = Executors.newFixedThreadPool(2);
        Future<?> a = pool.submit(() -> awaitAndCall(start));
        Future<?> b = pool.submit(() -> awaitAndCall(start));
        start.countDown();
        a.get(1, TimeUnit.SECONDS);
        b.get(1, TimeUnit.SECONDS);
        pool.shutdownNow();
    }
    void awaitAndCall(CountDownLatch start) { try { start.await(); serviceCall(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }
    void serviceCall() { }
}
Enterprise-Einordnung
Für Lizenzbericht gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.

BP-163 - Concurrent Tests für Schulungsunterlage mit Timeout absichern

Englischer technischer Begriff
Timeout-based Concurrent Test
Priorität
8/10
Warum wichtig
Nebenläufige Fehler sind selten deterministisch. Tests brauchen Latches, Timeouts und wiederholbare Belastung statt Sleep-Zufall. Bei Schulungsunterlage schützt diese Praxis vor Datenverlust, Speicherproblemen, Sicherheitslücken oder schwer reproduzierbaren Produktionsfehlern.
Typischer Fehler
Tests warten unbegrenzt auf Future-Ergebnisse und blockieren die Pipeline.
Ausgangspunkt-Code
import java.util.concurrent.*;

final class Schulungsunterlage163BadTest {
    void waitsForever(Future<String> future) throws Exception {
        future.get();
    }
}
Ziel-Code
import java.util.concurrent.*;

final class Schulungsunterlage163TimeoutTest {
    String waitsWithLimit(Future<String> future) throws Exception {
        return future.get(2, TimeUnit.SECONDS);
    }
}
Enterprise-Einordnung
Für Schulungsunterlage gehört diese Regel in die Application-Service- oder Runtime-Schicht. Sie sollte als wiederverwendbarer Baustein, Testfall oder Architekturregel dokumentiert werden, damit Teams sie nicht in jeder Fachlogik neu erfinden.
Hinweise zur Weiterarbeit0 Einträge

- Für reale Projekte sollten die Codeausschnitte in Modul-Adapter, Test-Fixtures und Architekturregeln überführt werden. - Security-Regeln gehören zusätzlich in Code Reviews, CI-Prüfungen und technische Runbooks. - Concurrency-Regeln sollten mit Lasttests, Timeout-Tests und Metriken abgesichert werden.

⌂ Cockpit