Proč se k tématu vracet i v roce 2026
Licencování Oracle Java se v posledních letech posunulo směrem k jednoduššímu, ale pro mnoho organizací dražšímu modelu. Pro management je atraktivní „jedna metrika“, pro IT a nákup to ale často znamená potřebu detailního mapování instalací a způsobu použití.
Co se typicky láme v praxi
- Neúplný inventář: organizace eviduje jen servery, ale chybí desktopy, CI/CD agenty, jump servery a bastiony.
- Nejasný vendor/VM vendor: v prostředí zůstávají různé buildy (Oracle, OpenJDK, Azul, Adoptium) bez centrální správy.
- Shadow IT: lokální instalace v týmech mimo standardní SW distribution.
- Chybějící důkazy: i když je Java odinstalovaná, chybí auditní stopa.
Doporučený postup (prakticky, bez teorie)
- Rychlý screening (1–2 týdny): sběr dat z endpoint managementu, SCCM/Intune/Jamf, server inventory, cloud VM listing.
- Normalizace verzí: sjednotit identifikaci major/minor/update a vendorů.
- Klasifikace použití: desktop vs server, runtime vs development, build agent vs production.
- Riziková mapa: kde běží Oracle JDK, jaké verze, kdo je vlastníkem.
- Rozhodnutí o strategii:
- standardizace na OpenJDK/Temurin,
- enterprise build (např. Azul) s podporou,
- nebo řízený nákup Oracle licencí v rozsahu, který je obhajitelný.
Co si připravit pro auditní odolnost
- Evidence instalací + časové razítko (kdy bylo zjištěno).
- Evidence odinstalací + logy/změnové lístky.
- Definovaná politika: kdo smí instalovat Oracle JDK a jak se schvaluje výjimka.
Kdy dává smysl migrace na Azul
Pokud chcete:
- snížit licenční nejistotu a auditní stres,
- mít enterprise podporu a SLA,
- zachovat kompatibilitu bez zásahů do kódu, pak je migrace na Azul typicky rychlá a nízkoriziková.
Chcete rychlé vyhodnocení rizik ve vašem prostředí? Ozvěte se přes kontaktní formulář.