Java Classloader - Java Classloader

Java Class Loader on osa Java Runtime Environment että dynaamisesti kuormien Java-luokkia osaksi Java Virtual Machine . Yleensä luokat ladataan vain pyynnöstä . Java -suoritusaikajärjestelmän ei tarvitse tietää tiedostoista ja tiedostojärjestelmistä, koska tämä on delegoitu luokanlataajalle.

Ohjelmisto kirjasto on kokoelma toisiinsa liittyviä kohdekoodin . Vuonna Java , kirjastot pakataan tyypillisesti JAR-tiedostot . Kirjastot voivat sisältää erityyppisiä objekteja. Jar -tiedoston tärkein objektityyppi on Java -luokka . Luokka voidaan ajatella nimetyksi koodiyksiköksi. Luokkalataaja vastaa kirjastojen paikantamisesta, niiden sisällön lukemisesta ja kirjastojen sisältämien luokkien lataamisesta. Tämä lataus suoritetaan tyypillisesti "pyynnöstä", koska se tapahtuu vasta, kun ohjelma kutsuu luokan. Luokka, jolla on etunimi, voidaan ladata vain kerran tietyllä luokanlataajalla.

Jokainen Java -luokka on ladattava luokanlataimen avulla. Lisäksi Java -ohjelmat voivat käyttää ulkoisia kirjastoja (toisin sanoen jonkun muun kuin ohjelman tekijän kirjoittamia ja toimittamia kirjastoja) tai ne voivat koostua ainakin osittain useista kirjastoista.

Kun JVM käynnistetään, käytetään kolmen luokan kuormaimia:

  1. Bootstrap -luokan kuormaaja
  2. Extensions -luokan kuormaaja
  3. Järjestelmäluokka

Bootstrap -luokan lataaja lataa <JAVA_HOME>/jre/libhakemistossa olevat ydin Java -kirjastot . Tämä luokan latauslaite, joka on osa JVM -ydintä, on kirjoitettu natiivikoodilla.

Laajennusten luokan lataaja lataa koodin laajennushakemistoihin ( <JAVA_HOME>/jre/lib/exttai mihin tahansa muuhun java.ext.dirsjärjestelmän ominaisuuden määrittämään hakemistoon ).

Järjestelmäluokan latauslaite lataa löydetyn koodin java.class.path, joka vastaa CLASSPATH ympäristömuuttujaan .

Käyttäjän määrittämät luokan kuormaajat

Java -luokan lataaja on kirjoitettu Java -kielellä. Siksi on mahdollista luoda oma luokkalataaja ymmärtämättä Java -virtuaalikoneen tarkempia yksityiskohtia. Jokaisella Java -luokan latauslaitteella on pääluokan latauslaite, joka määritetään, kun uusi luokanlataus on luotu tai asetettu virtuaalikoneen järjestelmän oletusluokkalataajaksi.

Tämä mahdollistaa (esimerkiksi):

Luokkakuormaajat paikassa Jakarta EE

Jakarta EE (entinen Java EE ja J2EE) -sovelluspalvelimet lataavat tyypillisesti luokkia käyttöönotetusta WAR- tai EAR -arkistosta luokanlatauspuun kautta, eristäen sovelluksen muista sovelluksista, mutta jakamalla luokat käyttöönotettujen moduulien välillä. Niin sanotut " servlet-säiliöt " toteutetaan tyypillisesti usean luokan kuormaajina.

JAR helvetti

JAR helvetti on DLL -helvetin kaltainen termi, jota käytetään kuvaamaan kaikkia erilaisia ​​tapoja, joilla luokan latausprosessi voi lopulta toimia. JAR -helvetti voi esiintyä kolmella tavalla:

  • Järjestelmään asennetun kirjaston kahden eri version vahingossa esiintyminen. Tätä ei pidetä järjestelmän virheenä. Pikemminkin järjestelmä lataa luokat yhdestä tai toisesta kirjastosta. Uuden kirjaston lisääminen käytettävissä olevien kirjastojen luetteloon sen korvaamisen sijaan voi johtaa siihen, että sovellus toimii edelleen kuin vanha kirjasto olisi käytössä, mikä saattaa hyvinkin olla.
  • Useiden kirjastojen tai sovellukset vaativat erilaisia versioita kirjaston foo . Jos kirjasto foo -versiot käyttävät samoja luokan nimiä, kirjasto foo -versioita ei voi ladata samalla luokanlataajalla.
  • Monimutkaisimmat JAR -helvetin ongelmat syntyvät olosuhteissa, joissa hyödynnetään luokanlatausjärjestelmän koko monimutkaisuus. Java -ohjelman ei tarvitse käyttää vain yhtä "tasaista" luokan lataajaa, vaan se voi koostua useista (mahdollisesti hyvin monista) sisäkkäisistä, yhteistyössä toimivista luokanlataimista. Eri luokan lataajien lataamat luokat voivat olla vuorovaikutuksessa monimutkaisilla tavoilla, joita kehittäjä ei täysin ymmärrä, mikä voi johtaa virheisiin tai virheisiin, joita on vaikea analysoida, selittää ja ratkaista.

OSGi Alliance määritetty (alkaen JSR 8 vuonna 1998) modulaarisuus kehys, joka pyrkii ratkaisemaan JAR helvettiin nykyiseen ja tulevaan VMS ME, SE, ja EE, joka on laajalti hyväksytty. Käyttämällä metatietoja JAR- luettelossa JAR-tiedostot (niput) kytketään pakettikohtaisesti. Paketit voivat viedä paketteja, tuoda paketteja ja pitää paketit yksityisinä tarjoamalla modulaarisuuden perusrakenteet ja versioidut riippuvuudenhallinnan.

JAR -helvetin ongelmien korjaamiseksi Java Community Process  - JSR 277 käynnistettiin vuonna 2005. Ratkaisun - Java Platform Module System  - tarkoituksena oli ottaa käyttöön uusi jakelumuoto, moduulien versiointijärjestelmä ja yhteinen moduulivarasto (samanlainen kuin Microsoft .NET 's Global Assembly Cache ). Joulukuussa 2008 Sun ilmoitti JSR 277: n lykkäämisestä. Java -moduulijärjestelmä käynnistettiin myöhemmin uudelleen nimellä "projektipalapeli", joka sisältyi Java 9: ​​ään .

Katso myös

Alaviitteet

Viitteet

Ulkoiset linkit