[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