Klasy rekordów implicitnie deklarują pola komponentów jako final, co zabrania mutacji po konstrukcji. Podczas używania skompaktowanego konstruktora — pomijając formalną listę parametrów — kompilator Javy zabrania jawnego przypisywania pola przez this.component = ..., ponieważ automatycznie wstrzykuje bajtkod przypisania zaraz po wykonaniu ciała konstruktora. Ten projekt zmusza programistów do samodzielnego przypisywania zmiennych parametrów (np. component = Objects.requireNonNull(component)) zamiast bezpośredniego przypisywania do pól. W konsekwencji, defensywne kopiowanie staje się niezbędne dla komponentów mutowalnych; ponieważ rekord przechowuje referencje, brak klonowania mutowalnych argumentów wewnątrz skompaktowanego konstruktora pozwala na zewnętrzne modyfikacje, które naruszają gwarancję niemutowalności rekordu.
Podczas rozwoju platformy handlu wysokich częstotliwości, zespół architektoniczny przyjął klasy rekordów do reprezentowania niemutowalnych danych rynkowych, zawierających cenę jako BigDecimal oraz znacznik czasu jako java.util.Date. Mutowalność Date stanowiła krytyczne zagrożenie, ponieważ warunek wyścigu mógł pozwolić wątkowi producenta na modyfikację obiektu timestamp po utworzeniu rekordu, psując ślad audytu.
Rozważano trzy podejścia, aby zminimalizować to zagrożenie. Pierwsza strategia polegała na migracji do java.time.Instant, niemutowalnego typu temporalnego. Choć to wyeliminowało narzut związany z defensywnym kopiowaniem i zastosowaniem nowoczesnych interfejsów programowania czasu w Javie, wymagało to obszernej refaktoryzacji komponentów middleware pochodzenia, które serializowały obiekty Date, wprowadzając nieakceptowalne ryzyko dostawy.
Drugą opcją było wykorzystanie statycznej metody fabrycznej do przeprowadzenia defensywnego kopiowania przed przekazaniem do kanonicznego konstruktora. To podejście zachowało enkapsulację, ale zrezygnowało z zwięzłej składni i automatycznych korzyści z równości strukturalnej intrinsic ensuing w rekordach, dodatkowo komplikując frameworki deserializacji oczekujące wzorców kanonicznego konstruktora.
Ostateczne rozwiązanie polegało na zastosowaniu skompaktowanego konstruktora do walidacji wejść i tworzenia defensywnych klonów: timestamp = (Date) timestamp.clone();. To wykorzystało implicitne przypisanie pól kompilatora do przechowywania kopii, a nie oryginalnej referencji, zapewniając bezpieczeństwo wątków bez poświęcania semantyki rekordu.
Implementacja skutecznie zapobiegła atakom na manipulację czasem, osiągając zerową liczbę incydentów uszkodzenia danych podczas późniejszych testów obciążeniowych, obejmujących miliony równoczesnych transakcji.
Dlaczego kompilator odrzuca jawne przypisanie this.field wewnątrz skompaktowanego konstruktora, mimo że zezwala na to w zwykłych konstruktorach?
Specyfikacja języka Java definiuje skompaktowane konstruktory jako rozszerzone do kanonicznych konstruktorów, w których kompilator syntetyzuje listę parametrów i dodaje przypisania pól. Ponieważ komponenty rekordu są implicitnie final, ciało skompaktowanego konstruktora wykonuje się w stanie przedprzypisania, gdzie pola są uważane za „zdecydowanie nieprzypisane”. Jakiekolwiek jawne przypisanie this.field stanowiłoby drugie przypisanie do zmiennej final, naruszając zasady zdecydowanego przypisania, podczas gdy ponowne przypisanie zmiennej parametru jest dozwolone, ponieważ jedynie zacienia implicitne przypisanie, które następuje później.
Jak defensywne kopiowanie w skompaktowanym konstruktorze rekordu chroni przed atakami deserializacji podczas używania ObjectInputStream?
W odróżnieniu od tradycyjnych klas Serializable, które JVM instancjonuje za pomocą alokacji Unsafe i populacji przez refleksję lub metody readObject, deserializowane rekordy są zawsze rekonstruowane poprzez wywołanie kanonicznego konstruktora z argumentami dostarczonymi przez strumień. Dlatego logika defensywnego kopiowania wykonywana wewnątrz skompaktowanego konstruktora automatycznie oczyszcza złośliwe lub uszkodzone strumienie wejściowe, próbujące wstrzykiwać obiekty mutowalne do późniejszej modyfikacji. Programiści często pomijają ten mechanizm, błędnie implementując metody readObject lub readResolve w rekordach, gdzie nie są one ani potrzebne, ani wywoływane podczas standardowej deserializacji.
Jaka różnica bajtkodowa istnieje między skompaktowanym konstruktorem a wyraźnie zadeklarowanym kanonicznym konstruktorem w rekordach?
Skompaktowany konstruktor kompiluje się do bajtkodu, gdzie invokespecial (wywołując konstruktor Object) jest poprzedzony logiką konstruktora, a następnie generowane przez kompilator instrukcje putfield dla każdego komponentu. Przeciwnie, explicite zadeklarowany kanoniczny konstruktor osadza operacje putfield napisane przez programistę. Ta różnica zapobiega wykonywaniu walidacji lub logiki po inicjalizacji pola w tym samym metodzie, zasadniczo ograniczając sekwencję inicjalizacji i wymagając, aby wszystkie defensywne transformacje miały miejsce na zmiennych parametrów przed wykonaniem implicitnych przypisań.