[Modelinterpreter] Java debug

[kmate at caesar.elte.hu]

Sziasztok!

A Java debugger API-kat összefogó JPDA specifikációt tudtommal minden  
szóba jövő virtuális gép támogatja - nem tudok más ilyen jellegű,  
kvázi konkurens megoldásról. Valósznűleg a JDT nem véletlen másolta be  
a kódot, futtatáshoz ugyanis csak JRE kell az Eclipse-nek, fordtója  
meg saját van, igy csak ez hiányzott nekik. Lehet, hogy mi is igy  
járhatunk el, a specifikáció JDI része az utóbbi években nem sokat  
változott tudtommal. A JDT-re még kockázatosabbnak tűnik épiteni,  
magasabb szintű API, komplikáltabb lehet az ő feature-jeiket  
kerülgetni. Ha licensz gondok lennének, akkor meg ők sem tehették  
volna be. De nem tudom most mi a legjobb megoldás, én a JDT API-t nem  
ismerem.

Üdv,
  Máté

Idézet (Dévai Gergely <deva at elte.hu>):

> Sziasztok!
>
> Elso"sorban a Java/Moka debug kapcsán érintettek figyelmébe:
>
> A Moka execution engine-t a korábban megbeszélteknek megfelelo"en  
> úgy szeretnénk megvalósítani, hogy a Java debugger szolgáltatásait  
> használjuk. Ehhez szükség van egy olyan API-ra, ami képes egy VM-et  
> indítani, breakpoint-okat manipulálni és debug eseményeket lekérdezni.
>
> Máté tavalyi compiler-moka-jdi-javaUML2  
> <https://plc.inf.elte.hu/modelinterpreter/trac/browser/experiments/compiler-moka-jdi-javaUML2> példája erre a célra a com.sun.jdi.VirtualMachineosztályt  
> használja.
> Ezzel kapcsolatban egyrészt felmerül, hogy nem kötjük-e magunkat  
> hozzá ezáltal egy konkrét JVM megvalósításhoz?
> Másrészt meg kell oldani a kapcsolódó függo"ség kezelését: A case  
> study a lib könyvtárában tartalmazza az Oracle-to"l letöltheto"  
> JDK-ból a tools.jar-t, ami tartalmazza a szükséges osztályokat.  
> Kérdés, hogy egy eclipse projektben szabad-e a JDK egy részét  
> binárisan terjeszteni? A weben írnak olyan véleményeket, hogy a JDK  
> csak egyben terjesztheto". Ha nem csomagoljuk be ezt a jar-t, akkor  
> meg el kell várnunk, hogy megfelelo" JDK legyen a felhasználóink  
> gépén, és dinamikusan kell feloldaunk a függo"ségünket.
> Ugyanakkor valamelyik org.eclipse.jdt.debug plugin-ban is megvannak  
> a com.sun.jdi.... csomagok, ám ez nem része a plugin publikus  
> API-jának, így ha ezzel oldjuk fel a függo"séget, akkor warning a  
> jutalom. A veszély nyilván az, hogy ezt a részt bármikor átírhatják  
> nem kompatibilis módon.
>
> Azon tipródtam ma sokat, hogy lehetne-e használni a com.sun.jdi.*  
> helyett az org.eclipse.jdt.* csomagok publikus API-ját? Ezek a  
> csomagok standard eclipse pluginokban vannak, és JVM-függetlenül  
> próbálnak Java szolgáltatásokat (többek között futtatás, debugolás)  
> nyújtani. A breakpoint-ok elhelyezésénél még stratum beállítására  
> leheto"séget adó függvényt is láttam. Az API használata nem  
> triviális, mert többnyire egy halom interfészt nyújt, és elvárja,  
> hogy a JVM implementációk extension pointokon keresztül adják az  
> implementációt. Úgy tu"nik, hogy a JavaRuntime.getVMInstallTypes(),  
> majd a IVMInstallType.createVMInstall(String id) függvényeken át  
> lehet VM-et kapni. Boldi, a saját típusú Launch konfigrációk nem  
> valami org.eclipse.jdt.launching alá tartozó típust adnak véletlenül?
>
> Vélemények, segítség jöhet!
>
> Üdv,
> Gergo"
>
>