Java-ийн 10 Жилийн Хүлээлт Дууслаа: JEP 401 "Value Objects" JDK 28-д Албан Ёсоор Нэгдлээ

10 жилийн хөгжүүлэлтийн үр дүн: Project Valhalla-ийн хамгийн том PR нэгдлээ

Java хөгжүүлэгчдийн дунд арав гаруй жил хүлээгдсэн OpenJDK-ийн хамгийн амбицтай төсөл болох Project Valhalla томоохон түүхэн үе шатандаа хүрлээ. Хөгжүүлэгчдийн удаан хугацаанд санал болгосон JEP 401 (Value Objects - Preview) болон JEP 539 (Strict Field Initialization - Preview) саналууд баталгаажиж, OpenJDK-ийн үндсэн (master) салбарт албан ёсоор merge хийгдэн, ирэх JDK 28 хувилбарт багтахаар боллоо.

Энэхүү шинэчлэл нь ердийн нэг жижиг боломж эсвэл бэлэн функц биш юм. Нийт 1,816 файл өөрчлөгдөж, 197,000 гаруй мөр код нэмэгдсэн нь Java-ийн сүүлийн 10 жилд хийгдсэн хамгийн том хэлний болон JVM (Java Virtual Machine) түвшний өөрчлөлтөд тооцогдож байна.

Oracle болон OpenJDK багийн гол зорилго бол Java-ийн объектын загварыг шинэчилж, Object Identity-гүй буюу санах ойн хаяг заадаггүй "Value Object"-ийг хэлний түвшинд анх удаа нэвтрүүлэх явдал юм.

Хуучин зовлон: Primitive болон Object-ийн асар том зааг

Java анх үүссэн цагаасаа өгөгдлийг хоёр өөр байдлаар удирдаж ирсэн:

Primitives (int, double, boolean г.м): Санах ойд шууд утгаараа хадгалагддаг, объект биш тул header, pointer гэх мэт нэмэлт ачаалалгүй, маш хурдан.
Reference Types / Objects: Heap санах ойд байршиж, бие даасан хаяг (Identity) болон Object Header (12-16 байт) агуулдаг.

Энэхүү ялгаанаас үүдэж Java хөгжүүлэгчид хэд хэдэн том бэрхшээлтэй тулгардаг байв:

Identity Trap (== харьцуулалт):
```
Integer a = 200;
Integer b = 200;
System.out.println(a == b); // false! (Санах ойн хаяг өөр тул)
```
Java нь -128-аас 127 хүртэлх Integer-ийг cache хийдэг ч, түүнээс дээш утгатай эсвэл LocalDate, Point зэрэг объектуудыг == оператороор харьцуулахад утгыг нь биш санах ойн хаягийг харьцуулж false буцаадаг.
Санах ойн ачаалал болон Garbage Collection (GC): Сая сая жижиг объект (Point, UUID, Money г.м) үүсгэхэд объект бүр тусдаа pointer зааж Heap санах ойд таран байршдаг. Энэ нь CPU-ийн Cache Locality-г багасгаж, GC дээр асар том ачаалал үүсгэдэг байв.

JEP 401: `value` түлхүүр үг ба шинэ зан төлөв

JEP 401 нь value гэсэн шинэ модификаторыг (modifier) танилцуулж байна. Классыг value class эсвэл value record гэж тодорхойлсноор тухайн класс "Object Identity"-ээс татгалзаж байна гэсэн үг юм.

Код жишээ:

public value class Point {
    private int x; // Далд хэлбэрээр implicitly final
    private int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int x() { return x; }
    public int y() { return y; }
}

Мөн record дээр шууд ашиглаж болно:

public value record Color(byte red, byte green, byte blue) {}

`==` операторын шинэ ажиллагаа:

Value Object-уудын хувьд == оператор нь тэдний санах ойн хаягийг бус, талбар бүрийнх нь утгыг рекурсив байдлаар харьцуулж ажиллана.

Point p1 = new Point(3, 4);
Point p2 = new Point(3, 4);

assert p1 == p2; // TRUE! Төрөл ба талбаруудын утга ижил тул

Одоо Java-д заавал equals() дуудалгүйгээр == оператороор утгын чанартай объектуудыг аюулгүй харьцуулах боломжтой болж байна.

Архитектурын давуу тал: GC ба Санах ойн "Flattening"

JEP 401-ийн хамгийн чамин хэсэг нь кодын бичиглэлд төдийгүй, JVM-ийн гүн түвшинд гарах гүйцэтгэлийн үсрэлт юм:

Heap Flattening (Санах ойн хавтгайруулалт): Value Object нь Identity-гүй тул JVM тэдгээрийг тусдаа Heap дээрх заагч олгох шаардлагагүй гэж үзнэ. Жишээ нь Point[] массив үүсгэхэд тус бүрт нь pointer заалгахгүйгээр, шууд x1, y1, x2, y2 гэх мэтээр санах ойд дараалсан биет өгөгдөл (inline layout) болгон байршуулна.
Allocation-free execution: Жижиг объектуудыг функц дамжуулах, буцаахад санах ойд шинээр объект үүсгэхгүйгээр CPU-ийн регистр дотор шууд утгаар нь дамжуулах боломжтой болно.
GC Ачаалал эрс багасна: Heap санах ойд үүсэх "хог" объектын тоо асар олноор багасах тул Garbage Collector-ийн паузын хугацаа эрс багасна.

Дүрэм болон Хязгаарлалтууд

Value Object-ийг ашиглахдаа дараах дүрмүүдийг анхаарах шаардлагатай:

Бүх талбар final байна: Утга нь нэгэнт үүссэн бол өөрчлөгдөхгүй (immutable).
Strict Field Initialization (JEP 539): Байгуулагч функц (constructor) дотор бүх талбар заавал эхлүүлэгдсэн (assigned) байх ёстой.
No Synchronization: Value Object дээр synchronized (obj) блокийг ашиглаж болохгүй. Учир нь объектод санах ойн тусдаа lock тавих Identity хаяг байхгүй.
JDK-ийн сангуудын шилжилт: Стандарт JDK-д байдаг Integer, Double, LocalDate, Optional зэрэг классууд ирээдүйд автоматаар Value Class рүү шилжих бөгөөд ингэснээр хуучин Java кодуудын гүйцэтгэл шинэ JVM дээр аяндаа хурдсах болно.

Дүгнэлт

JEP 401 буюу Value Objects нь Java хэлийг орчин үеийн C++, Rust зэрэг хэлүүдийн санах ойн ашиглалтын өндөр гүйцэтгэлтэй ойртуулж буй түүхэн алхам юм. JDK 28-аас эхлэн Preview хэлбэрээр турших боломжтой бөгөөд туршихдаа --enable-preview болон --release 28 флагоор ажиллуулна.

Хэрэв та Java/JVM экосистемд систем хөгжүүлдэг бол энэхүү өөрчлөлт ирээдүйн кодын архитектур ба гүйцэтгэлд асар том хувьсгал авчирна гэдэгт эргэлзэх зүйлгүй.

Эх сурвалж: InfoQ - Project Valhalla's First Preview: JEP 401 Redefines == for Java Objects