A Java jövője: Mikre érdemes várni

2021.03.26. · 5 perc olvasás

Kevesebb mint egy hónapon belül érkezik a Java legújabb fejlesztői csomagja, így az már a 16-os verziónál fog tartani, azonban hála az Oracle nem rég bevezetett verzió frissítési ritmusának a 17-es verzió is a látóhatáron van.

Ez utóbbi már csak azért is érdekes, hiszen a Java 17-es lesz a következő LTS (long-term support) verzió, ami így a Java 11-et váltja ezen a pozíción.

Az Oracle ez elmúlt pár évben elhivatottnak látszik, hogy ledolgozza azt a lemaradást, amit a Java a 8-as verzió óta összeszedett – nem kevés részben a visszafele kompatibilitás szavatolása miatt. Ennek a leglátványosabb példája az újragondolt verzió frissítési ritmus, aminek köszönhetően félévenként érkezik új JDK. Természetesen a gyakori frissítés önmagában még nagyon kevés lenne a boldogsághoz, főleg, ha azokat az Oracle képtelen lenne valós tartalommal megtölteni. Ezekben a csomagokban azonban sok olyan adalék is megjelenik, amiknek a hiánya már régóta fájó pont volt a fejlesztőknek. Ezek az újdonságok pedig négy nagyobb projekt (Amber, a Panama, a Loom és a Valhalla) alá esnek, amik a következő pár évben teljesülnek ki az elkövetkező JDK-kban. Az Oracle ígérete szerint ezek hivatottak szavatolni, hogy a Java nyelv visszanyerje modern imázsát.

Project Panama

A Panama nem kevesebbet ígér, mint hogy gazdagítja és elsősorban javítja a JVM (Java virtual machine) és a natív kód közti kapcsolatot. Vagy ahogy ők fogalmaznak “azt a kapcsolatot, ami a JVM és az idegen nyelvekben jól definiált API-k, valamint azon interfészek közt, létezik, amiket C programozók használnak”.

A Project Panama egy korai változata már 2018-ban bekerült a Java-ba, azonban ezt mindössze csak ismerkedésre és tesztelésre ajánlják, újabb verzió pedig a 2021 végén érkezik belőle, amire az az ígéret, hogy közel teljes funkcionalitással fog rendelkezni.

Project Loom

A Loom talán a legjobban várt a négy közül. A Java-t régóta érik támadások, hogy a szálkezelést és alapvetően a konkurens feladatok megoldását nem könnyíti meg az ilyesmivel próbálkozó programozóknak. A Loom célja, hogy a JVM funkcióinak kiterjesztésével és ezek felé ültetett API-k létrehozásával, inkubálásával hozzon létre könnyen használható, nagy áteresztőképességű, könnyű egyidejűséget biztosító új programozási modelleket.

A Project Loom is létezik már, mint early-access build, de végleges és így használható verziót a 17-es JDK-ban kap majd.

Projet Valhalla

A Valhalla legérdekesebb újítása minden bizonnyal a primitívek és az sima objektumok mellé bevezetendő ValueType. A mindennapi kódolás szempontjából a ValueType-ok és a megszokott objektumok közt nem lesz észrevehető különbség, azonban a háttérben a ValueTypok mégsem objektumokként, hanem sokkal inkább primitívekként fognak viselkedni. Röviden tehát: jóval effektívebben lehet majd őket használni, mint a sima objektumokat. Az igencsak hangzatos szlogen szerint a Valhalla lehetővé teszi, hogy: „kódold, mint egy osztályt, használd, mint egy intet” alkalmazását.

Ez annak köszönhető, hogy a ValueType nem rendelkezik se object headerrel se saját identitása nincs, így természetesen referencia sem kapcsolódik hozzá. A ValuType-ok továbbá képtelenek lesznek öröklődni egymástól, tehát a poliformizmus is kiesik a képből. Mindezekre azért van szükség, mert az értékek az objektumokkal ellentétben nem a heap-ben, hanem a változóban tárolódnak – így a complier egyből fogja tudni a típust, ahogy egy int esetében is, aminek következtében egyből fogja tudni, hogy hogyan dolgozza fel.

A ValueType használata a jelenlegi állás szerint a következő lesz:

final __ByValue class Point {
    public final int x;
    public final int y;

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

    public boolean equals( Point other ) {
        return this.x == other.x && this.y == other.y;
    }

    private Point() {
        this.x = 0;
        this.y = 0;
    }

    public static Point of( int x, int y ) {
        Point v = __MakeDefault Point();
        v = __WithField( v.x , x );
        v = __WithField( v.y, y );
        return v;
    }  
}

Jól látható, hogy az osztály deklarációja elé __ByValue helyezésével tudatjuk, hogy az új típust kívánjuk használni, majd példányosításánál nem a new szócskát, hanem a __WithField kifejezést kell majd használni.

Project Amber

Az Amber egy kicsit kilóg a sorból, ugyanis nem egy jól megfogható cél köré épül, hanem több kisebb újítást foglal magába. Ezek közt már van olyan, ami teljes funkcionalitással elérhető, mint a 12-es JDK óta Preview módban elérhető switch expression (switch kifejezés) vagy a JDK 13 óta elérhető Text Blocks.

Azonban jócskán van még potenciál a projektben. A legfontosabb újítása a JDK 14-óta, mint Preview létező Pattern Matching, ami sajons csak több részletben fog teljesen bevezetésre kerülni. Egyelőre csak az instanceof operátor részére lesz elérhető. Ez elsőre nem tűnik nagy előre lépésnek, de valójában nagy mértékben javítja már ez is a kód olvashatóságát, mivel megszünteti az instanceof utáni kényszeres kasztolást.

Így tehát ez:

    if (obj instanceof String) {
        String s = (String) obj;
        // use s
    }

a jövőben leírható lesz mindössze annyival, hogy:

    if (obj instanceof String s) {
        // can use s here
    } else {
        // can't use s here
    }

Ennek a négy projektnek egyértelmű célja, hogy a Java-t visszavezessék a modern nyelvek közé. Nem állítjuk, hogy ennyi önmagában elegendő lesz, de a szándék jól látható, és ami még ennél is jobb, hogy a szándékot tettek is követik.

A bejegyzés természetesen nem kívánt minden apró részlettel külön foglalkozni, sőt még a négy projektet is csak távoli perspektívából mutatja be. A részletekbe való elmerülést pedig külön posztokban tesszük meg.