Java-päivitykset tuntuvat harvoin kiireellisiltä, ennen kuin yhteistyökumppanin SDK, tietoturvapäivitys tai kehys pakottaakin yllättäen toimimaan. Tässä oppaassa kerromme, milloin päivitys kannattaisi tehdä, miten riskit pidetään kurissa ja mitä kysymyksiä tiimille kannattaa esittää, jotta päivitykset eivät enää jarrutaisi kehityssuunnitelmianne.
Java julkaistaan kuuden kuukauden sykleissä. Toimittajat nimeävät tietyt versiot pitkän tuen (LTS) julkaisuiksi. Ekosysteemit rakentuvat näiden LTS-linjojen ympärille, mikä tarkoittaa parempaa tietoturvakattavuutta, sujuvampia SDK-integraatioita ja helpompaa rekrytointia. Liian vanhoissa versioissa pidättyminen myös estää tai vaikeuttaa tekoälyn käyttöönottoa, koska pilvipohjaiset AI SDK:t ja turvalliset suoratoistoratkaisut kohdistuvat nykyisiin Java LTS -tasoihin.
Vanhoissa versioissa pysyminen näyttää aluksi edulliselta, kunnes se johtaa julkaisujen viivästymiseen tai auditoinnissa havaittuihin puutteisiin. Ratkaisu ei ole yksittäinen pelastusprojekti, vaan säännöllinen päivityskäytäntö.
Jos jokin vastaus on epäselvä, korjatkaa se ensin. Tämä vähentää myöhemmin syntyviä kustannuksia ja ongelmia.
Pyrkikää käyttämään toimittajan nykyistä LTS-versiota, ellei siihen ole selkeitä esteitä. Testatkaa toteutustapa lyhyellä kokeilulla. Joskus JVM:n on muututtava ensin, toisinaan taas kehyksen. Päättäkää järjestys faktojen pohjalta, älkää arvailujen varassa, ja kirjatkaa se muistiin. Pitäkää tiimin huomio keskittyneenä muutamaan lyhyeseen kehityssykliin yhden suuren harppauksen sijaan.
Suorittakaa ensin pieni pilottiprojekti ja ottakaa toiminnot käyttöön vaiheittain. Seuratkaa asiakaskäyttöön liittyviä mittareita ja laajentakaa käyttöä vasta sitten, kun tulokset ovat positiivisia. Kun kyseessä on tietokantamuutokset, käyttäkää suunnitelmaa, jossa vanha ja uusi koodi voivat toimia rinnakkain, kunnes tiedot on siirretty turvallisesti. Suhtautukaa ”palautukseen” realistisesti. Kun tiedot muuttuvat, siirtyminen turvalliseen tilanteeseen on usein se ainoa järkevä vaihtoehto.
Siitä lähtien, kun Java siirtyi kuuden kuukauden julkaisuväliin, näiden välijulkaisujen elinkaari on ollut lyhyt ja niiden päivitykset on lopetettu nopeasti. Käytännössä tiimit valitsevat toimittajien pitkäaikaisen tuen (LTS) versioita, koska juuri niissä tietoturvakorjaukset, kumppanien SDK:t ja työkalut yhdistyvät. Siksi tämä opas keskittyy juuri nykyisiin sekä viimeaikaisiin LTS-julkaisuihin, ja käsittelee muita kuin LTS-versioita vain väliaikaisena vaiheena matkalla kohti LTS-versiota.
Java 25 (LTS) – yleinen saatavuus syyskuussa 2025
Paras oletusvalinta uusille palveluille ja päivityksille. Saat pisimmän tukijakson ekosysteemin kattavimman tuen. Useimmat suuret alustat joko tukevat jo versiota 25 tai ovat siirtymässä siihen piakkoin. Pysymällä tässä versiossa olet oikeutettu uusimpiin APM-agentteihin, konttikuviin ja kumppanien SDK-paketteihin, kun ne päivittävät perustasonsa.
Miksi tällä on merkitystä: vähemmän ”JVM:n estämiä” yllätyksiä, nopeammat kumppani-integraatiot sekä vähemmän uudelleen työstämistä, kun kehysrakenteet ottavat käyttöön vain versiossa 25 olevia ominaisuuksia.
Java 21 (LTS) – yleinen saatavuus syyskuussa 2023
Edelleenkin vankka perusta ja turvallinen välivaihe. Versio 21 tuo mukanaan virtuaaliset säikeet, joiden ansiosta monet ”thread-per-request” -palvelut voivat skaalautua pienemmillä resurssikustannuksilla. Tästä syystä Spring Boot 3.2+ ja muut kehysrakenteet ottivat version 21 nopeasti käyttöönsä. Jotkut toimittajat ovat alkaneet merkitä uusille SDK-paketeille ja APM-agenteille suosituksen, kuten ”21+ suositeltava”.
Viivyttelyb riskit: yhä useammat kirjastot optimoidaan ensin 25:lle, ja tukenne päättyy aiemmin, mikä lyhentää suunnitteluajanjaksoanne.
Java 17 (LTS) – yleisesti saatavilla syyskuussa 2021
Tuettu edelleen, mutta käyttöönotto vaikeutuu. Spring Framework 6 / Spring Boot 3.x, Micronaut 4, Quarkus 3 ja Jakarta EE 11edellyttävät kaikki Java 17:ää tai uudempaa versiota. Voitte käyttää niitä, mutta menetätte yli 21 parannusta ja näette enemmän ”vaatii 21+” -huomautuksia SDK:issa, tietoturva-agenteissa ja rakennuslaajennuksissa.
Miksi tällä on merkitystä: tulette viettämään enemmän aikaa vanhojen laajennusversioiden kiinnittämiseen sekä heikompien tietoturvastandardien hyväksymiseen, ja joudutte selittelemään kumppaneillenne, miksi heidän uusin SDK:nsa ei toimi.
Java 11 (LTS) – yleisesti saatavilla syyskuussa 2018
Tämä alkaa jo vanhentua. Monet työkaluketjut edellyttävät uudempia bytecode-versioita, uudempia TLS-oletusasetuksia sekä konttien peruskuvia, jotka on suunnattu versioille 17 tai 21 ja uudemmille. Java 11:n käyttö tarkoittaa usein Spring Boot 2.x -versioiden jäädyttämistä ja pääsyn menettämistä nykyisiin tietoturvapäivityksiin ja suorituskykyparannuksiin.
Miksi tällä on merkitystä: suuremmat ongelmariskit, hitaammat julkaisut, kiertoratkaisujen ylläpitokustannusten nousu.
Java 8 ja vanhemmat versiot
Suuri riski ja korkeat kustannukset. Teidän on vaihdettava kirjastoja ja laajennuksia, noudatettava tiukempia salaus- ja TLS-käytäntöjä sekä tehtävä muutoksia peruskuvaan. Jotkut toimittajat tarjoavat edelleen turvallisuuskorjauksia vanhemmille versioille, mutta ekosysteemin kehitys on jo siirtynyt eteenpäin.
Miksi tällä on merkitystä: osaajien ja kumppaneiden kanssa syntyy yhä enemmän kitkaa, auditoinnit kiristyvät ja päivityksen laajuus kasvaa sitä mukaa, mitä kauemmin odotatte.
Kun tiimit sanovat, että ”emme voi ottaa tekoälyä käyttöön”, kyse on usein JVM:n ja SDK:n yhteensopimattomuudesta (ja toisinaan TLS:n, HTTP2:n tai gRPC:n aiheuttamista ongelmista), ei niinkään tuotteen rajoituksista. Tässä on käytännönläheinen, versioittain eritelty katsaus OpenAI:hin/Azure OpenAI:hin, AWS Bedrockiin/SageMakeriin ja Google Vertex AI:hin.
Yhteenvetona voidaan todeta, että suurin osa tekoälyyn tarkoitetuista Java-SDK-paketeista toimii Java 8:ssa tai uudemmissa versioissa, mutta Java 17:ssä, 21:ssä ja 25 :ssä vältätte paremmin turvallisuus-, HTTP2- ja gRPC-ongelmia ja saatte arempia esimerkkejä ja työkaluja käyttöönne – joita kehysympäristönne edellyttävät muutenkin yhä useammin.
Java 25 (LTS) – Green.
Tämä on paras oletusvalinta uusille tekoälyominaisuuksille. Selkein reitti nykyaikaiseen TLS:ään, HTTP/2:een, gRPC:hen ja konttikuviin; SDK:t ja esimerkit keskittyvät ensisijaisesti tähän versioon.
Java 21 (LTS) – Vihreä.
Täysin yhteensopiva kaikkien tärkeimpien tekoäly-SDK:iden kanssa. Kehysrakenteet, APM-agentit ja rakennuslaajennukset tukevat aktiivisesti versiota 21; voitte hyödyntää virtuaalisia säikeitä silloin, kun ne ovat hyödyllisiä chat- tai suoratoistopalvelinten taustaprosesseissa.
Java 17 (LTS) – Vihreä → Keltainen ajan myötä.
SDK:t toimivat, mutta yhä useammat kirjastot ja esimerkit edellyttävät versiota 21 tai 25. Lisäksi suosittuja palvelinkehysrakenteita, joissa käytetään tekoälyportteja (Spring Boot 3.x jne.), vaaditaan jo Java 17 tai uudemmassa – joten tilanne on toistaiseksi kunnossa, mutta siirtymäaika lyhenee pian.
Java 11 (LTS) – Punakeltainen.
Tekoäly-SDK:iden integrointi on edelleenkin mahdollista, mutta sen vaikeusaste kasvaa: uudemmat laajennukset, kontit ja oletusarvoiset suojausasetukset edellyttävät Java 17:ää tai uudempaa versiota. Valmistautukaa siis siihen, että pinning/backport-versioita tarvitaan yhä enemmän, ja nykyisistä esimerkeistä on vähemmän hyötyä. Harkitkaa välivaiheina versioita 17 ja 21.
Java 8 ja vanhemmat versiot – Punainen.
Vaikka useat SDK:t teknisesti tukevatkin versiota 8, joudutte maksamaan siitä toiminnallista hintaa: vanhemmat TLS-salausalgoritmit, rajoitettu HTTP/2/gRPC-tuki, tiukemmat konttien perusvaatimukset ja toimittajien vähenevä tuki. Googlen ohjeistuksen mukaan on suositeltavaa käyttää uusinta LTS-versiota; AWS v1 (jota käytetään usein JDK 8:n kanssa) menettää tukensa 31. 12.2025. Jos käytätte versiota 8, varatkaa ensin budjettia alustan siirtymiseen (versioihin 17/21/25) ennen kuin lisäätte tekoälyä laajamittaisemmin. Google Cloud -dokumentaatio+1
Jos käytätte Java 21:tä tai 25:tä, olette valmiina nykyaikaiseen tekoälyyn (OpenAI/Azure, Bedrock/SageMaker, Vertex). Jos käytätte Java 11:tä,voitte edetä varovasti, mutta varautukaa kuitenkin kasvaviin ongelmiin. Jos käytätte Java 8:aa tai sitä vanhempaa versiota, päivittäkää ensin, sillä kiertoratkaisujen kustannukset nousevat korkeammiksi kuin nykyiseen LTS-versioon siirtyminen.
Voimmeko ohittaa versioita
Usein tämä onnistuu, jos kehysrakenteenne ja SDK:t tukevat kyseistä JVM:ää. Pyytäkää lyhyttä yhteensopivuustarkistusta ja pilottitestiä.
Tarvitaanko virtuaalisia säikeitä
Ei aina. Ne auttavat I/O-intensiivisiä palveluita, jotka kärsivät säikeiden enimmäismäärän rajoituksista. Pyytäkää tiimiänne mittaamaan suorituskykyä ennen ja jälkeen.
Miten käyttökatkokset voidaan välttää?Hoitakaa julkaisu vaiheittain, seuratkaa palvelun tilaa tarkasti ja käyttäkää tietoturvallista siirtosuunnitelmaa, jonka avulla vanha ja uusi koodi voivat toimia rinnakkain.
Pyytäkää yhden sivun inventaario, joka sisältää Java-version, keskeiset frameworkit, toimittajien tukiajat ja tunnetut esteet. Hyväksykää lyhyt sandbox-harjoitus ja suunnittelkaa sen jälkeen vaiheittainen käyttöönotto. Tehkää tästä säännöllinen käytäntö ja tarkistakaa tilanne neljännesvuosittain, jotta päivityksistä ei koskaan syntyisi kriisitilanteita.
Suunnittelemme ja toteutamme Java-päivitykset rauhallisin ja selkein vaihein. Jos kaipaatte toista mielipidettä tai tiimiä suunnitelmanne toteuttamiseen, ottakaa meihin yhteyttä.
.jpg)
.jpg)
.jpg)
