[Modelinterpreter] Java debug

[kmate at caesar.elte.hu]

Sziasztok!

Azt hiszem ezen a ponton kicsit az oracle is ellentmondásra futott  
önmagával. Ha nem a JDK, hanem a JRE readme-jét nézem, akkor nincs  
benne a kiemelt kitétel:

http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html

Ugyanabban a "Redistributable JDK™ Files" szekcióban. Én itt  
veszítettem el a fonalat jogilag. Egyébként ha benne van a JDT-ben,  
akkor kb. egy @SuppressWarnings árán megúszható.

Üdv,
  Máté

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

> 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
>
>