Oblac

Multi-Release JARs

Sa Javom 9 dolazi i Multi-Release JAR Files specifikacija. Reč je o dodatnoj osobini JAR fajlova da podržavaju klase namenjene različitim verzijama Java platforme.

Primer strukture MRJAR-a je dovoljan za razumevanje ove specifikacije:

Foo.class
Bar.class
/META-INF
    /versions
        /9
            /Bar.class

Kada se ovakav jar koristi na JDK koji nema podršku za MRJAR fajlove, sve će raditi na uobičajeni način: videće se samo klase u korenu arhive.

Kada se MRJAR koristi na novijem JDK (od verzije 9), dozvoljena je zamena bilo koje klase njenom novom varijantom - koja koristi nove i naprednije funkcionalnosti platforme nedostupne u prethodnim verzijama JDK. U našem primeru, klasa Bar biva zamenjena kada se ovakav MRJAR koristi na JDK 9.

Priprema

Da bi napravili MRJAR, prvo se mora “uključiti” ova osobina u MANIFEST.MF:

Multi-Release: true

Nakon toga, u suštini, potrebno je:

Nažalost, nisam našao lak način da sve ovo ostvarim i automatizujem (još uvek). Za početak, jedan Gradle sub-modul se još uvek ne može tek tako kompajlirati različitim verzijama Jave. Zato sam Java 9 varijantu prosto smestio u zaseban projekat koji se kompajlira nezavisno. Imao sam sreće jer klase od interesa nisu zavisile od ostalih, tako da je bilo dovoljno kompajlirati ih zasebno. Prebacivanje klasa na odgovarajuću lokaciju je izvršena jednostavnim linkovanjem output foldera. Prvo se kompajlira Java 9 varijanta, pa tek onda Java 8.

Falinka

Ideja iza MRJAR-ova je zasita smislena. Jasno, postoji očigledan izazov održavanja ovakvog code base-a; ne postoji nikakva provera da li su varijante iste klase zaista zamenjive. Iapk, ovaj problem je očekivan i važi za sve slične multi-release specifikacije.

Drugi problem je konceptualan i mnogo važniji: MRJAR-ovi rade samo ako su… jarovi. Drugim rečima, ukoliko je sadržaj MRJAR-a exploded (t.j. raspakovan), on neće raditi.

Zašto je to problem?

Svakodnevni rad sa kodom se dešava u exploded modu: artifakti, kao što su jarovi, se pripremaju tek kasnije, pre objavljivanja koda. Testovi se takođe izvršavaju pre ikakve pripreme artifakta.

Čekaj… testovi?

Da. Da ponovim još jednom ako to nije jasno: testovi koji zavise od implentacije na različitim platformama Jave neće raditi. Ne mogu da se pokrenu iz IDE-a, a neće raditi ni na CI serveru.

O Orakle, otkuda ovo?

Biću pomalo grub: ovaj primer specifikacije (koji se kuva još od 2014.) je dobra ilustracija nemaštovitosti kompanije koja je preuzela razvoj Jave.

bug report