--- title: "Kriittisen Java 8 -sovelluksen päivitys moderniin Javaan" description: "Näin siirrät kriittisen Java 8 -sovelluksen nykyiseen LTS-versioon: riippuvuudet, vaiheittaiset päivitykset, testit, sudenkuopat ja kuormitustestit." canonical: https://sdk.enterprises/fi/insights/upgrading-legacy-java language: fi --- # Kriittisen Java 8 -sovelluksen päivitys moderniin Javaan Päivitetty: 2026-09-25 > Päivitä kriittinen Java 8 -sovellus vaiheittain: inventoi jokainen riippuvuus, siirry ensin Java 11:een ja sitten kuhunkin myöhempään pitkän tuen (LTS) versioon, ja anna testien ja kuormitustestien ratkaista, milloin kukin askel on turvallinen. Suurin osa työstä on kirjastoissa, käännöstyökaluissa ja JDK:n sisäosia käyttävässä koodissa, ei liiketoimintalogiikassa. ## Java 8:ssa pysyminen kaventaa vaihtoehtojasi joka vuosi Java 8 -sovellus voi pyöriä vuosia, ja juuri se on ansa. Tietoturvakorjaukset edellyttävät yhä useammin maksullista tukisopimusta tai jakelua, joka vielä takaporttaa ne, ja tärkeät kirjastot ovat siirtyneet eteenpäin. Esimerkiksi Spring Boot 3 vaatii vähintään Java 17:n, joten Java 8:ssa pysyminen jäädyttää myös sovelluskehyksesi versiot. Uudemmat JVM:t myös ajavat samaa koodia paremmin. G1 on ollut oletusroskienkerääjä Java 9:stä lähtien, lyhyiden taukojen kerääjät, kuten ZGC, ovat tuotantovalmiita, ja tiiviit merkkijonot (compact strings) vähentävät muistinkäyttöä tekstipainotteisissa kuormissa. Kehittäjät myös odottavat moderneja kielen ominaisuuksia, kuten recordeja, tekstilohkoja ja switch-lausekkeita, mikä vaikeuttaa tekijöiden löytämistä Java 8 -koodikannalle. ## Aloita inventoimalla kaikki, mistä sovellus riippuu Itse JDK:n päivitys on harvoin vaikein osa. Vaikeinta on pitkä häntä kirjastoja, lisäosia ja agentteja, jotka kirjoitettiin Java 8:lle eikä niitä koskaan päivitetty. Laadi täydellinen luettelo ennen kuin muutat mitään, ja kirjaa kunkin kohteen versio. - JDK:n toimittaja ja versio jokaisessa ympäristössä kehittäjien kannettavista tuotantoon. - Suorat ja transitiiviset riippuvuudet Mavenin riippuvuuspuusta tai Gradlen riippuvuusraportista vietyinä. - Käännöslisäosat, koodigeneraattorit ja annotaatioprosessorit, kuten Lombok. - Sovelluspalvelin tai servlet-kontti, jos sovellus toimii sellaisen sisällä. - Valvonnan, profiloinnin tai tietoturvan Java-agentit, jotka kytkeytyvät syvälle JVM:ään. - Koodi, joka käyttää JDK:n sisäisiä API:ja, löydettynä jdeps-työkalulla ja sen jdk-internals-valinnalla. - JVM-liput, roskienkerääjän asetukset ja kaikki skriptit, jotka jäsentävät java -version -komennon tulostetta. ## Etene pitkän tuen versio kerrallaan hyppäämisen sijaan Siirry Java 8:sta 11:een, sitten 17:ään ja sitten 21:een tai 25:een. Jokaisella hypyllä on omat poistonsa ja toimintamuutoksensa, ja yksi iso hyppy sekoittaa ne kaikki yhdeksi virheeksi, jota et pysty diagnosoimaan. Kerros kerrallaan korjaaminen pitää jokaisen askeleen tarpeeksi pienenä katselmoitavaksi ja peruttavaksi. Päivitä kirjastot mahdollisuuksien mukaan jo Java 8:ssa, sillä monet tuoreet versiot tukevat sekä vanhoja että uusia JDK:ita. Aja sitten nykyinen käännös uudella JVM:llä ennen kuin muutat käännöskohdetta. Näin ajonaikaiset ongelmat erottuvat kääntäjäongelmista, ja kääntäjän release-lippu pitää tavukoodin kohdeversion eksplisiittisenä. ## Tee testijoukosta jokaisen askeleen portti Testit ovat ainoa objektiivinen signaali siitä, että päivitetty sovellus toimii yhä samoin. Jos kriittisten polkujen kattavuus on heikko, kirjoita ensin karakterisointitestit: testit, jotka tallentavat, mitä järjestelmä tekee nyt, myös sen oudot reunatapaukset, arvioimatta, onko toiminta oikeaa. Lisää integraatiotestit, jotka ajetaan oikeaa tietokantaa ja oikeita viestinvälittäjiä vasten, koska monet päivitysvirheet näkyvät vain näissä rajapinnoissa. Laskentapainotteisissa järjestelmissä aja samat syötteet vanhan ja uuden version läpi ja vertaa tuloksia kenttä kentältä. Kiinnitä huomiota päivämääriin, lukuihin ja tekstiin: Java 9 siirtyi oletuksena CLDR-lokaalitietoihin ja Java 18 teki UTF-8:sta oletusmerkistön, ja kumpikin voi muuttaa muotoilua tai jäsentämistä huomaamatta. ## Tunne sudenkuopat, jotka rikkovat Java 8 -koodia Useimmat rikkoutumiset kuuluvat muutamaan tunnettuun luokkaan. Etsi jokaista niistä ennen päivitystä sen sijaan, että löytäisit sen tuotannossa. - Poistetut Java EE- ja CORBA-moduulit: Java 11 poisti JDK:sta JAXB:n, JAX-WS:n, JavaBeans Activationin ja yleiset annotaatiot (common annotations), joten ne on lisättävä takaisin eksplisiittisinä riippuvuuksina. - JDK:n sisäosien vahva kapselointi: laiton reflektiivinen pääsy tuotti varoituksia Java 9:stä alkaen, se estetään oletuksena Java 16:sta lähtien, eikä sitä voi kytkeä takaisin päälle globaalisti Java 17:stä lähtien. Korjaa se päivittämällä kirjasto; käytä add-opens-valintaa vain dokumentoituna, väliaikaisena poikkeuksena. - Vanhentuneet tavukoodityökalut: Lombokin, Mockiton, Byte Buddyn, ASM:n ja käännöslisäosien vanhemmat versiot eivät toimi uudemmilla luokkatiedostoversioilla. - Poistetut ominaisuudet: Nashorn-JavaScript-moottori poistettiin Java 15:ssä, ja Security Manager vanhennettiin Java 17:ssä ja poistettiin pysyvästi käytöstä Java 24:ssä. - Poistetut JVM-liput: CMS-roskienkerääjä poistettiin Java 14:ssä, ja poistetuilla valinnoilla käynnistetty JVM voi kieltäytyä käynnistymästä. ## Todista suorituskyky realistisella kuormalla, ei kannettavalla Uusi JDK muuttaa roskienkerääjää, JIT-kääntäjää ja muistin asettelua, joten suorituskyky voi muuttua kumpaan suuntaan tahansa. Aja kuormitustesti, joka toistaa tuotannon liikenneprofiilin samalla laitteistolla tai instanssityypillä, ennen jokaista askelta ja sen jälkeen. Vertaa viiveen persentiilejä, läpäisyä, muistia ja roskienkeruun taukoja, ja anna JIT:n lämmetä ennen mittaamista. Kehittäjämme johtivat kriittisen kaasun päiväkauppasovelluksen siirron Java 8:sta Java 16:een kansalliselle kaasukaupan kaupankäyntiyksikölle Sopra Sterian kautta. Siinä järjestelmässä kapasiteetti- ja energiavirtalaskelmien piti pysyä oikeina ja nopeina korkeataajuuksisella kuormalla, joten päivitys kulki käsi kädessä näiden laskelmien optimoinnin kanssa, ja se validoitiin kuormalla eikä sen toimivuutta oletettu. ## Ota käyttöön asteittain ja säilytä paluutie Vie päivitetty ajoympäristö ensin yhteen instanssiin tai pieneen osaan liikenteestä ja seuraa virhetasoja, viivettä ja roskienkeruun käyttäytymistä Java 8 -vertailukohtaa vasten. Pidä edellinen käännös käyttöönotettavana, kunnes uusi versio on käynyt läpi tavalliset liiketoimintajaksot, kuukauden vaihteet ja huippujaksot mukaan lukien. Vasta sitten poista Java 8 -artefaktit ja ala käyttää uusia kielen ominaisuuksia. Jos haluat apua tällaisen päivityksen suunnitteluun tai toteutukseen, SDK Enterprises miehittää sen omilla kehittäjillään ja tarkistetuilla asiantuntijoilla yhdellä sopimuksella, jossa vastuu on meillä. ## Tärkeimmät havainnot - Java 8 -päivityksen työ on enimmäkseen riippuvuuksissa, käännöstyökaluissa ja JDK:n sisäosien käytössä, ei liiketoimintalogiikassa. - Etene pitkän tuen versio kerrallaan, jotta jokaisella virheellä on yksi, löydettävä syy. - Karakterisointi- ja integraatiotestit ovat jokaisen askeleen portti, erityisesti päivämäärien, lukujen ja merkistökoodauksen osalta. - Validoi suorituskyky tuotannon kaltaisella kuormalla, koska roskienkeruun ja JIT:n muutokset voivat siirtää tuloksia kumpaan suuntaan tahansa. - Ota käyttöön ensin pienelle osalle liikenteestä ja pidä Java 8 -käännös käyttöönotettavana, kunnes uusi ajoympäristö on osoittanut toimivuutensa. ## UKK ### Voiko Java 8:sta päivittää suoraan Java 21:een? Voi, mutta perit kaikki muutokset Java 9:stä 21:een kerralla, mikä tekee virheistä vaikeita jäljittää. Eteneminen 11:n ja 17:n kautta vie hieman enemmän käännösaikaa ja säästää paljon virheenetsintää kriittisessä järjestelmässä. ### Kuinka kauan Java 8 -päivitys kestää? Se riippuu riippuvuuksien määrästä, siitä, kuinka moni niistä käyttää JDK:n sisäosia, testikattavuudesta ja siitä, kuinka paljon kuormitustestausta järjestelmä tarvitsee. Inventaario ja koeajo uudella JVM:llä antavat realistisen arvion varhain, ennen kuin sitoudut aikatauluun. ### Pitääkö koodi kirjoittaa uudelleen uusien Java-ominaisuuksien käyttämiseksi? Ei. Java säilyttää vahvan taaksepäin yhteensopivuuden koodille, joka pitäytyy standardeissa, vanhentumattomissa API:issa. Ota recordit, tekstilohkot ja muut ominaisuudet käyttöön vähitellen, kun päivitetty ajoympäristö on vakaa tuotannossa. ## Liittyvät palvelut - [Räätälöity ohjelmisto](https://sdk.enterprises/fi/services/product-engineering) - [Sovellusten tietoturva](https://sdk.enterprises/fi/services/secure-systems)