Ez a rész leírja a szükséges módosításokat, ha a 2.1 bedolgozót módosítani kívánja, hogy elfogadja a 3.0 mechanizmusokat és alkalmazás programozási felületeket.
Az Eclipse 3.0 futási környezet jelentősen különbözik. Az alapul szolgáló megvalósítás az OSGi keretrendszer-specifikációra épül. Az Eclipse 3.0 futási környezet tartalmaz egy kompatibilitási réteget (az org.eclipse.core.runtime.compatibility bedolgozóban), amely karbantartja a 2.1 alkalmazás programozási felületeket. A jobb teljesítményben és további funkciókban érdekelt bedolgozófejlesztőknek meg kell fontolniuk a 3.0 alkalmazás programozási felületek alkalmazását és a kompatibilitási réteg függőség megszüntetését. A kompatibilitási kód három helyen jelenik meg:
Az alábbi szöveg részletes információkat biztosít azzal kapcsolatban, hogy mely osztályok és metódusok vannak jelen kompatibilitási okokból, valamint a bedolgozó frissítésének módját mutatja be.
Az Eclipse futási környezet két részre lett bontva; az osztálybetöltés és az előfeltétel-kezelés, valamint a kiterjesztés/kiterjesztési pont kezelés. Ezen felosztás segítségével az OSGi keretrendszer-specifikáció természetesen/zökkenőmentesen alkalmazható az osztálybetöltéshez és az előfeltétel-kezeléshez. Ez számos új képességet tesz lehetővé a futási környezetben a bedolgozó dinamikus telepítési/frissítési/eltávolítási lehetőségétől a biztonságig és jobb konfigurálhatóságig.
Továbbra is bedolgozókról beszélünk, de az új futási környezetben a bedolgozó valójában egy köteg, néhány kiterjesztés és kiterjesztési pont. A köteg kifejezést az OSGi keretrendszer-specifikáció használja: típusok valamint erőforrások gyűjteményére utal, és kötegen belüli előfeltétel-információkhoz vannak társítva. A kiterjesztésnyilvántartás a bedolgozónyilvántartás új formája, és csak a kiterjesztés valamint a kiterjesztési pont információkat részletezi. A kiterjesztésnyilvántartási API nagyjából megegyezik az érintett bedolgozónyilvántartás alkalmazás programozási felülettel (további információkat a Nyilvántartások rész tartalmaz).
Az Eclipse 2.x futási környezetben a bedolgozóobjektum számos szereppel és felelőséggel rendelkezik:
Az Eclipse 3.0 futási környezet képben ezek a szerepek és felelősségek külön objektumokra lettek bontva.
A bedolgozó a BundleActivator aktiválót is megvalósítja. Ez annak kényelmét ismeri el, hogy egy központi objektum ábrázolja a bedolgozó életciklusát és szemantikáját. Ez nem szentesíti az adatstruktúrák mohó inicializálását, amely manapság a bedolgozókban általános. Nem hangsúlyozhatjuk eléggé, hogy a bedolgozók aktiválhatók, ha néhány másik bedolgozóban az osztály ellenőrzése során egy periféria osztályra hivatkoztak. Azaz a bedolgozók aktiválása nem jelenti szükségszerűen azt, hogy funkcióra szükség van. Tetszőlegesen egy másik BundleActivator osztály is megadható, de a kötegaktiváló teljesen el is távolítható.
A 2.x Bedolgozó osztály Eclipse 3.0 verzióra átírásának szükséges lépései a használt osztálytól függenek. Ahogy fent említettük, a legtöbb indítási életciklus-feladat az alábbi kategóriák egyikébe esik:
Az új futási környezetben el vannak különítve a bedolgozó végrehajtásához szükséges információk és struktúrák, amelyek a bedolgozó kiterjesztéseihez és kiterjesztési pontjaihoz kapcsolódnak. Az előbbieket az OSGi keretrendszer-specifikáció adja meg és kezeli. Az utóbbiak Eclipse-specifikus alapelvek, és az Eclipse futási kód adja meg őket. Az eredeti bedolgozó-nyilvántartás és a kapcsolódó objektumok fel lettek osztva OSGi kötegekre és egy Eclipse kiterjesztés-nyilvántartásra.
A végrehajtási specifikációt kezelő IPluginRegistry részei (például IPluginDescriptor, ILibrary, IPrequisite) elavultak, és a kiterjesztésekhez valamint kiterjesztési pontokhoz kapcsolódó további részek átkerültek az IExtensionRegistry nyilvántartásba. A bedolgozó nyilvántartáshoz egészként kapcsolódó úgynevezett modellobjektumok elavultak. Ezeket a típusokat a futási rendszer jelenítette meg és példányosította elsődlegesen az eszközkezelés - mint például a PDE - támogatása érdekében. Sajnos gyakran az az eset, hogy a szükséges információk szintje meghaladja a képességeket és érdekeltséget (például a plugin.xml elemek sorszámainak megjegyzése) és végül a futási környezet információk lehetséges ügyfeleinek karban kell tartaniuk a saját struktúrájukat.
Az új futási környezetben újból kiértékeltük a futási környezet által biztosított szolgáltatásokat és már csak azok biztosítottak, amelyek alapvető fontosságúak a futási környezet végrehajtáshoz vagy kivételesen nehéz ez mások számára. Ahogy fent említettük, a bedolgozó nyilvántartásmodell-objektumok elavultak, mivel rendelkeznek bedolgozóelemzési alkalmazás programozási felülettel. Az kiterjesztések nyilvántartás karbantartja az alapvető fontosságú kiterjesztéssel kapcsolatos információkat. Az új állapot (lásd: org.eclipse.osgi.service.resolver.State és egyéb ismerős elemek) struktúra ábrázolja és lehetővé teszi a lényeges végrehajtással kapcsolatos információk kezelését.
Az Eclipse 3.0 verzióban az NL töredékstruktúra frissítésre került, hogy konzisztensebb legyen. Korábban a fájlok - mint például a plugin.properties - fordításairól feltételezték, hogy a töredékek által biztosított JAR fájlokban vannak. Mivel az eredeti fájlok az érintett gazdabedolgozó gyökerében találhatók, a lefordított fájlok egy konzisztensebb helyen találhatók, az NL töredékek gyökerében. Például:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Figyelje meg, hogy az nl1.jar fájl korábban tartalmazta a plugin.properties fordításait. Ezek a fájlok a töredék gyökerében találhatók, és a JAR tárolja a lefordítható erőforrások fordításait (például az osztálybetöltőn keresztül betöltött fájlok) a gazdabedolgozóban.
Természetesen az Eclipse 3.0 verzióban futó 2.1 gazdabedolgozók továbbra is támogatják az Eclipse 2.1 töredékstruktúrát. A 2.1 NL töredék nem használható 3.0 bedolgozón. A töredéket frissíteni kell az új struktúrához.
A teljes org.eclipse.core.boot csomag elavult. A BootLoader összefésülésre került az org.eclipse.core.runtime.Platform elemmel, mivel a rendszerbetöltés és futási környezet közötti felosztásának a továbbiakban nincs értelme. Az org.eclipse.core.boot bedolgozó felosztásra, a teljes kód pedig áthelyezésre került az új futási környezetbe vagy a kompatibilitási rétegbe.
Az IPlatformConfiguration az Eclipse Telepítés/Frissítés összetevő által megadott típussal rendelkezik. A futási környezet újraszervezésével ezt a típust visszaküldhetjük jogos helyére. Ez az osztály lényegében változatlan, és újracsomagolásra került org.eclipse.update.configurator.IPlatformConfiguration elemként.
Az IPlatformRunnable átkerült az org.eclipse.core.runtime.IPlatformRunnable elembe.
A getDeclaringPlugin()
metódus (minden osztályon) egy
felfelé mutató hivatkozást biztosít a bedolgozóhoz, amely megadja a
kiterjesztési pont kiterjesztését (értelemszerűen).
Az új nyilvántartásmodell szétválasztja a bedolgozók végrehajtási
aspektusait a kiterjesztés/kiterjesztési pont aspektusoktól, és nem
tartalmazza az IPluginDescriptors bedolgozót.
Ezen API felhasználóinak meg kell fontolniuk az új
getParentIdentifier() metódus használatát, amely az
IExtension és IExtensionPoint elemen található meg.
Az eredeti futási környezetben a bedolgozó nyilvántartás egy teljes képet tart fenn a futási konfigurációról. Az Eclipse 3.0 verzióban ez a kép az OSGi keretrendszerre és a kiterjesztési nyilvántartásra is kiterjed. Ily módon ezek az osztályok elavultak. Az elavulási megjegyzések a kód frissítési módjával kapcsolatos részleteket tartalmaznak.
Az új futási környezetben a Bedolgozó objektumokat a futási környezet már nem kezeli, így a Platformon keresztül általánosan nem érhetők el. Ehhez hasonlóan a bedolgozónyilvántartás már nem létezik és nem biztosít hozzáférést a bedolgozóleírókhoz. Megfelelő helyettesítőmetódusok állnak rendelkezésre, amelyek részletes leírása ezen osztályok elavult metódusainak Javadoc dokumentumaiban találhatók.
A csomag összes típusa elavult. További információkat a nyilvántartások leírása tartalmaz.
Az IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) metódus ügyfeleinek át kell tekinteniük a metódus használatát, és meg kell fontolniuk a nagyobb funkciógazdagságú metódusok használatát IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). A régi IWorkspace.run metódus az IWorkspaceRunnable időtartama alatt egy zárolást szerez a teljes munkaterületre. Ez azt jelenti, hogy a metódussal végzett művelet nem futhat párhuzamosan más műveletekkel, amelyek a munkaterületet módosítják. Az Eclipse 3.0 verzióban számos hosszan futó művelet került át a háttérszálakba, így a műveletek közötti konfliktusok valószínűsége nagymértékben növekedett. Ha egy hosszan futó háttérművelet egy modális előtérműveletet blokkol, akkor az UI blokkolásra kerül a háttérművelet befejeződésééig, vagy a műveletek egyikének törléséig.
A javasolt megoldás a régi IWorkspace.run metódusra mutató
összes hivatkozás átkapcsolása, hogy az új metódust használják egy
ütemezési szabályparaméterrel. Az ütemezési szabálynak a legfinomabban
szabályozhatónak kell lennie, amely összefogja a művelet által végzett
összes módosítás szabályait. Ha a művelet az ütemezési szabály hatókörén
kívül eső erőforrást próbál módosítani, akkor futási kivétel történik. Az
adott munkaterület-művelet által igényelt precíz ütemezési szabály nincs
megadva, és az adott projekten telepített lerakatszolgáltatótól függően
változhat. Az erőforrás-módosítási művelet ütemezési szabályának
megszerezéséhez az IResourceRuleFactory
gyárat kell
használni. Ha kívánatos, akkor a MultiRule segítségével több
erőforrásszabály is megadható, és a MultiRule.combine metódus
segítségével kombinálhatók a különböző erőforrás-módosítási műveletek
szabályai.
Ha nincs szükség zárolásra, akkor a null ütemezési szabálya használható. Ennek segítségével a futtatható fájl módosíthatja a munkaterület összes erőforrását, de nem akadályozza meg, hogy más szálak egyidejűleg szintén módosítsák a munkaterületet. A munkaterület egyszerű módosításához ez gyakran a legegyszerűbb és leginkább egyidejűség-támogató megoldás.
filteredSelection
kijelölésből
feldolgozás érdekében:
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
if (selection.isEmpty()) { IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { IWorkbenchPart part = window.getPartService().getActivePart(); if (part instanceof IEditorPart) { IEditorInput input = ((IEditorPart) part).getEditorInput(); if (input instanceof IFileEditorInput) { selection = new StructuredSelection(((IFileEditorInput) input).getFile()); } } } }
IActionBars actionBars= getActionBars(); if (actionBars != null) { actionBars.setGlobalActionHandler(IDEActionFactory.ADD_TASK.getId(), getAction(textEditor, IDEActionFactory.ADD_TASK.getId())); actionBars.setGlobalActionHandler(IDEActionFactory.BOOKMARK.getId(), getAction(textEditor, IDEActionFactory.BOOKMARK.getId())); }
Itt a feljegyzéstípus explicit megjegyzése található. Lásd: Annotation.getType() és Annotation.setType(). A feljegyzés típusa az élettartama során változhat. Egy kiterjesztési pont került hozzáadásra a feljegyzéstípus deklarációjához: "org.eclipse.ui.editors.annotationTypes". A feljegyzéstípusnak van neve, és deklarálható egy másik megadott feljegyzési típus altípusaként. A feljegyzéstípus-deklaráció a "markerType" és "markerSeverity" attribútumokat is használhatja annak megadásához, hogy az adott típusú jelzőket és fontosságot a szövegszerkesztőnek egy adott feljegyzéstípus feljegyzéseiként kell megadni. Az "org.eclipse.ui.editors.markerAnnotationSpecification" "markerType" és "markerSeverity" attribútumait a továbbiakban nem szabad használni. Ezért a jelzőfeljegyzés-specifikációk a jelzőktől függetlenek lesznek, és a név félrevezető. A rendszer a visszamenőleges kompatibilitás biztosítása érdekében megtartja a nevet.
Az AbstractMarkerAnnotationModel alosztályainak példányai a jelzőkhöz létrehozott feljegyzésekhez automatikusan észlelik és beállítják a megfelelő feljegyzéstípust. Egy adott jelző vagy egy adott markerType és markerSeverity pár feljegyzéstípusa az org.eclipse.ui.texteditor.AnnotationTypeLookup segítségével programozási eljárással lekérhető.
A feljegyzéstípusok hierarchiájának elérését az IAnnotationAccessExtension biztosítja. Egy adott feljegyzéstípushoz lekérhető a szupertípusok lánca, és ellenőrizhető, hogy a feljegyzéstípus egy másik feljegyzéstípus altípusa-e. A DefaultMarkerAnnotationAccess megvalósítja ezt a felület.
A feljegyzéstípus a kulcs, amellyel a társított jelzőfeljegyzés-specifikáció kikereshető. Mivel a feljegyzéstípus kiterjeszthet másik kiterjesztéstípust, implicit kapcsolat van a jelzőfeljegyzés-specifikációk között. Egy adott feljegyzéstípus jelzőfeljegyzés-specifikációját az adott feljegyzéstípus szupertípusához adott jelzőfeljegyzés-specifikációk egészítik ki. A jelzőfeljegyzés-specifikációknak nem kell teljesnek lenniük, ahogy ez korábban szükséges volt. A jelzőfeljegyzés-specifikációt az AnnotationPreferences kéri le. Az org.eclipse.ui.texteditor.AnnotationPreferenceLookup segítségével a feljegyzésbeállítás lekérhető egy adott feljegyzéstípushoz, amely a feljegyzésszupertípus-lánccal átlátszó módon végrehajtja a beállítás megadását.
A jelzőfeljegyzés-specifikáció ki lett terjesztve három további attribútummal a függőeleges vonalzón lévő adott feljegyzéstípus egyéni megjelenésének engedélyezése érdekében. Ezek az attribútumok az alábbiak: "icon", "symbolicIcon" és "annotationImageProvider". Az "icon" értéke az ikonképet tartalmazó fájl elérési útja. A "symbolicIcon" értéke az alábbi lehet: "error", "warning", "info", "task", "bookmark". A "symbolicIcon" attribútum előírja a platform számára, hogy a feljegyzést ugyanannak a képnek kell ábrázolnia, mint amelyet a platform használ a hibák, figyelmeztetések, információk, feladatok és könyvjelzők megjelenítéséhez, értelemszerűen. Az "annotationImageProvider" értéke az org.eclipse.ui.texteditor.IAnnotationImageProvider elemet megvalósító osztály, amely teljesen egyéni feljegyzésmegjelenítést tesz lehetővé.
A függőleges vonalzó a társított IAnnotationAccess/IAnnotationAccessExtension elemet használja a feljegyzések lerajzolásához. A függőleges vonalzó nem hívja meg többet az Annotation.paint elemet. A feljegyzések általában nem rajzolják le magukat. A "paint" és "getLayer" metódusok elavulttá váltak a feljegyzés UI-függetlenné tétele érdekében. A DefaultMarkerAnnotationAccess az IAnnotationAccess/IAnnotationAccessExtension alapértelmezett megvalósításaként szolgál. A DefaultMarkerAnnotationAccess az alábbi stratégiát valósítja meg a festésfeljegyzésekhez: Ha a feljegyzés az IAnnotationPresentation elemet valósítja meg, akkor az IAnnotationPresentation.paint kerül meghívásra. Ha nem, akkor feljegyzésbeállításban kieresésre kerül a feljegyzés-képszolgáltató. A feljegyzés-képszolgáltató csak akkor érhető el, ha meg van adva, és a csatoló jelzőfeljegyzés-specifikációt megadó bedolgozó már betöltésre került. Ha itt található egy feljegyzéskép-szolgáltató, akkor a hívás továbbításra kerül hozzá. Ha nem, akkor a megadott "icon" kerül kikeresésre. A rendszer a "symbolicIcon" attribútumot végső visszalépésként használja. Rajzolási feljegyzések esetén a feljegyzésmegjelenítési réteg érdekes. A DefaultMarkerAnnotationAccess az alábbi stratégiával keresi meg a megjelenítési réteget: Ha a feljegyzésbeállítás megad egy beállításréteget, akkor a rendszer a megadott réteget használja. Ha nincs réteg, és a feljegyzés megvalósítja az IAnnotationPresentation elemet, akkor a rendszer az IAnnotationPresentation.getLayer metódust használja, ellenkező esetben a megjelenítési réteg (amely 0) kerül visszaadásra.
Az org.eclipse.ui.editors bedolgozó az alábbi feljegyzéstípusokat adja meg:
<extension point="org.eclipse.ui.editors.annotationTypes"> <type name="org.eclipse.ui.workbench.texteditor.error" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="2"> </type> <type name="org.eclipse.ui.workbench.texteditor.warning" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="1"> </type> <type name="org.eclipse.ui.workbench.texteditor.info" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="0"> </type> <type name="org.eclipse.ui.workbench.texteditor.task" markerType="org.eclipse.core.resources.taskmarker"> </type> <type name="org.eclipse.ui.workbench.texteditor.bookmark" markerType="org.eclipse.core.resources.bookmark"> </type> </extension>
A megadott markerAnnotationSpecification kiterjesztés a továbbiakban nem biztosít "markerType" és "markerSeverity" attribútumokat. Ezek a "symbolicIcon" attribútumot adják meg a megfelelő értékkel. A MarkerAnnotation.paint és MarkerAnnotation.getLayer a továbbiakban nem kerül meghívásra, azaz ezen metódusok újradefiniálásának nincs hatása. A befolyásolt ügyfeleknek meg kell valósítaniuk az IAnnotationPresentation elemet.
A kiterjeszthető indítási módok 3.0 verzióban bevezetésével egy
indításikonfiguráció-típushoz több indításdelegálás állhat rendelkezésre.
A 3.0 előtti kiadások indítási konfigurációs típusonként csak egy
indításdelegálást támogattak. Az
ILaunchConfigurationType.getDelegate()
metódus már elavult. A
getDelegate(String mode)
metódust helyben kell használni az
indításdelegálás adott indítási módhoz lekéréséhez.
Az elavult metódus megváltozott a run
mód
indításdelegálásának visszaadása érdekében.
Az indítólap-csoportok és az indítólapok többé nem kapnak értesítést
egy indítás befejezéséről. Az ILaunchConfigurationTab
és
ILaunchConfigurationTabGroup
felületen lévő
launched(ILaunch)
metódus elavult, és nem kerül meghívásra.
Erre a metódusra támaszkodó indítási funkció mindig problémás volt, mivel a
lapok csak akkor léteznek, ha az indítás az indítás párbeszédablakból
kerül végrehajtásra. A háttérindítás bevezetésével ez a metódus már nem
hívható meg, mivel az indítás párbeszédablak lezárásra kerül az eredményül
kapott indítási objektum létrehozása előtt.
Két metódus került hozzáadásra az ILaunchConfigurationTab
felülethez - az aktivált és letiltott. Ezek az új életciklus-metódusok
akkor kerülnek meghívásra, ha a lap be- és kiléptetésre kerül,
értelemszerűen. Az ILaunchConfigurationTab
meglévő
megvalósításai, amelyek alosztályokat hoznak létre a hibakeresés bedolgozó
által biztosított absztrakt osztályokhoz
(AbstractLaunchConfigurationTab
), binárisan kompatibilisek,
mivel a metódusok az absztrakt osztályban kerülnek megvalósításra.
A korábbi kiadásokban a lap aktiváláskor az
initializeFrom
, leállításkor pedig a
performApply
üzenetet küldte. Ily módon az indítási
konfigurációs lap keretrendszer lapok közötti kommunikációt biztosított az
indítási konfiguráción keresztül (a konfiguráció aktuális
attribútumértékekkel frissítésével, amikor a lap kiléptetésre kerül,
valamint az újonnan megadott lap frissítésével). Mivel számos lap nem hajt
végre lapok közötti kommunikációt, ez nem mindig használható. Hasonlóan,
nem volt lehetőség megkülönböztetni egy éppen aktivált lapot egy olyan
laptól, amely első alkalommal jelenített megy egy adott indítási
konfigurációt. Az újonnan hozzáadott metódusok segítségével a lapok különbséget
tehetnek az aktiválás és inicializálás között, valamint a leállítás és az
aktuális értékek mentése között.
Az absztrakt lap által biztosított aktivált
elem
alapértelmezett megvalósítása meghívja az initializeFrom
metódust. A leállított
alapértelmezett megvalósítása a
performApply
metódust hívja meg. Az új API előnyeit
kihasználni kívánó lapoknak szükség szerint újra kell definiálniuk ezeket
a metódusokat.
A lapok közötti kommunikációt nem megvalósító lapok esetén az ajánlott
megközelítés a metódusok újbóli megvalósítása, hogy ne csináljanak semmit.
A korábbi kiadásokban a perspektívaátkapcsolás az indítási
konfiguráción került megadásra az
ATTR_TARGET_DEBUG_PERSPECTIVE
és
ATTR_TARGET_RUN_PERSPECTIVE
indítási konfigurációs
attribútumokon keresztül. A 3.0 kiterjeszthető indítási módjainak
bevezetésével ez a megközelítés már nem méretezhető. A
perspektívaátkapcsolás az indítási konfigurációs típus alapján indítási
módonként került megadásra, amelyet az indítási konfigurációs típus
támogat. Az API hozzáadásra került a DebugUITools
elemhez egy
adott indítási mód indításikonfiguráció-típusához rendelt perspektíva
beállításához és lekéréséhez.
Egy további, elhagyható launchMode
elem került hozzáadásra
a launchConfigurationTabGroup
kiterjesztési ponthoz, ezáltal
a közreadott lapcsoport egy alapértelmezett perspektívát adhat meg egy
indításikonfiguráció-típushoz és -módhoz.
Az Eclipse felhasználói felületről a felhasználók szerkeszthetik az indításikonfiguráció-típushoz rendelt perspektívát az indítási konfigurációs párbeszédablak megnyitásával, és a fában egy indítási konfigurációs típus csomópont kiválasztásával (egy egyedi konfiguráció helyett). Megjelenik egy lap annak engedélyezése érdekében, hogy a felhasználó minden támogatott indítási módhoz beállítson egy perspektívát.
Két metódus került hozzáadásra a VMRunnerConfiguration
osztályhoz a környezeti változók beállításának és lekérésének támogatása
érdekében. Az IVMRunner
megvalósítóinak meg kell hívniuk a
VMRunnerConfiguration.getEnvironment()
metódust, és át kell
adniuk ezt a környezetet a végrehajtott JVM-nek. A
DebugPlugin.exec(String[] cmdLine, File workingDirectory)
metódust használó ügyfelek ezt a DebugPlugin.exec(String[] cmdLine,
File workingDirectory, String[] envp)
meghívásával hajthatják
végre. A getEnvironment()
eredmény egyszerű átadása elegendő.
A korábbi kiadásokban a rendszerbetöltési elérési út leírásához a
VMRunnerConfiguration
rendelkezett egy attribútummal. Az
attribútum az -Xbootclasspath
argumentumban megadásra kerülő
Stringek
gyűjteménye. A JVM-ek támogatása érdekében három új
attribútum került hozzáadásra a VMRunnerConfiguration elemhez, amelyek
lehetővé teszik a rendszerbetöltési elérési út hozzáfűzését, és az elérési
úthoz fűzést. A hozzáadott új metódusok/attribútumok az alábbiak:
getPrependBootClassPath()
- bejegyzések gyűjteményét
adja vissza, amelyek a rendszerbetöltési elérési út elé kerülnek (a
-Xbootclasspath/p
argumentum)getMainBootClassPath()
- bejegyzések gyűjteményét adja
vissza, amelyek a rendszerbetöltési útra kerülnek (az
-Xbootclasspath
argumentum)getAppendBootClassPath()
- bejegyzések gyűjteményét
adja vissza, amelyek hozzáfűzésre kerülnek a rendszerbetöltési elérési
úthoz (az -Xbootclasspath/a
argumentum)A régi getBootClassPath()
attribútum továbbra is létezik,
és a három új attribútumnak megfelelő teljes elérési utat tartalmaz. Az új
rendszerbetöltési elérési utat támogató VMRunners
elemnek ki
kell használnia az új attribútumok előnyeit.
A Java modell működő példány szolgáltatása a jelentősen javított funkcionalitás biztosítása érdekében 3.0 verzióban átdolgozásra került. A 3.0 verzió előtt a Java modell lehetővé tette a fordítási egység egyéni működő példányainak létrehozását. A működő példány módosítható, és később véglegesíthető. Támogatva volt a Java-modell maradékának kontextusában a működő példány korlátozott elemzése. Ugyanakkor ezek az elemzések semmilyen módon nem tudtak egynél több működő példányt figyelembe venni.
A 3.0 módosításai lehetővé teszik fordítási egységek működő példányainak létrehozását és kezelését, és elemzéseket hajthatnak végre az összes működő példány jelenlétében. Például most már egy, a JDT-újraíráshoz hasonló ügyfél számára, hogy működő példányokat hozzon létre egy vagy több módosítani kívánt fordítási egységhez, majd ezek után feloldja a működő példányok típushivatkozásait. Korábban ez csak a fordítási egység működő példányok módosításainak elfogadása után volt lehetséges.
A Java modell API kétféleképpen változik a jobb támogatás biztosítása érdekében:
(1) A korábban az IWorkingCopy
elemen megtalálható, és az
ICompilationUnit
által örökölt funkciók az
ICompilationUnit
elembe lettek egyesítve.
Az IWorkingCopy
felület csak ezen a helyen volt használható,
és indokolatlanuk általánosabb volt, mint aminek kellett lennie. Ez a
módosítás leegyszerűsíti az alkalmazás programozási felületet.
Az IWorkingCopy
elavult. Az alkalmazás programozási felület
más helyei, ahol az IWorkingCopy
paraméterként vagy
eredménytípusként került használatra, szintén elavultak; a helyettesítő
API metódusok az ICompilationUnit
elemet használják az
IWorkingCopy
helyett.
(2) Az IBufferFactory
felületet a
WorkingCopyOwner
helyettesíti.
A működő példányok jobb támogatásához az szükséges, hogy egy objektum
birtokolja a működő példányokat. Annak ellenére, hogy az
IBufferFactory
a megfelelő helyen van, a név nem adja meg
megfelelően, hogy az új működő példány mechanizmus hogyan működik. A
WorkingCopyOwner
sokatmondóbb. A
WorkingCopyOwner
felület helyett absztrakt osztályként került
megadásra annak lehetővé tétele érdekében, hogy a működő példány
tulajdonos elképzelése kiértékelésre kerüljön a jövőben. The one method on IBufferFactory
moves to WorkingCopyOwner
unaffected. A
WorkingCopyOwner
nem valósítja meg az
IBufferFactory
elemet annak egyértelművé tétele érdekében,
hogy az IBufferFactory
a múlt eleme. Az
IBufferFactory
elavult. Az API más helyei, ahol az
IBufferFactory
paraméterként vagy eredménytípusként jelenik
meg, szintén elavultak; a helyettesítő API metódusok a
WorkingCopyOwner
elemet használják az
IBufferFactory
helyett.
Ezen módosítok nem törik meg a bináris kompatibilitást.
Átállításkor az IWorkingCopy
típusra mutató összes
hivatkozásnak a ICompilationUnit
elemre kell hivatkoznia. Az
IWorkingCopy
megvalósítása megvalósítja az
ICompilationUnit
típust is, vagyis az
IWorkingCopy
típusú objektumok nyugodtan adhatók meg
ICompilationUnit
típusúként.
Az IBufferFactory
elemet megvalósító osztálynak
helyettesítenie kell a WorkingCopyOwner
alosztályát. Annak
ellenére, hogy a WorkingCopyOwner
nem valósítja meg az
IBufferFactory
elemet, meg lehet határozni a
WorkingCopyOwner
alosztályait, amely megvalósítja az
IBufferFactory
elemet, és ezáltal létrehoz egy hidat a régi
és új elem között (az IBufferFactory
deklarálja a
createBuffer(IOpenable)
elemet, a
WorkingCopyOwner
pedig a
createBuffer(ICompilationUnit)
elemet; az
ICompilationUnit
kiterjeszti az IOpenable
elemet).
Mivel az IWorkingCopy
és IBufferFactory
módosításai összefüggenek, ajánlatos mindkettőt egyszerre kezelni. Az
elavulások részletei a következők:
IWorkingCopy
(org.eclipse.jdt.core
csomag)
public void commit(boolean, IProgressMonitor)
elavult.
ICompilationUnit
közvetlenül biztosítja:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
metódust
((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
metódusrapublic void destroy()
elavult.
ICompilationUnit
közvetlenül biztosítja:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
metódust ((ICompilationUnit)
wc).discardWorkingCopy()
metódusrapublic IJavaElement findSharedWorkingCopy(IBufferFactory)
elavult.
ICompilationUnit
közvetlenül biztosítja:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
az
IBufferFactory
elemet helyettesíti.public IJavaElement getOriginal(IJavaElement)
elavult.
IJavaElement
elem
biztosítja:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
metódust az
elt.getPrimaryElement()
metódusraIWorkingCopy.getOriginal
elemmel
ellentétben az IJavaElement.getPrimaryElement
nem ad vissza
null
értéket, ha a fogadó nem egy működő példány.public IJavaElement getOriginalElement()
elavult.
ICompilationUnit
közvetlenül biztosítja:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
metódust
((ICompilationUnit)
wc).getPrimary()
metódusraIWorkingCopy.getOriginalElement
metódussal ellentétben, az IWorkingCopy.getPrimary
nem ad
vissza null
értéket, ha a fogadó nem működő példány.public IJavaElement[] findElements(IJavaElement)
elavult.
ICompilationUnit
egységen
közvetlenül meg van adva.wc.findElements(elts)
metódust
((ICompilationUnit)
wc).findElements(elts)
metóduskéntpublic IType findPrimaryType()
elavult.
ICompilationUnit
egységen
közvetlenül meg van adva.wc.findPrimaryType()
metódust
((ICompilationUnit)
wc).findPrimaryType()
metódusrapublic IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
elavult.
ICompilationUnit
közvetlenül biztosítja:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
helyettesíti a IBufferFactory
elemet.public IJavaElement getWorkingCopy()
elavult.
ICompilationUnit
közvetlenül biztosítja:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
metódust
((ICompilationUnit)
wc).getWorkingCopy(null)
metódusrapublic IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
elavult.
ICompilationUnit
közvetlenül biztosítja:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
helyettesíti a IBufferFactory
elemet.public boolean isBasedOn(IResource)
elavult.
ICompilationUnit
közvetlenül biztosítja:
public boolean hasResourceChanged()
wc.isBasesOn(res)
metódust
((ICompilationUnit)
wc).hasResourceChanged()
metódusrapublic boolean isWorkingCopy()
elavult.
ICompilationUnit
egységen
közvetlenül meg van adva.wc.isWorkingCopy()
metódust
((ICompilationUnit)
wc).isWorkingCopy()
metódusrapublic IMarker[] reconcile()
elavult.
ICompilationUnit
közvetlenül biztosítja:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
metódust ((ICompilationUnit)
wc).reconcile(false, null)
metódusranull
értéket adott vissza; a helyettesítő metódus nem ad
vissza eredményt.public void reconcile(boolean, IProgressMonitor)
elavult.
ICompilationUnit
egységen
közvetlenül meg van adva.wc.reconcile(b,monitor)
metódust ((ICompilationUnit)
wc).reconcile(b.monitor)
metódusrapublic void restore()
elavult.
ICompilationUnit
egységen
közvetlenül meg van adva.wc.restore()
metódust ((ICompilationUnit)
wc).restore()
metóduskéntIType
(org.eclipse.jdt.core
csomag)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
elavult.
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
ICompilationUnit[]
típussá alakítását.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
elavult.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
ICompilationUnit[]
típussá alakítását.IClassFile
(org.eclipse.jdt.core
csomag)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
elavult.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
helyettesíti a IBufferFactory
elemet.JavaCore
(org.eclipse.jdt.core
csomag)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
elavult.
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
az
IBufferFactory
elemet helyettesíti.ICompilationUnit[]
IWorkingCopy[]
típussá alakítását.SearchEngine
(org.eclipse.jdt.core.search
csomag)
public SearchEngine(IWorkingCopy[])
elavult.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
ICompilationUnit[]
típussá alakítását.Az org.eclipse.help bedolgozó, amely az alkalmazás programozási felületeket és kiterjesztési pontokat tárolja a súgórendszer kiegészítéséhez és kiterjesztéséhez, és megjeleníti a súgót, csak alkalmazás programozási felületeket és kiterjesztési pontokat biztosítanak a súgóerőforrások kiegészítéséhez és eléréséhez. A bedolgozóban tárolt alapértelmezett súgó UI megvalósítás egy része az alkalmazás programozási felületekkel együtt átkerült egy új org.eclipse.help.base bedolgozóba a megvalósítás kiterjesztése érdekében. A Súgó UI kiegészítésére és a súgó megjelenítésére szolgáló alkalmazás programozási felületek és kiterjesztési pont átkerült az org.eclipse.ui bedolgozóba. Ez az átstrukturálás nagyobb rugalmasságot biztosít az alkalmazások számára a súgórendszert illetőleg; az új struktúra segítségével az alkalmazások az általános munkaterület alapján saját Súgó UI és/vagy Súgó megvalósítást biztosíthatnak, vagy teljes egészében kihagyhatják a súgórendszert.
Mivel az érintett kiterjesztési pontokat és API csomagokat csak maga a súgórendszer használja, nem valószínű, hogy ez a módosítás hatással van a meglévő bedolgozókra. Ezeket a teljesség kedvéért adjuk meg:
Egyéni kereséseket megvalósító új API került hozzáadásra a 3.0 verzióhoz. Az eredeti API elavult a 3.0 verzióban, és az ügyfeleket érdemes átírni az org.eclipse.search.ui és org.eclipse.search.ui.text csomagban lévő új alkalmazás programozási felületre.
Az ügyfeleknek létre kell hozniuk az ISearchQuery
,
ISearchResult
és ISearchResultPage
megvalósítását. Az ISearchResultPage
megvalósítást ezután
hozzá kell adni az új
org.eclipse.search.searchResultViewPages
kiterjesztési
ponthoz.
Az ISearchResult
és ISearchResultPage
alapértelmezett megvalósításai az org.eclipse.search.ui.text
csomagban kerülnek megadásra.
A 3.0 verzió előtt ha az SWT DirectoryDialog.setMessage(String string) vagy MessageBox.setMessage(String string) metódus nulla karaktersorozat-értékkel kerül meghívásra, akkor a párbeszédablak címében nem jelenik meg szöveg. Ez a viselkedés meghatározatlan (nulla átadása sosem engedélyezett) és problémát okoz a getMessage függvény esetén, amely nem adhat vissza nullát. A 3.0 kiadásban a nullérték átadása egy IllegalArgumentException kivételt eredményez. A specifikációk megváltoztak és jelölik ezt, egységessé téve a Dialog.setMessage szülőosztállyal. Ha a Dialog.setMessage osztályt használja, akkor győződjön meg róla, hogy az átadott karaktersorozat sosem nulla. Egyszerűen egy üres karaktersorozatot adjon át, ha a párbeszédablakot szöveg nélkül kívánja megjeleníteni.
A párhuzamos műveletek támogatás kifinomultabb módszert igényel a modális folyamat megjelenítéséhez. A válaszkészég részeként a további folyamattámogatás az IProgressService osztályban került megvalósításra. A meglévő módszer a folyamat ProgressMonitorDialog elemmel megjelenítése továbbra is működik. A felhasználói élmény javítása érdekében javasoljuk az új IProgressService elemre áttérést.
A Modális folyamat megjelenítése az Eclipse 3.0 verzióban dokumentum leírja, hogy hogyan kell áttérni az új IProgressService szolgáltatásra.
A Hibakeresés tevékenységcsoportok kiterjesztési pont (org.eclipse.debug.ui.debugActionGroups) eltávolításra került. Az Eclipse 3.0 verzióban a munkaterület az org.eclipse.platform.ui.activities kiterjesztési ponton keresztül támogatást vezetett be a Tevékenységekhez. Ez a támogatás biztosít mindent, amelyet a Hibakeresés tevékenységcsoportok biztosítottak és a használata egyszerűbb (támogatja a mintákat az összes tevékenység megadása helyett), és rendelkezik egy programozható alkalmazás programozási felülettel ennek támogatásához. A régi kiterjesztési pontra mutató hivatkozások eltávolításának meghiúsulása nem okoz hibát. A kiterjesztési pont hivatkozásai egyszerűen figyelmen kívül maradnak. A termékgyártók számára javasoljuk, hogy használják a munkaterület Tevékenységek funkciójának támogatását a nyelvspecifikus hibakeresési műveletek nyelvspecifikus tevékenységekkel társítása érdekében (például a C++ hibakeresési műveletek társíthatók egy "C++ fejlesztés" nevű tevékenységgel).
Az IBreakpointManager a setEnabled(boolean) és isEnabled() metódust adja meg. Ha a töréspontkezelő le van tiltva, akkor a hibakeresőknek az összes bejegyzett töréspontot figyelmen kívül kell hagyniuk. A hibakeresés platform egy új figyelőmechanizmust - IBreakpointManagerListener - is biztosít, amelynek segítségével az ügyfelek regisztrálhatók a töréspontkezelőhöz, hogy értesítést kapjanak az engedélyezettség változásáról. A Töréspontok nézet meghívja ezt az alkalmazás programozási felületet egy új átkapcsolás tevékenységből, amelynek segítségével a felhasználó "Átugorhatja az összes töréspontot." A töréspontkezelő engedélyezettségét nem elfogadó hibakeresők egyes dolgokat megszakítva jelenítenek meg, ha a felhasználó ezt a szolgáltatást próbálja használni.
A Java-közeli nyelveknek (mint például a JSP, SQLJ, JWS, stb.) részt kell tudniuk venni a Java keresésben. Az ilyen nyelvek megvalósítóinak az alábbiakat kell tudniuk:
Az ilyen megvalósítót keresés-résztvevőnek hívják. Ez kiterjeszti a SearchParticipant osztályt. A keresés-résztvevők átkerülnek a keresési lekérdezésekbe (lásd: SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
Az egyezések indexelésekor vagy keresésekor a keresés-résztvevőnek meg kell adnia a SearchDocument egy alosztályát, amely a getByteContents() vagy getCharContents() újradefiniálásával lekérheti a dokumentum tartalmát. A getDocument(String) ezen alosztály egy példányát adja vissza.
A keresés-résztvevő, amely indexelni kíván néhány dokumentumot, a SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) metódust fogja használni az adott dokumentum adott indexelés szerinti indexelésének ütemezéséhez. Ha a dokumentum készen áll az indexelésre, akkor az alapul szolgáló keretrendszer meghívja a SearchParticipant.indexDocument(SearchDocument, IPath) metódust. A keresés-résztvevő ezután veszi a dokumentum tartalmát, elemzi és a SearchDocument.addIndexEntry(char[], char[]) segítségével indexbejegyzéseket ad hozzá.
Ha az indexelés kész, akkor az indexek a SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) segítségével lekérhetők és az egyezések megkereshetők. Ez először a SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope) segítségével minden résztvevőtől lekéri a lekérdezéshez szükséges indexeket. Az adott mintának megfelelő indexbejegyzésekhez a keresés résztvevő lekérdezésével létrehozásra kerül egy keresési dokumentum (lásd getDocument(String)). Ezek a dokumentumok átkerülnek a keresés-résztvevőhöz, így a locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) segítségével megkeresheti az egyezéseket. A keresés-résztvevő az acceptSearchMatch(SearchMatch) segítségével értesíti a SearchRequestor elemet a keresési egyezésekről, és átadja a SearchMatch alosztály egyik példányát.
A keresés-résztvevő delegálhatja a munka egy részét az alapértelmezett Java keresés-résztvevőhöz. Ezen alapértelmezett résztvevő példánya a SearchEngine.getDefaultSearchParticipant() segítségével kerül lekérésre. Az egyezéskeresési kéréskor például az SQLJ résztvevő a .sqlj dokumentumokból létrehozhat .java dokumentumokat, és a .java dokumentumok segítségével delegálhatja a munkát az alapértelmezett résztvevőnek.