Novinky v balíčcích OpenJDK

OpenJDK je jeden z největších (ne-li úplně největší hned po kernelu) open-source projekt. Jako takový se vyvíjí velmi pomalu a stejně tak pomalu se vyvíjejí jeho balíčky. Přesto se krom běžného udržování a (bezpečnostního) záplatování dočkaly balíčky OpenJDK ve Fedoře několika výrazných změn.

OpenJDK8 - F19

Pouze pro úplnost, úplně první JDK ve Fedorce byla GNU classpath a její gcj a gij. [1]
GCJ – nástup F7, odstraněno (!!!) F20
JDK6 – nástup F11, odstraněno F17
Extrakce java pluginu a javaws do projektu IcedTea-Web – F15 [1.5]
JDK7 – techpreview F16, nástup F17, odstraněno F21
JDK8 - techpreview F19+F20, hlavní JDK od F21 do teď
OpenJDK má tendenci se stát techpreview +- půlrok kolem data vydání (OpenJDK9 by mělo vyjít v březnu 2017, čili je ještě čas [2] ) a o Fedorku dvě později se stává hlavním JDK. Předchozí JDK je odstraněno. Ale o tom níže.
Takže ano, již od F20 je vaším JDK OpenJDK8, to kdybyste to náhodou přehlédli :).

Multiple JDKs – F18 [3]

Multiple JDKs je velmi kontroverzní vlastnost. Prapůvodní myšlenka byla umožnit mít na jednom stroji jak stabilní balíčky, tak balíčky s experimentálními fixy. To vše jednoduchým trikem, instalovat javu vždy do nového adresáře NVRA (jméno-verze-vydání-architektura (ano, java má funkční multilib)). Ovšem celá vychytávka se začala kroutit, když jsme zjistili, že rpm ani yum nám nejsou schopni pomoci a nakonec se úplně zvrtla v podobě bugu [5] .

Nicméně se ukázalo, že RHEL i Fedora slouží mnoha vývojářům samotné javy (neplést s vývojáři v javě) a tato funkcionalita je pro ně návyková. Takže jsme zabojovali a kousek logiky rpm připsali v lue [6] . To se nakonec vyvrbylo v nový balíček copy-jdk-configs [7] , a i když se to celé jednou za čas kousne, obecně to dělá návrh balíčku jednodušší a javu užitečnější. Zvláště v okamžiku, kdy mohly nastoupit -debug podbalíčky (viz níže).

Headless support – F20 [4]

Java, zvláště pokud je použita na serveru nebo v X-less systému (například buildící systém pro Fedoru Koji[16] ), má podporu běžet bez jakékoliv vizuální integrace. To v rámci OpenJDK dělá i se závislostmi něco kolem 150 MB. Čili java rozdělila své jre na jre a jre-headless. A celá Fedorka prošla masovým patchováním, kdy co mohlo, přešlo na requires java-headless. I když pro běžného uživatele javy se nic moc nezměnilo, věřte, že Koji i různým domácím serverům se výrazně ulehčilo.

Debug subpackages – F21

Jak jsem zmínil, Fedora i RHEL jsou využívané vývojáři platformy java. Vývoj javy je jako každý jiný - samý bug a následný fix s novým bugem. A debugovat něco tak kolosálního vyžaduje spoustu build-in debugovacích vychytávek přímo v platformě. Bohužel, tyto vychytávky pak ve finálním buildu chybí. Proto vznikly debug balíčky.

V případě, že se objevila nějaká opravdu vážná chyba, která se navíc nedá reprodukovat mimo cílové místo, musel vývojářjavy na cílovém místě znovu sestavit OpenJDK s plným debugem (s tím, že v případě znovu sestavení zde byl již risk špatnéverze či závislosti) a teprve pak debugovat. Nyní mu stačí nainstalovat -debug podbalíčky, v alternatives přepnout a může vesele zkoumat. Navíc tyto balíčky byly sestaveny ve stejném buildrootu, ze stejné verze, se stejnými patchi jako postižené JDK, takže má jistotu identity.

Jen pro úplnost -debug balíčky jsou:

java-1.8.0-openjdk-headless-debug
java-1.8.0-openjdk-debug
java-1.8.0-openjdk-devel-debug
...

vedle běžných

java-1.8.0-openjdk-headless
java-1.8.0-openjdk
java-1.8.0-openjdk-devel
…

Nikoliv java-1.8.0-openjdk-debuginfo. Debuginfo zůstává tradiční se stejným užitím. Bohužel, debuginfo je nyní dvojnásob veliké, neboť jej sdílejí jak normální, tak debug balíčky.

Legacy JDKs – F22

Po nástupu JDK8 jako hlavního JDK se spoustě lidem zastesklo po JDK7. Prostě jen tak, že sami vyvíjejí aplikaci pro cílové JDK7 a tak proč se trápit případnými bugy po přenosu.

Prachybou, která tuto otázku otevřela, byla https://bugzilla.redhat.com/show_bug.cgi?id=1190137 – již ve Fedoře 21 - „Cannot install java-1.7.0-openjdk on a system with java-1.8.0-openjdk using yum”. Tato chyba vyústila v sadu pravidel a byla přednesena jako Systémová změna -https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora.

Tato změna však nikdy nebyla schválena, a lidé kolem balíčku nemají sílu podporovat více než jedno hlavní JDK (pro šťourali – každé 3 měsíce dochází k velké bezpečnostní aktualizaci a udělat tuto aktualizaci správně, rychle a další dva měsíce spravovat co rozbila… je opravdu těžké. Jedno JDK je až až). Takže se úkolu chopila komunita, jmenovitě mistr Julius Schwartzenberg. Ten vzal z výše uvedené systémové změny co šlo, drží krok s lidmi okolo hlavního JDK a udržuje svoje copr repositáře s neoficiálními javami:

OpenJDK 6 : https://copr.fedorainfracloud.org/coprs/jschwart/openjdk-6/
OpenJDK 7 : https://copr.fedorainfracloud.org/coprs/jschwart/openjdk-7/
OpenJDK 9 : https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/

Udržuje je synchronizací s CentOS 7 a světe div se, ono to skvěle funguje.
Podobný přístup má nyní i OpenJDK9 – viz poslední repo vukázce výše.

--family - F23

V okamžiku, kdy je nainstalováno více než jedno (velké, např 1.7.0 a zároveň 1.8.0) JDK a zároveň více než jedna verze odjednotlivých „velkých“ JDK, zůstává otázka, co nastavit jako hlavní JDK po aktualizaci. Odpověď je jednoduchá –aktualizovanou verzi toho JDK, které má uživatel nastaveno. Ovšem implementace samotná už jednoduchá není. Naštěstí nám chlapci z chkconfig (který vlastní program alternatives) vyšli vstříc [8] a přidali přepínač --family, který přesně toto dělá. Pokud je manuálně nastaven nějaký master, který je „v rodině“, pak aktualizace zůstává v rodině (pokud rodina stále existuje).

Shenandoah [9] – F24

Shenandoah je nový garbage collector [10] pro OpenJDK. Je vysoce paralelní a tak ho ocení hlavně lidé na mnoho procesorových strojích s 10 GB a více paměti, alokované pro javu. Na slabších strojích je jeho výkon +- stejný jako současný garbage collector. Do Fedorky míří jako SelfContainedChange [11] a minimálně ze začátku se bude zapínat na přání pomocí -XX:+UseShenandoahGC. Zda-li se časem zapne jako primární zatím není zřejmé, ale při pozorování chování tohoto GC je zřejmé, že kromě vědeckých výpočtů či simulací a serverových aplikací ho ocení už třeba hráči Minecraftu...

aarch32 template interpreter [12] a JIT [13] – F24 (f25?)

Fedora má tři primární architektury - 32b Intel, 64b Intel a nejmladší 32b ARM. Je sice pěkné moci rozběhnout Fedorku na libovolném tabletu nebo telefonu, ale zároveň tím utrpěly buildery. Pokud packager vydává aktualizaci, musí se sestavit na všech primárních architekturách. A ať se nám to líbí nebo ne, ARM32 je mnohem pomalejší, než Intel. Čili balíček se buildí, Intely jsou hotové a packager čeká, čeká a čeká, až skončí ARM32. V případě balíčků napsaných v jazyce java je rozdíl ještě markantnější – OpenJDK pro ARM32 totiž nemá ani Template Interpreter [12] ani JIT [13].

Zde si dovolím malou technickou vložku: java ve svých prapočátcích byla interpretovaný jazyk. A její rychlost byla velmi velmi nedostačující. Proto inženýři ze Sunu přišli s mechanismem, který kusy bajtkódu v paměti nahradí kusy instrukcí pro danou architekturu. Toto je ovšem velmi náročné na naprogramování, neboť je třeba napsat mapování bytecode->assembler pro každou architekturu procesoru. Pak navíc udržovat a odlaďovat. Proto byl první sunovský Template Interpreter pouze pro Intel. Jen o málo později bylo zřejmé, že samotný Template Interpreter nebude stačit a proto vznikl JIT. JIT bere sekvenci bytekódu a nejen, že ji přeloží do assembleru, ale navíc ji (výrazně) optimalizuje. V postupu staletí se ukázalo, že by bylo fajn mít podobné zrychlení na všech architekturách. Ale napsat Interpreter pro všechny architektury je prostě oříšek. Proto vznikl Zero. Zjednodušeně řečeno, Zero nahrazuje kusy bajtkódu kusy C kódu. Běží to všude, běží to dobře, ale je to pořád mnohem pomalejší, než „kusy assembleru“ a navíc JIT pro Zero (Shark) je již dlouho (od uvedení lambda výrazů) nefunkční. Takže to celé za rychlostí běhu na Intelu opravdu zaostává.

Pokud je architektura perspektivní, je snaha přidat další nativní implementace. RedHat přidal ARM64, IBM přidalo ppc64le, Oracle má svůj proprietární, uzavřený ARM32. A uzavřený - navíc nijak neoslňující rychlostí - je kámen úrazu. Chlapíci z Azul systems už toho měli dost a začali s otevřenou implementací pro ARM32. V současnosti mají opravdu hotový funkční ARM32 template interpreter a v brzké době slibují i JIT!

Proto bychom rádi do Fedory dostali pouze ARM32 balíček, který bude obsahovat javu s tímto technickým klenotem. Balíček je zatím na review - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 - bude přidán jako nový balíček. Jako takový zatím vůbec neposkytuje javu, je opravdu příliš čerstvý. Časem ji ale poskytovat bude a pak čeká všechny ARM32 buildery Fedory rychlostní revoluce.

compressed javadoc – F25 (24?)

Javadoc je dobrý. Vlastně každý doc (pydoc, perldoc…) založený na dokumentaci z kódu je dobrý. Ovšemjejich užitečnost mimo internet (a google), tedy zejména na lokálním disku, pokulhává.

Nicméně užití lokální docy občas mají a navíc, Fedora je krásně podporuje. Ale… jistě jste si někdy všimli něčeho jako:

Installing:
java-1.7.0-openjdk-legacy-javadoc noarch 14 M

Transaction Summary
====================================================================================================================
Install 1 Package

Total download size: 14 M
Installed size: 232 M

To není halucinace. Texty mají obecně nejúčinnější kompresi a html tuplem, neboť jednotlivé značky odejdou do slovníků ještě spíše. Čili ano, máte doc se sporadickou užitečností a zabírá o 200 MB víc než by měl. Navíc rozumné nástroje pro práci s dokumentací umí pracovat s docy v archivu, jmenovitě zipu (adresářová struktura tolik potřebná v docích je v zipu přirozeností (na rozdíl např. od gz)). Takže OpenJDK balíčky konečně vyslyšely dlouholeté volání, propasíroval jsem se s upstreamem [14] a největší mně známý javadoc konečně přichází v podbalíčku, kde i po instalaci zůstane zazipován [15].

Future

Co nás čeká v nejbližší budoucnosti? Co se týče té úplně nejbližší, tak Shenandoah, ARM32 JIT a zazipovaný javadoc je hádám až až. Také JDK9 je již dostupné v kopr repozitářích:

$cat /etc/yum.repos.d/alternativeJvms.repo
...
[omajid-openjdk9]
name=Copr repo for openjdk9 owned by omajid
baseurl=https://copr-be.cloud.fedoraproject.org/results/omajid/openjdk9/fedora-$releasever-$basearch/
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/omajid/openjdk9/pubkey.gpg
enabled=1

OpenJDK9 má vyjít až v březnu 2017 [2], takže myslím, že dříve než v F26 se opravdu neobjeví. OpenJDK7 bylo tech preview rok - a změny v něm byly minimální. OpenJDK8 pak půl roku, ačkoliv změn bylo více (Oracle zaškrtil atualizace JDK7 o něco dříve). Takže se dá předpokládat, že JDK9 bude hlavní JDK nejdříve v F28.

Pozor! JDK9 je pořád velmi živé a pokud budete používat jakékoliv balíčky z kopru, nezapomeňte je odstranit v okamžiku aktualizace na Fedoru, která již bude JDK9 obsahovat.

Poslední (snad) změnou která přijde s JDK9 je změna názvu balíčku. Název se zjednoduší (pravděpodobně, je to daleká budoucnost) na java-9-openjdk*.

Linky

[1]http://pkgs.fedoraproject.org/cgit/rpms/java-1.5.0-gcj.git/tree/?h=f7

http://pkgs.fedoraproject.org/cgit/rpms/java-1.5.0-gcj.git/tree/?h=f19

http://pkgs.fedoraproject.org/cgit/rpms/java-1.5.0-gcj.git/tree/?h=master

http://pkgs.fedoraproject.org/cgit/rpms/java-1.6.0-openjdk.git/tree/?h=f11

http://pkgs.fedoraproject.org/cgit/rpms/java-1.6.0-openjdk.git/tree/?h=f16

http://pkgs.fedoraproject.org/cgit/rpms/java-1.6.0-openjdk.git/tree/?h=master

http://pkgs.fedoraproject.org/cgit/rpms/java-1.7.0-openjdk.git/tree/?h=f16

http://pkgs.fedoraproject.org/cgit/rpms/java-1.7.0-openjdk.git/tree/?h=f17

http://pkgs.fedoraproject.org/cgit/rpms/java-1.7.0-openjdk.git/tree/?h=f20

http://pkgs.fedoraproject.org/cgit/rpms/java-1.7.0-openjdk.git/tree/?h=master