Java 28-ə daxili JSON API əlavə olunur: Jackson-a hələ də ehtiyac var?

JDK daxilində JSON API

Java 28 | JEP 540 | Sadə JSON API (inkubator mərhələsi)

Java proqramçıları illərdir JSON ilə işləmək üçün Jackson və Gson kimi kənar kitabxanalardan is­ti­fa­də edirlər.

REST API hazırlayanda, kənar servislərə müraciət edəndə, kon­fi­qu­ra­si­ya fayllarını oxuyanda və ya Kafka hadisələrini emal edəndə JSON ilə qarşılaşırıq.

Amma Java Development Kit-in özündə həmişə bir imkan çatışmayıb: JSON mətnini oxumaq və JSON yaratmaq üçün sadə, daxili API.

JEP 540: Simple JSON API (Incubator) ilə Java 28 bu boşluğu ara­dan qaldırmaq istiqamətində mühüm addım atır.

İlk dəfə proqramçılar Jackson, Gson və ya başqa JSON kitabxanası əlavə et­mə­dən, birbaşa JDK-nın təqdim et­di­yi xüsusi API ilə əsas JSON əmə­liy­yat­la­rı­nı ye­ri­nə yetirə biləcəklər.

Bəs bu, Jackson-un artıq lazım olmayacağı deməkdir?

Tam ola­raq yox.

JEP 540-ın nə təqdim etdiyinə, necə işlədiyinə və müasir backend tətbiqlərində hansı yeri tutduğuna baxaq.

Buraxılış və­ziy­yə­ti: JEP 540, buraxılışı 2027-ci ilin martına planlaşdırılan JDK 28-ə inteqrasiya edilib. 2 noyabr 2026-cı il tarixinə Java 28 hələ ümumi istifadəyə buraxılmayıb. API inkubator mərhələsindədir, buna görə daimi API-yə çevrilənədək di­zay­nı dəyişə bilər.

Java-ya daxili JSON API niyə lazımdır?

Tə­səv­vür edin ki, kənar API-yə müraciət edən kiçik Java tət­bi­qi hazırlayırsınız.

Cavab be­lə­dir:

{
  "service": "payment-service",
  "status": "healthy",
  "instances": 4,
  "metrics": {
    "latencyMs": 25,
    "errorRate": 0.01
  }
}

Tətbiqinizə yal­nız servisin adını, vəziyyətini və ge­cik­mə müd­də­ti­ni oxumaq la­zım­dır.

Adətən bunun üçün layihəyə kənar JSON kitabxanası əlavə edərdiniz.

Mə­sə­lən, Jackson ilə:

ObjectMapper mapper = new ObjectMapper();

JsonNode root = mapper.readTree(response);

String service = root.get("service").asText();

int latency = root
        .get("metrics")
        .get("latencyMs")
        .asInt();

Kod sadədir, amma yenə də JDK-dan kənar kitabxana tələb edir.

Böyük Spring Boot tətbiqlərində bu, nadir hal­lar­da prob­lem ya­ra­dır. Jackson artıq freymvorkla sıx inteqrasiya olunub.

Amma daha kiçik tətbiqləri nə­zər­dən ke­çi­rək:

• Əmr sətri alətləri
• Yüngül HTTP klientləri
• Proqramçılar üçün daxili köməkçi alətlər
• Sadə kon­fi­qu­ra­si­ya emalçıları
• Diaqnostika və monitorinq alətləri
• Kiçik, müstəqil Java servisləri

Belə hal­lar­da geniş imkanlı JSON freymvorku əlavə etməyə ehtiyac ol­ma­ya bilər.

JEP 540-ın məqsədi bütün JSON kitabxanalarını əvəz etmək deyil. Məq­səd əsas JSON əmə­liy­yat­la­rı­nı Java-nın standart imkanına çevirməkdir.

JEP 540 nədir?

JEP 540 JSON sənədlərini oxumaq, on­la­rın strukturunda hərəkət etmək və yeni sənədlər yaratmaq üçün yüngül API təqdim edir.

API inkubator modulu va­si­tə­si­lə verilir:

jdk.incubator.json

Onun di­zay­nı JSON standartını mü­əy­yən edən RFC 8259 spesifikasiyasına əsaslanır.

Təklif beş əsas imkanı əhatə edir:

1. JSON mətnini yaddaşda saxlanan struktura çevirmək.
2. JSON obyektləri və massivləri daxilində hərəkət etmək.
3. Tipə uyğun metodlarla dəyərləri əldə etmək.
4. Proqram va­si­tə­si­lə JSON sənədləri qur­maq.
5. JSON dəyərlərini ye­ni­dən mətnə serializasiya etmək.

Java obyektlərinə av­to­ma­tik çevirmə, JSON-un axın şəklində emalı və sxem yoxlaması kimi bəzi geniş imkanlar API-nin əhatə dairəsinə qəsdən daxil edilməyib.

Bu fərqi nəzərə almaq va­cib­dir.

JEP 540 JSON sənədləri ilə işləmək üçün API-dir, obyektlərin serializasiyası üçün tam funksional freymvork deyil.

İnkubator nə deməkdir?

Java bəzi eksperimental API-ləri inkubator modulları va­si­tə­si­lə təqdim edir.

İnkubator mərhələsindəki API-ni proqramçılar sınaqdan keçirə bilərlər, amma o, hələ Java SE-nin daimi API-si sayılmır.

Bu mərhələdə:

• Açıq API-lər dəyişə bilər.
• Proqramçılar rəy bildirə bilərlər.
• Uyğunluğu pozan dəyişikliklər mümkündür.
• Modul sonradan standartlaşdırıla və ya silinə bilər.

Canlı sistemlərlə iş­lə­yən komandalar bunu yekunlaşmış, uzunmüddətli müqavilə kimi qəbul etməməli, API-ni diqqətlə qiymətləndirməlidirlər.

JSON dəyər modeli necə qurulub?

Yeni API-nin mərkəzində JsonValue interfeysi dayanır.

Bu interfeys JSON sənədindəki bir dəyəri təmsil edir.

JSON altı əsas dəyər kateqoriyasını dəstəkləyir. Hər kateqoriyaya uyğun Java interfeysi var.

Bu interfeyslər kökündə JsonValue dayanan tip iyerarxiyası ya­ra­dır.

Ümumi quruluş be­lə­dir:

JsonValue
  +-- JsonObject
  +-- JsonArray
  +-- JsonString
  +-- JsonNumber
  +-- JsonBoolean
  +-- JsonNull

JsonValue sealed interfeysdir, onun icazə verdiyi dəyər interfeysləri isə non-sealed ola­raq təyin edilib.

Beləliklə, JSON kateqoriyalarının dəqiq siyahısı mü­əy­yən olu­nur, eyni zamanda həmin interfeyslərin implementasiyalarını yaratmaq mümkün qalır.

Bu nə üçün faydalıdır?

API bütün dəyərləri ümumi Java Object tipi kimi qəbul etmək əvəzinə, JSON dəyərlərini öz tipləri ilə təmsil edir.

Mə­sə­lən, JSON ədədi av­to­ma­tik Integer və ya Double kimi deyil, JsonNumber kimi təqdim olu­nur.

Bu yanaşma JSON tipləri ilə Java tipləri arasındakı fərqi daha aydın gös­tə­rir.

Həmçinin Java-nın müasir pattern matching imkanları ilə rahat işləyir.

4. Java 28-də JSON mətninin oxunması

Praktik nümunə ilə başlayaq.

Fərz edək ki, kənar servis bu cavabı qaytarır:

{
  "user": {
    "id": 101,
    "name": "Alice",
    "active": true
  }
}

Təklif olunan API ilə:

import jdk.incubator.json.Json;
import jdk.incubator.json.JsonValue;

String response = """
    {
      "user": {
        "id": 101,
        "name": "Alice",
        "active": true
      }
    }
    """;

JsonValue root = Json.parse(response);

int id = root
        .get("user")
        .get("id")
        .asInt();

String name = root
        .get("user")
        .get("name")
        .asString();

boolean active = root
        .get("user")
        .get("active")
        .asBoolean();

Burada diqqətəlayiq bir məqam var.

Aralıq obyektlərin hər birini əl ilə JsonObject tipinə çevirməyə ehtiyac yoxdur.

API birbaşa JsonValue üzə­rin­dən metodları zəncirvari çağıraraq strukturda hərəkət etməyə imkan verir.

Bu, API-nin ən fay­da­lı di­zayn qərarlarından biridir.

İç-içə JSON strukturlarında hərəkət

Daha mürəkkəb cavaba baxaq:

{
  "order": {
    "id": "ORD-2028",
    "customer": {
      "name": "Alice"
    },
    "items": [
      {
        "product": "Laptop",
        "quantity": 2
      },
      {
        "product": "Mouse",
        "quantity": 1
      }
    ]
  }
}

İlk məh­su­lu oxuyaq:

String product = Json.parse(response)
        .get("order")
        .get("items")
        .get(0)
        .get("product")
        .asString();

Nə­ti­cə:

Laptop

API həm obyektin sahəsinə, həm də massiv elementinə indekslə müraciəti dəstəkləyir.

• get(String) obyektin sahəsinə müraciət edir.
• get(int) massiv elementinə müraciət edir.
• asString() sətir dəyərini qaytarır.
• asInt() tam ədəd dəyərini qaytarır.
• asBoolean() məntiqi dəyəri qaytarır.

Bu, xüsusilə kənar servislərin cavablarını yox­la­yar­kən rahatdır.

5. Mövcud olmayan sahələr və null dəyərləri

Praktikada JSON sənədləri nadir hal­lar­da qüsursuz olur.

Bəzi sahələr möv­cud ol­ma­ya, məcburi ol­ma­ya və ya açıq şə­kil­də null dəyəri daşıya bilər.

Bu nümunəyə baxaq:

{
  "username": "alice",
  "email": null
}

Burada iki fərqli və­ziy­yət var:

A və­ziy­yə­ti: Sahə möv­cud deyil.

{
  "username": "alice"
}

B və­ziy­yə­ti: Sahə mövcuddur, amma dəyəri null-dur.

{
  "username": "alice",
  "email": null
}

API müqavilələrində bu vəziyyətlər fərqli mənalar daşıya bilər.

JEP 540 onları ayırd etmək üçün metodlar təqdim edir.

JsonValue root = Json.parse(response);

Optional<JsonValue> email =
        root.tryGet("email");

Obyektin sahəsi möv­cud olmayanda tryGet() boş Optional qaytarır.

Sahə mövcuddursa və JSON null dəyərini sax­la­yır­sa, qaytarılan Optional daxilində JsonNull dəyəri olur.

API JSON null dəyərini boş Optional kimi təqdim etmək üçün tryValue() metodunu da verir.

Bu, məcburi olmayan JSON sahələri üzə­rin­də proqramçıya daha çox nə­za­rət imkanı ya­ra­dır.

Canlı sistemlərdə nəzərə alınmalı məqam

Hər JSON sahəsinin möv­cud ol­du­ğu­nu və gözlənilən tipdə ol­du­ğu­nu fərz etməyin.

Kənar API cavablarını emal edər­kən məcburi sahələri yoxlayın, məcburi olmayan sahələrin necə işlənəcəyini isə açıq şə­kil­də mü­əy­yən edin.

Yanlış və ya gözlənilməz quruluşlu cavab səbəbi bilinməyən nasazlıq əvəzinə, tət­bi­qin idarə edə bildiyi xəta ilə nəticələnməlidir.

6. Kənar kitabxana olmadan JSON yaratmaq

JSON mətnini oxumaq işin yal­nız bir hissəsidir.

Tətbiqlərə JSON yaratmaq da la­zım­dır.

Mə­sə­lən, bu sənədi yaratmaq istəyirik:

{
  "service": "notification-service",
  "instances": 3,
  "healthy": true
}

JEP 540 ilə:

import jdk.incubator.json.JsonObject;
import jdk.incubator.json.JsonString;
import jdk.incubator.json.JsonNumber;
import jdk.incubator.json.JsonBoolean;

import java.util.Map;

JsonObject document = JsonObject.of(
    Map.of(
        "service",
        JsonString.of("notification-service"),

        "instances",
        JsonNumber.of(3),

        "healthy",
        JsonBoolean.of(true)
    )
);

String json = document.toString();

Alınan JSON eyni obyekti təmsil edir.

Vacib məqam budur ki, hər Java dəyəri uyğun JSON fabrik metodu ilə çevrilməlidir.

Mə­sə­lən:

JsonString.of("hello");
JsonNumber.of(42);
JsonBoolean.of(true);

Beləliklə, JSON tipi açıq şə­kil­də göstərilir.

Bununla ya­na­şı, böyük sənədlər qurarkən bəzi möv­cud JSON kitabxanalarına nisbətən daha çox kod yazmaq lazım gələ bilər.

Yığcam və formatlanmış JSON

Bu çağırış:

document.toString();

yığcam JSON ya­ra­dır.

Rahat oxunan çıxış üçün API bu metodu təqdim edir:

Json.toDisplayString(document, "  ");

Formatlanmış çıxış JSON-u diaqnostika alətlərində və proqramçılar üçün köməkçi alətlərdə göstərərkən xüsusilə faydalıdır.

7. JSON və pattern matching: müasir Java yanaşması

JSON dəyər iyerarxiyasının maraqlı üstünlüklərindən biri Java-nın pattern matching imkanları ilə uyğunluğudur.

Tə­səv­vür edin ki, kənar API identifikatoru bəzən ədəd, bəzən isə sətir kimi qaytarır.

A nümunəsi:

{
  "id": 12345
}

B nümunəsi:

{
  "id": "12345"
}

Pattern matching dəs­tək­lə­yən switch ilə hər iki formanı emal edə bilərik:

JsonValue value = Json.parse(response)
        .get("id");

long id = switch (value) {
    case JsonNumber number ->
            number.asLong();

    case JsonString string ->
            Long.parseLong(string.asString());

    default ->
            throw new IllegalArgumentException(
                    "Unsupported ID format"
            );
};

Bu yanaşmanın bir neçə üstünlüyü var:

• Hər tip üçün davranış açıq göstərilir
• Çevirmə məntiqi rahat oxunur
• Digər hal­lar­da nə baş verəcəyi aydındır
• Müasir Java dil imkanları ilə uyğun işləyir

Nümunədə identifikatorun icazə verilən iki təqdimat forması emal olu­nur.

Canlı sis­tem­də tət­biq yenə də identifikatorun qiymət aralığını və gözlənilən formatını yoxlamalıdır.

8. Dəyişməzlik və çoxaxınlı mühitdə təhlükəsizlik

Digər mühüm di­zayn qərarı JSON dəyərlərinin dəyişməz olmasıdır.

JSON sənədi oxunduqdan və ya qurulduqdan sonra onun dəyərlərini yerində dəyişmək mümkün deyil.

Mə­sə­lən, oxunmuş obyektin status sahəsini setter va­si­tə­si­lə birbaşa dəyişə bilməzsiniz.

Bunun əhəmiyyəti nədir?

Bir neçə icra axınının eyni JSON konfiqurasiyasını oxuduğu backend servisini tə­səv­vür edin.

Struktur dəyişməz ol­duq­da onu oxuyanlar ortaq sənədi təsadüfən dəyişə bilmirlər.

Bu, JSON dəyərlərinin özünü qorumaq üçün əlavə surət yaratmağa və sinxronizasiyaya ehtiyacı azal­dır.

Praktik nümunə

Servis kon­fi­qu­ra­si­ya sənədini bir dəfə oxuyub onun dəyişməz strukturunu bir neçə oxucu ara­sın­da təh­lü­kə­siz şə­kil­də paylaşa bilər.

Amma dəyişməzlik tətbiqdəki bütün əməliyyatları av­to­ma­tik ola­raq çoxaxınlı mühitdə təh­lü­kə­siz etmir.

Tət­biq ortaq konfiqurasiyaya istinadı dinamik şə­kil­də yeniləyirsə, yeni istinadın digər axınlara görünməsi və əməliyyatların əlaqələndirilməsi üçün yenə də uyğun paralel icra me­xa­nizmlə­ri la­zım­dır.

Verilən əsas təminat budur: JSON dəyərlərinin öz strukturu dəyişməzdir və çoxaxınlı mühitdə təhlükəsizdir.

9. Ciddi JSON sintaksisi və xətaların idarə edilməsi

JEP 540 JSON sintaksis qaydalarına ciddi əməl edir.

Bu sənədə baxaq:

{
  "name": "Alice",
  "active": true,
}

Burada son elementdən sonra vergül var.

Daha yumşaq qaydalarla iş­lə­yən bəzi parserlər bunu qəbul edə bilər.

JDK-nın Simple JSON API-si isə rədd edir.

Eyni qayda şərhlərə və RFC 8259-un dəstəkləmədiyi digər sintaksis genişləndirmələrinə də aiddir.

Təkrarlanan JSON açarları

Bu nümunəyə baxaq:

{
  "role": "USER",
  "role": "ADMIN"
}

Müx­tə­lif JSON parserləri təkrarlanan açarları fərqli emal edə bilər.

Bəziləri ilk dəyəri, digərləri sonuncu dəyəri sax­la­yır.

JEP 540 obyekt daxilində təkrarlanan sahə adlarını rədd edir.

Bu qərar sistemlərarası uyğunluq və düzgünlük ba­xı­mın­dan faydalıdır.

JSON oxunarkən yaranan xətaların idarə edilməsi

try {
    JsonValue document = Json.parse(response);

    // Process the document

} catch (JsonParseException exception) {
    // Handle invalid JSON syntax
}

Təklif olunan istisna API-si oxuma əməliyyatının harada uğur­suz ol­du­ğu­nu bil­di­rir.

Dəyərlərə yanlış müraciətlər və çevirmələr üçün ayrıca JsonValueException is­ti­fa­də olu­nur.

Mə­sə­lən, JSON sətirinə massiv indeksi ilə müraciət etmək düz­gün əmə­liy­yat deyil.

Təhlükəsizlik baxımından nəzərə alınmalı məqamlar

Sintaksisin ciddi yoxlanması bəzi qeyri-müəyyənlikləri ara­dan qaldırır, amma daxil olan mə­lu­ma­tın yoxlanmasını əvəz etmir.

Tətbiqlər yenə də bunları nəzərə almalıdır:

• Sor­ğu­nun maksimum ölçüsü
• Yaddaş sərfiyyatı
• Həd­din­dən artıq iç-içə strukturlu sənədlər
• Gözlənilməyən mə­lu­mat tipləri
• Ədədlərin qiymət aralıqları
• Tətbiqə xas yoxlamalar

Parserin sintaktik baxımdan düz­gün JSON-u qəbul etməsi sənədin tətbiqinizin iş qaydaları üçün təh­lü­kə­siz və ya keçərli olduğu demək deyil.

10. Java 28 JSON API, Jackson və Gson müqayisəsi

Backend mühəndisləri üçün əsas suallardan biri budur.

Yeni API möv­cud kitabxanalarla müqayisədə nə təklif edir?

JDK API-sinin əhatə dairəsi qəsdən daha kiçik saxlanılıb.

Obyektlərə çevirmə, axın şəklində emal, fərdiləşdirmə və freymvork inteqrasiyaları sayəsində Jackson korporativ tətbiqlər üçün xüsusilə fay­da­lı ola­raq qalır.

Mə­sə­lən:

record User(
        long id,
        String name,
        boolean active
) {}

Jackson ilə:

User user = objectMapper.readValue(
        response,
        User.class
);

Bu kod JSON sənədini av­to­ma­tik ola­raq Java record-una çevirir.

JEP 540 obyektlərə belə av­to­ma­tik çevirmə imkanı təqdim etmir.

Bunun əvəzinə proqramçı sahələri əl ilə oxumalı və record-u özü yaratmalıdır.

JsonValue json = Json.parse(response);

User user = new User(
        json.get("id").asLong(),
        json.get("name").asString(),
        json.get("active").asBoolean()
);

Sadə sənədlər üçün sahələri əl ilə oxumaq tamamilə məq­bul ola bilər.

Mürəkkəb domen modellərində isə Jackson adətən daha rahatdır.

Spring Boot-a hələ də Jackson lazımdır?

Tipik Spring Boot tətbiqlərində Jackson və ya dəs­tək­lə­nən başqa JSON serializasiya həlli aktuallığını qoruyacaq.

REST kontrollerinə baxaq:

@RestController
@RequestMapping("/api/users")
class UserController {

    @GetMapping("/{id}")
    UserResponse findUser(@PathVariable long id) {
        return new UserResponse(
                id,
                "Alice",
                true
        );
    }
}

Spring-in HTTP mesajlarını çevirmə in­fra­struk­tu­ru kon­fi­qu­ra­si­ya edilmiş JSON inteqrasiyası va­si­tə­si­lə cavabı serializasiya edir.

JEP 540 freymvork səviyyəsindəki bu funksi­ya­nı av­to­ma­tik əvəz etmir.

Daxili JSON API və tam funksional serializasiya freymvorkunun həll et­di­yi problemlər qismən üst-üstə düşsə də, fərqlidir.

11. Backend mühəndisləri üçün praktik istifadə halları

JEP 540-ın harada fay­da­lı ola biləcəyinə baxaq.

Nümunə 1: Servisin sağlamlıq yoxlamasının cavabını oxumaq

Fərz edək ki, servis bu sor­ğu­nu gön­də­rir:

GET /actuator/health

Cavab:

{
  "status": "UP"
}

Tətbiqə yal­nız bir dəyər la­zım­dır.

String status = Json.parse(response)
        .get("status")
        .asString();

Bu əmə­liy­yat üçün tam funksional obyektə çevirmə freymvorkuna ehtiyac ol­ma­ya bilər.

Nümunə 2: Kənar REST API-nin cavabını yoxlamaq

Tə­səv­vür edin ki, servis hava proqnozu API-sinə müraciət edir və ona yal­nız cari temperatur la­zım­dır.

int temperature = Json.parse(response)
        .get("properties")
        .get("periods")
        .get(0)
        .get("temperature")
        .asInt();

Nümunə iç-içə JSON strukturunda hərəkət etmək üçün nə qədər az kodun kifayət et­di­yi­ni gös­tə­rir.

Nümunə 3: Konfiqurasiya sənədlərini emal etmək

Əmr sətri aləti bu sənədi oxuyur:

{
  "environment": "production",
  "retry": {
    "maxAttempts": 5
  }
}

Kon­fi­qu­ra­si­ya dəyərlərini əldə edək:

JsonValue config = Json.parse(content);

String environment = config
        .get("environment")
        .asString();

int maxAttempts = config
        .get("retry")
        .get("maxAttempts")
        .asInt();

Alət bu əməliyyatları kənar JSON kitabxanası əlavə et­mə­dən ye­ri­nə yetirə bilər.

Nümunə 4: Kafka hadisələrinin məzmununu yoxlamaq

Bu Kafka hadisəsini tə­səv­vür edin:

{
  "eventType": "PAYMENT_COMPLETED",
  "paymentId": "PAY-101",
  "amount": 250
}

Yüngül diaqnostika aləti hadisənin tipini yoxlaya bilər:

String eventType = Json.parse(payload)
        .get("eventType")
        .asString();

Bu yanaşma proqramçı alətləri, xəta araşdırması və kiçik mesajların yoxlanması üçün faydalıdır.

Amma çoxlu hadisə emal edən, yüksək buraxılış qabiliyyətli Kafka istehlakçıları üçün parserin performansını, yaddaş ayırma davranışını, sxemin dəyişməsini və serializasiya tələblərini yenə də qiymətləndirmək la­zım­dır.

JEP 540-ın möv­cud, yetkin kitabxanalardan av­to­ma­tik ola­raq daha sü­rət­li ol­du­ğu­nu fərz etmək olmaz.

12. Performans: daxili API Jackson-dan sürətlidirmi?

Tez-tez belə bir fikir səslənir:

"JSON emalı JDK-nın daxilindədirsə, müt­ləq daha sü­rət­li ol­ma­lı­dır."

Bu fərziyyə doğru deyil.

JDK-nın təqdim et­di­yi implementasiya av­to­ma­tik ola­raq kənar kitabxanadan daha sü­rət­li olmur.

Jackson illərlə optimallaşdırılıb və canlı sis­tem­lər­də is­ti­fa­də olunub.

Simple JSON API əsas əmə­liy­yat­lar üçün yığcam və anlaşılan API təqdim etməyə üs­tün­lük verir.

O, bütün JSON emalı iş yüklərində möv­cud həlləri əvəz edən universal, yüksək performanslı vasitə kimi hazırlanmayıb.

Performans testlərində nəyi ölçmək lazımdır?

Mənalı müqayisə üçün bunları ölçün:

1. Kiçik və orta ölçülü JSON sənədlərinin oxunmasında buraxılış qabiliyyəti.
2. Yaddaş ayırma sü­rə­ti və garbage collector üzərindəki yük.
3. p50, p95 və p99 persentillərində ge­cik­mə.
4. Serializasiyanın buraxılış qabiliyyəti.
5. Paralel iş yükləri za­ma­nı yaddaş is­ti­fa­də­si.
6. Dərin iç-içə strukturlar emal edilərkən performans.

Java mikrobençmarkları üçün JMH is­ti­fa­də edin və hər implementasiyanın eyni işi gördüyünə əmin olun.

Bir dəfə icra olunan testdən və ya System.nanoTime() ilə sadə vaxt müqayisəsindən yekun nə­ti­cə çıxarmayın.

JSON alətlərini JDK-ya daxil olub-olmamasına görə deyil, iş yükünüzün ölçmələrlə mü­əy­yən edilmiş tələblərinə görə seçin.

13. API-ni necə sınaqdan keçirmək olar?

JEP 540 inkubator modulu təqdim etdiyinə görə modulun istifadəsini açıq şə­kil­də gös­tər­mək la­zım­dır.

Bu imkanı ehtiva edən uyğun JDK 28 erkən sınaq yığımı ilə kompilyasiyanın ümumi forması be­lə­dir:

javac \
  --add-modules jdk.incubator.json \
  JsonExample.java

Tət­bi­qi başladın:

java \
  --add-modules jdk.incubator.json \
  JsonExample

Möv­cud modulları bu əmrlə yoxlaya bilərsiniz:

java --list-modules

Siyahıda bu modulu axtarın:

jdk.incubator.json

Modul seçilmiş JDK yığımında ol­ma­lı­dır.

Erkən sınaq API-lərini və on­la­rın dəqiq davranışını müvafiq yığımın sənədləşməsi əsa­sın­da yoxlamaq la­zım­dır.

Canlı sis­tem­lər üçün layihə hazırlayarkən nəzərə alın ki, inkubator modulları daimi uyğunluq təminatı vermir.

14. JEP 540 hansı problemləri həll etmir?

Məhdudiyyətləri anlamaq imkanları bilmək qədər va­cib­dir.

Obyektlərə avtomatik çevirmə yoxdur

Jackson-un readValue() metodunun daxili qarşılığı ilə mürəkkəb JSON sənədini istənilən Java domen obyektinə birbaşa deserializasiya edə bilməzsiniz.

Axın şəklində emal API-si yoxdur

Təklif yaddaşda saxlanan JSON sənədlərinə yönəlib.

O, sənədin strukturunu yaddaşda tam yaratmadan çox böyük JSON sənədlərini hissə-hissə emal etmək üçün nə­zər­də tutulmayıb.

JSON Schema yoxlaması yoxdur

API JSON sintaksisini emal edir, amma biz­nes tələblərini ifadə edən sxemləri yoxlamır.

Mə­sə­lən, ödə­niş məbləğinin müsbət olmasını və ya mü­əy­yən tət­biq müqaviləsinə əsasən hansısa sahənin məcburi olmasını av­to­ma­tik təmin etmir.

Tam freymvork inteqrasiyası yoxdur

API Spring Boot, Hibernate ilə əlaqəli alətlər və digər freymvorklardakı JSON inteqrasiyalarını av­to­ma­tik əvəz etmir.

API-nin uzunmüddətli sabitliyinə hələ təminat verilmir

İnkubator mərhələsində olduğu üçün onun açıq API-si dəyişə bilər.

Bunlar müt­ləq çatışmazlıq sayılmalı deyil. Əhatə dairəsi ilə bağlı məqsədli qərarlardır.

15. Canlı sistemdə istifadə etməyə dəyərmi?

Cavab tətbiqinizin tələblərindən ası­lı­dır.

Bu hal­lar­da JEP 540-ı sınaqdan keçirməyi düşünün:

• Kiçik, müstəqil Java aləti hazırlayırsınız.
• Yal­nız əsas JSON oxuma və ya yaratma əmə­liy­yat­la­rı­na ehtiyacınız var.
• Kənar asılılıqları azaltmaq istəyirsiniz.
• JSON sənədləriniz çox böyük deyil.
• JDK-nın gələcək imkanlarını qiymətləndirmək istəyirsiniz.

Bu hal­lar­da yetkin kitabxanalardan istifadəni davam etdirin:

• Tətbiqiniz DTO serializasiyasından geniş is­ti­fa­də edir.
• Spring Boot-un sorğu və ca­vab­la­rı av­to­ma­tik çevirmə imkanlarından is­ti­fa­də edirsiniz.
• Çox böyük JSON axınlarını emal edirsiniz.
• Təkmil annotasiyalara və ya fərdiləşdirməyə ehtiyacınız var.
• Ekosistemlə yetkin inteqrasiyalar tələb olu­nur.
• Uyğunluq gözləntiləri aydın olan sabit API-lərə ehtiyacınız var.

Kritik canlı tətbiqlərdə təkcə API-nin inkubator mərhələsində olması ehtiyatlı yanaşmaq üçün ciddi səbəbdir.

Daha geniş istifadəyə keçməzdən əvvəl API-ni daxili alətlərdə, eksperimentlərdə və ya təcrid olunmuş komponentlərdə qiymətləndirmək məntiqli yanaşmadır.

16. Daha geniş baxış: bu, Java üçün niyə əhəmiyyətlidir?

JEP 540 Java-nın inkişafında daha geniş bir istiqaməti gös­tə­rir.

Platforma uyğunluğu, per­for­man­sı və kodun uzun müd­dət rahat saxlanmasını nəzərə alaraq proqramçıların işini asanlaşdırmağa davam edir.

Daxili JSON API gündəlik tapşırıqları, xüsusilə böyük tət­biq freymvorklarından kənarda, asanlaşdıra bilər.

Həmçinin sadə JSON əmə­liy­yat­la­rı­na ehtiyac ol­duq­da proqramçıların arxalana bi­lə­cə­yi ortaq baza ya­ra­dır.

Amma standartlaşdırma bütün ixtisaslaşmış kitabxanaların lazımsız olması demək deyil.

Java artıq JDK daxilində şə­bə­kə, kolleksiyalar, paralel icra və kriptoqrafiya API-ləri təqdim edir.

Tələblər daxili imkanları aşanda proqramçılar yenə də ixtisaslaşmış kitabxana və freymvorklardan is­ti­fa­də edirlər.

JSON emalı da eyni modelə uyğun inkişaf edə bilər.

Əsas əmə­liy­yat­lar üçün kiçik standart API.

Daha mürəkkəb tələblər üçün ixtisaslaşmış kitabxanalar.

Bu, praktik tarazlıqdır.

Yekun fikirlər

Java 28-in Simple JSON API-si Java ekosisteminə əhəmiyyətli əlavədir.

Gündəlik JSON emalı üçün sadə API-ni birbaşa JDK-da təqdim etməklə uzun müddətdir möv­cud olan boşluğu doldurur.

Buradan çıxan əsas nə­ti­cə Jackson və ya Gson-un yox olacağı deyil.

Əsas məqam budur ki, Java proqramçılarının daha bir seçimi olacaq: əsas JSON oxuma, strukturda hərəkət və sənəd yaratma əməliyyatları üçün kənar JSON kitabxanası tələb etməyən seçim.

Backend mühəndisi üçün bu API-nin harada uyğun ol­du­ğu­nu anlamaq onu sa­də­cə yeni olduğu üçün is­ti­fa­də etməkdən daha faydalıdır.

Həll et­di­yi­niz problemə uyğun alət seçin.

JEP 540-ın inkişafını da iz­lə­yin.

Əlavə oxu materialları

• JEP 540: Sadə JSON API (inkubator mərhələsi)
• OpenJDK
• Java 28-in erkən sınaq yığımları
• RFC 8259: JSON məlumat mübadiləsi formatı

Proxy Academy ilə öyrənməyə davam edin

proxy-academy.com saytında Java, backend proq­ram­laş­dır­ma, sis­tem di­zay­nı və canlı sistemlərə uyğun proqram arxitekturasını öyrənin.

Müzakirə: Kiçik servislərdə Java-nın daxili JSON API-sindən is­ti­fa­də edərdiniz, yoxsa Jackson ilə davam edərdiniz?