<html>Hali,<br /><br />A JDK azt mondja, hogy vagy az egesz JDK, vagy JRE + tools.jar, es explicit kimondja, hogy tools.jar onmagaban nem lehet.<br />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.<br /><br />De igazabol mindegy, egyelore importalom a dolgokat a JDT pluginbol, es suppress warning. Ha meg lesz idom, akkor megtanulom a JDT API-t.<br /><br />/ Gergo<br /><br />On Tuesday, March 17, 2015 13:46 CET, <kmate@caesar.elte.hu> wrote:<br /> <blockquote type="cite" cite="20150317134612.14633qm6jgglz6s4@webmail.elte.hu">Sziasztok!<br /><br />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:<br /><br />http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html<br /><br />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ó.<br /><br />Üdv,<br />Máté<br /><br />Idézet (Gergely Dévai <deva@caesar.elte.hu>):<br /><br />> Sziasztok!<br />><br />> Megnéztem az Oracle JDK license-t redistribution szempontból:<br />><br />> C. LICENSE TO DISTRIBUTE SOFTWARE.<br />> 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 [...]<br />><br />> JDK 8 Readme:<br />><br />> Redistributable JDK files<br />> 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.<br />> [...]<br />> |lib/tools.jar<br />> ||<br />> |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.<br />><br />> 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.<br />><br />> Üdv,<br />> Gergő<br />><br />><br />> On 2015-03-17 09:46, kmate@caesar.elte.hu wrote:<br />>> Sziasztok!<br />>><br />>> 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.<br />>><br />>> Üdv,<br />>> Máté<br />>><br />>> Idézet (Dévai Gergely <deva@elte.hu>):<br />>><br />>>> Sziasztok!<br />>>><br />>>> Elso"sorban a Java/Moka debug kapcsán érintettek figyelmébe:<br />>>><br />>>> 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.<br />>>><br />>>> 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.<br />>>> Ezzel kapcsolatban egyrészt felmerül, hogy nem kötjük-e magunkat >>> hozzá ezáltal egy konkrét JVM megvalósításhoz?<br />>>> 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.<br />>>> 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.<br />>>><br />>>> 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?<br />>>><br />>>> Vélemények, segítség jöhet!<br />>>><br />>>> Üdv,<br />>>> Gergo"<br />>>><br />>>><br />>><br />>><br />>><br />>> _______________________________________________<br />>> Modelinterpreter mailing list<br />>> Modelinterpreter@plc.inf.elte.hu<br />>> https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter<br />><br />><br /><br /><br /><br />_______________________________________________<br />Modelinterpreter mailing list<br />Modelinterpreter@plc.inf.elte.hu<br />https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter</blockquote><br /><br /><br /> </html>