Java zavar - JVM, JNI
2009-09-18T12:06:52+02:00
2009-09-18T19:18:20+02:00
2022-07-25T10:46:20+02:00
  • Sot, ha jol ertem, ha a native kodbol hivott java kod dob egy kivetelt, akkor a JVM elkezdi a stackrol visszaszedni a frameket, hogy keressen valamit, amit le tudja kezelni a hibat.

    Elobb-utobb leveszi a stackrol a native framet is, latja, hogy az nem javas es atadja neki a kivetelt, hatha tud vele kezdeni valamit. Es ha a native kodbol hivok egy ClearException-t, akkor tulajdonkepp le van kezelve a hiba es nem crash-el a JVM.

    Jol ertem ezt? Ez lenne azt hiszem a "pending exception", amit emlegettem a nyito hozzaszolasomban.
    Mutasd a teljes hozzászólást!
  • Bocsánat, a válasz nem. Kicsit kutattam ez ügyben:).
    A JVM-ben benne vannak ezek az osztályok és interfészek, így .class file-ba nem fog bele kerülni. A jre-nél az rt.jar-ban benne vannak azon osztályok .class-ai
    Mutasd a teljes hozzászólást!
  • Ertem. Tehat kivaltodik egy futasideju kivetel a Javaban, akkor letrejon egy kivetel-objektum, amit "elkaphat" a metodus es lekezelhet. A C++ kodbol pedig egy JNI hivassal lekerdezheto ennek az objektumnak az allapota, de meghivhato a PrintStackTrace metodus is.

    De ennek feltele az, hogy
    - a kivetel kezelve legyen a javaban
    - meg azelott kerdezzuk le, hogy le lenne kezelve

    Ezt jelentene a "pending exception" kijejezes? Ez kivetel egy nevtelen objektum amugy, amire egy referencia allitodik be a catch blokk elejen? Ha ez igy van, akkor a blokk hatokoren kivulre kerulve "dereferred" lesz?
    Mutasd a teljes hozzászólást!
  • Igen, de erre nem tenném fel az életem.
    Te jobban értesz a java-hoz, meg auth.gabor, ezt elismerem
    Mutasd a teljes hozzászólást!
  • Ezeknek a Stringeknek néha meghívod a valueOf függvényét, akkor az a funkció benne lesz a byte code-ban.


    Belefordul a kodba a fuggveny implementacioja, ezt akartad irni..?
    Mutasd a teljes hozzászólást!
  • Tehat az, hogy a JVM runs the program, and it uses the class libraries, nem azt jelenti, hogy futas kozben fogja a VM kinezegetni a println metodus dolgait, hogy mit csinal es azt hogy csinalja, hanem ez mar bent van a byte code-ban.


    Igen, ez már benne van a byte kódban.

    A byte code-ban pedig nincs ott az egesz be-include-olt osztaly, csak mondjuk az a par byte, ami a println fuggveny kodja, meg persze sok egyeb info a forditoprogramrol, a konstansokrol, a parameterekrol, a szulo osztalyrol, stb.?


    Nincs benne a be-include-olt osztály. Csak azok a funkciók, amiket használsz is. Például a programodban használsz Stringeket. Ezeknek a Stringeknek néha meghívod a valueOf függvényét, akkor az a funkció benne lesz a byte code-ban. Viszont a String trim() függvénye nem lesz benne, mivel nem használod.

    De akkor mire kell a VM-nek a JRE? Ugy kepzeljem el, mintha egy DLL-t hasznalna egy C program?


    JRE-ben szerepelnek azok az osztályok/interfészek, amiket használsz a programodban. A JVM-ben nincsenek benne ezek a leírások. Lásd a JRE-ben látható osztályokat/interfészeket: Java 1.5 API
    Mutasd a teljes hozzászólást!
  • Azt meg nem értem, hogy mire akarsz utalni az exception pending-gel.

    Ezért írtam ezt a rövid kis leírást.

    [Szerk.]
    Egy exception vagy leállítja a JVM-t (persze a runtime-os exceptionok), vagy lekezeled a hibákat.
    [/Szerk.]
    Mutasd a teljes hozzászólást!
  • Kicsi magyarázatot írok a kivételkezelésről.
    Mondjuk ez Java kód és nincs sok köze a C++-hoz, de lehet magyarázatot ad.

    Először is, ha egy kivétel dobódik, akkor nem feltétlen áll le a JVM, csak ha nem kezeled le.
    Kód.:
    String valami = null; if(valami == null) { throw new IllegalArgumentException(); } System.out.println("Kész");
    Ebben az esetben elszáll egy nagy IllegalArgumentEception-nal és nem írodik ki a kész szöveg.

    Kód:
    String valami = null; try { if(valami == null) { throw new IllegalArgumentException(); } } catch(IllegalArgumentException e) { System.out.println("Bement"); } System.out.println("Kész");
    Ebben az esetben is hiba lesz, vagyis belemegy a program a catch ágba és kiírja a szöveget, de tovább fut a program
    és kiírja a szöveget és nem állt le a JVM.

    Kód:
    String valami = null; try { if(valami == null) { throw new IllegalArgumentException(); } System.out.println("Továbbment"); } finally { System.out.println("Bement"); } System.out.println("vege");
    Ebben az esetben meg IllegalargumetnException következik be, de a JVM leállása előtt kiíródik a Bement szöveg és a másik már nem,
    mivel leállt a JVM a hiba miatt.
    Mutasd a teljes hozzászólást!
  • Koszonom a linket, tenyleg kihagytam a JRE/JDK-t. Tehat onmagaban a javac semmire nem jo, kell neki a JRE!

    A byte code-ban pedig nincs ott az egesz be-include-olt osztaly, csak mondjuk az a par byte, ami a println fuggveny kodja, meg persze sok egyeb info a forditoprogramrol, a konstansokrol, a parameterekrol, a szulo osztalyrol, stb.?

    Tehat az, hogy a JVM runs the program, and it uses the class libraries, nem azt jelenti, hogy futas kozben fogja a VM kinezegetni a println metodus dolgait, hogy mit csinal es azt hogy csinalja, hanem ez mar bent van a byte code-ban.

    De akkor mire kell a VM-nek a JRE? Ugy kepzeljem el, mintha egy DLL-t hasznalna egy C program?

    Sajnalom, hogy ilyen bonyolulra sikerult a nyito hozzaszolasom. A vege lett volna az igazan fontos, ezt a (rovid) reszt idemasolom.

    Ha van egy C++ kodban egy JNI hivas, ami adhat exception-t, pl. IllegalArgumentException, akkor ez lehet azert is mert van mar egy pendig exception,Ezt ellenorizni kell a JNI hivas elott.

    Tesztelni akarom ezt az ellenorzest. Generalnom kell a JNI hivas elott egy exceptiont, ami szinten egy JNI hivas?

    Ekkor:

    JVM hiba dobas
    CHECK EXCEPTION
    a tenyleges JNI hivas
    END_CHECK_EXCEPTION

    Azt nem ertem, hogy miutan dobok egy hibat (pl. java/lang/IllegalArgumentException) az egesz JVM elszall es le se fut a CHECK_EXCEPTION?! Mitol lesz az exception pending?
    Mutasd a teljes hozzászólást!
  • Hát a közepe táján feladtam az olvasást. Nem láttam értelmét már a logikádnak

    Nem hagytad ki véletlen a folyamatodból a jdk/jre-t???

    Ezek nélkül nem is tudsz .class fájlokat létrehozni, amik futtatására már a JVM kell. JVM.
    Hiszem a Collection-ok vagy a JAVA változók(Integer, String, BigDecimal) osztályai is a jdk/jre-ben szerepelnek. Fordítani nélkülük nem is tudsz.

    Én így tudom, persze lehet butaságot írtam.

    HASZNOS link: What is the difference between JRE,JVM and JDK?
    Mutasd a teljes hozzászólást!
  • Sziasztok,

    Azt gondolom, hogy
    - van a JVM, ami mondjuk C-ben/assemlyben van implementalva, van egy binarisa, amit vegrehajt a CPU, mikor futattom a programomat, ez az interpreter.
    - van egy csomo .java fajl, amikbol lesznek a .class fajlok a JVM szamara. Ilyet irhatok en is, de fel is hasznalhatom a masok altal irt osztalyokat.
    - van maga a java nyelv es a hozza tartozo osztalyok, hisz semmi nincs osztalyon kivul. Ezeket hasznalhatja fel minden javas program. Ezekhez nem tartozik "native" binaris, hisz a JVM ertelmezi majd a programomat. Ha jol gondolom, van egy interpreter es egy compiler. Persze lehet, hogy az interpreter valtozik, optimalizaljak, miert is ne. Az is lehet, hogy a compiler valtozik, pl. bevezetnek egy uj nyelvi elemet.
    - ha mondjuk valaki portolni szeretne a JVM-et, akkor kell neki egy forditot es egy interpretert keszitenie, igaz? Mi kap ehhez a Sun-tol? A java nyelv osztalyaihoz tartozo .java fajlokat? Vagy a JVM native nyelvu forrasat is? Arra celzok, hogy a JVM nem futtathatja a JVM-et, tehat onmagat. Vagy igen? Tehat mikor elindul a JVM, akkor elindit az operacios rendszer egy folyamatot, ami aztan elindit egy szalat, ami mar egy "hivatalos" java fajlbol interpretalodik, ami aztan elinditja, futtatja az altalam keszitett "nem hivatalos" fajlt? (Azt ertem, hogy a JVM futtathat egy java nyelven irt JVM-et, ami futtathat JNI segitsegevel egy C++ nyelven irt fuggvenyt, stb.)

    Azt tudom, hogy a JNI lehetove teszi, hogy tetszoleges native fuggvenyeket hasznaljanak java osztalyok, de ugyanez a JNI lehetove teszi azt is, hogy a native fuggvenybol hozzunk letre java osztalyt, lekeredezzuk a szal allapotat, stb.

    Nem vilagos viszont, hogy a JVM maga is hasznalja a "hatterben" a JNI-t?

    Vagy a javac.exe-be (Windows) be van drotozva az osszes nyelvi elem, az osszes osztaly osszes metodusanak minden kodja? A java.exe egyszerubb, hisz az csak vegrehajtja az utasitasokat, ami veges halmaz es abszolut jol deklaralt.

    Maga a JVM is hasznal nativ fuggvenyeket, ha ez nem is transzparens a programozo szamara, vagy a JVM csak nativ fuggvenyeket hasznal, vagy hasznal java metodusokat is, onmaga mukodtetesere?

    Azt jol gondolom, hogy maga a java nyelv, maguk a nyelvi osztalyok java-ban vannak irva, ugyanakkor van olyan resz is, ami C-ben van implementalva, de megvan a forras es van olyan is, amit a Sun nem is ad oda, csak binaris formaban?

    Vagy egyszeruen van
    * a nyelv specifikacioja
    * az interpreter
    * a fordito?

    Utolso felvetes. Ha van egy C++ kodban egy JNI hivas, ami adhat exception-t, pl. IllegalArgumentException, akkor ez lehet azert mert tenyleg rossz a parameter es lehet azert mert van mar egy pendig exception, ami nincs meg lekezelve. Ezert fontos ellenorizni azt, meg a JNI hivas elott, hogy nincs-e ilyen.

    Tegyuk fel tesztelni akarom ezt az ellenorzest. Generalnom kell a JNI hivas elott egy exceptiont, ami szinten egy JNI hivas? A kor bezarulni latszik.

    De mondjuk korabbrol nincs ilyen exception.

    Ekkor:

    JVM hiba dobas
    CHECK EXCEPTION
    a tenyleges JNI hivas
    END_CHECK_EXCEPTION

    Azt nem ertem, hogy miutan dobok egy hibat (pl. java/lang/IllegalArgumentException) az egesz JVM elszall es le se fut a CHECK_EXCEPTION?!

    Tudom ezek fabol vaskarika kerdesek, de tenyleg osszezavarodtam.

    Koszi a seitseget elore is!
    Mutasd a teljes hozzászólást!
abcd