[Modelinterpreter] Java debug

[Dévai Gergely]

Hali,

A JDK azt mondja, hogy vagy az egesz JDK, vagy JRE + tools.jar, es explicit kimondja, hogy tools.jar onmagaban nem lehet.
A JRE pedig azt, hogy a JRE melle odacsomagolhatod a tools.jar-t. Itt explicit nem mondja ki, hogy a tools.jar onmagaban nem csomagolhato, gondolom azert, mert itt a JRE-rol van alapvetoen szo, a tools.jar pedig a JDK resze.

De igazabol mindegy, egyelore importalom a dolgokat a JDT pluginbol, es suppress warning. Ha meg lesz idom, akkor megtanulom a JDT API-t.

/ Gergo

On Tuesday, March 17, 2015 13:46 CET, <kmate at caesar.elte.hu> wrote:
 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
>
>



_______________________________________________
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/2bc345e2/attachment-0001.html>