[Modelinterpreter] Java debug
Gergely Dévai
deva at caesar.elte.hu
Tue Mar 17 11:38:45 CET 2015
Sziasztok!
Megnéztem az Oracle JDK license-t redistribution szempontból:
C. LICENSE TO DISTRIBUTE SOFTWARE.
Subject to the terms and conditions of this Agreement and restrictions
and *exceptions set forth in the README File*, including, but not
limited to the Java Technology Restrictions and Limitations on
Redistribution of these Supplemental Terms, Oracle grants you a
non-exclusive, non-transferable, limited license without fees to
reproduce and distribute the Software, provided that (i) *you distribute
the Software complete and unmodified* and only bundled as part of, and
for the sole purpose of running, your Programs [...]
JDK 8 Readme:
Redistributable JDK files
The limited set of files and directories from the JDK listed below may
be included in vendor redistributions of the Java Runtime Environment
(JRE). They *cannot be redistributed separately*, and must accompany a
JRE distribution.
[...]
|lib/tools.jar
||
|Nem tudom, a JDT-s pluginnál hogyan oldották meg, de a fentiek alapján
a tools.jar csak egy teljes JDK részeként vagy egy teljes JRE-hez adott
kiegészítésként csomagolható bele a szoftverünkbe.
Marad az, hogy a JDT plugin internal részéből használjuk a JDI-t és
elnyomjuk a warningot, vagy kipróbáljuk a JDT API-t.
Üdv,
Gergő
On 2015-03-17 09:46, kmate at caesar.elte.hu wrote:
> 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"
>>
>>
>
>
>
> _______________________________________________
> Modelinterpreter mailing list
> Modelinterpreter at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/modelinterpreter/attachments/20150317/174c8aac/attachment-0001.html>
More information about the Modelinterpreter
mailing list