Tento oddíl popisuje změny, které jsou nutné, pokud se pokoušíte změnit svůj modul plug-in pro verzi 2.1 tak, aby adoptoval mechanizmy a rozhraní API verze 3.0.
Běhová komponenta platformy Eclipse verze 3.0 se výrazně liší. Základní implementace je založena na základě specifikace rámce OSGi. Běhová komponenta Eclipse 3.0 obsahuje vrstvu kompatibility (v modulu plug-in org.eclipse.core.runtime.compatibility), která udržuje rozhraní API verze 2.1. Vývojáři modulů plug-in, kteří se zajímají o přidaný výkon a funkce, by měli zvážit použití rozhraní API verze 3.0 a odebrání závislosti na úrovni vrstvy kompatibility. Kód pro kompatibilitu se vyskytuje na třech místech:
V níže uvedeném textu najdete další podrobnosti o tom, které třídy a metody jsou přítomny z důvodu kompatibility, a také návod, jak svůj modul plug-in aktualizovat.
Běhová komponenta Eclipse byla rozdělena do dvou částí: načítání tříd se správou nezbytných předpokladů a správu rozšíření/bodů rozšíření. Toto rozdělení umožňuje přirozené a hladké zavedení specifikace struktury OSGi pro načítání tříd a správu nezbytných předpokladů. To zase zpřístupňuje řadu nových schopností v běhové komponentě, od dynamické instalace/aktualizace/odinstalování modulů plug-in po zabezpečení a lepší konfigurovatelnost.
I když budeme nadále mluvit o modulech plug-in, v nové běhové komponentě je modul plug-in ve skutečnosti balíkem spolu s nějakými rozšířeními a body rozšíření. Termín balík je definován ve specifikaci struktury OSGi a označuje kolekci typů a prostředků spolu s přidruženými informacemi o mezibalíkových předpokladech. Registr rozšíření je nová forma registru modulů plug-in a obsahuje pouze podrobné informace o rozšířeních a bodech rozšíření. Celkově je rozhraní API registru rozšíření shodné s odpovídajícím rozhraním API registru modulů plug-in (viz Registry, kde najdete další informace).
V běhové komponentě Eclipse 2.x má objekt modulu plug-in množství rolí a zodpovědností:
V obrázku běhové komponenty Eclipse 3.0 jsou tyto role a zodpovědnosti rozloženy do samostatných objektů.
Třída Plugin také implementuje BundleActivator. To proto, že je pohodlné, když jeden centrální objekt reprezentuje životní cyklus a sémantiku modulu plug-in. Všimněte si nicméně, že se tím neschvaluje horlivá inicializace datových struktur, která je dnes v modulech plug-in běžná. Musíme stále zdůrazňovat, že moduly plug-in se mohou aktivovat i tím, že se během verifikace třídy v nějakém jiném modulu plug-in odkazovalo na poněkud periferní třídu. Tedy pouhá aktivace vašeho modulu plug-in ještě neznamená, že jsou jeho funkce potřebné. Rovněž vezměte na vědomí, že vám nic nebrání definovat si vlastní třídu BundleActivator nebo žádný aktivátor balíku nepoužít.
Kroky nezbytné k portování třídy Plugin pro verzi 2.x do Eclipse 3.0 záleží na tom, co třída dělá. Jak bylo nastíněno výše, většina práce na začátku životního cyklu spadá do jedné z následujících kategorií:
V nové běhové komponentě se oddělují informace a struktury potřebné ke spuštění modulu plug-in od těch, které se vztahují k rozšířením a bodům rozšíření modulu plug-in. První z nich definuje a spravuje specifikace rámce OSGi. Druhé z nich jsou koncepty specifickými pro Eclipse a přidává je kód běhové komponenty platformy Eclipse. Podobně se původní registr modulů plug-in a související objekty rozdělily do balíků struktury OSGi a registru rozšíření platformy Eclipse.
Části rozhraní IPluginRegistry, které se zabývají specifikací provedení (např. IPluginDescriptor, ILibrary, IPrequisite), jsou nyní nepřípustné a zbývající části související s rozšířeními a body rozšíření byly přesunuty do IExtensionRegistry. Dále, takzvané modelové objekty, které se týkají registru modulů plug-in jako celku, jsou nyní nepřípustné. Běhová komponenta nabízela tyto typy a vytvářela jejich instance zejména pro podporu nástrojů, jako např. prostředí PDE. Bohužel bylo častým případem, že úroveň potřebných informací překračovala schopnosti nebo zájmy běhové komponenty (např. pamatování si čísel řádků pro prvky souboru plugin.xml), takže nakonec si potenciální spotřebitelé informací běhové komponenty museli stejně udržovat své vlastní struktury.
V nové běhové komponentě jsme přehodnotili systémové prostředky poskytované běhovou komponentou a nyní poskytujeme pouze takové, které jsou buď nezbytné pro provádění běhové komponenty, nebo je jiní mohou provádět velmi obtížně. Jak bylo zmíněno výše, modelové objekty registru modulů plug-in i rozhraní API pro analýzu modulů plug-in jsou nyní nepřípustné. Nový registr rozšíření udržuje nezbytné informace související s rozšířeními. Nová struktura state (viz org.eclipse.osgi.service.resolver.State a spřátelené funkce) reprezentuje nezbytné informace související s prováděním a umožňuje s nimi manipulovat.
Struktura fragmentů NL byla v Eclipse 3.0 aktualizována, aby byla konzistentnější. Dříve se předpokládalo, že překlady souborů, jako např. plugin.properties, budou uvnitř souborů JAR dodaných fragmenty. Jelikož se původní soubory nalézají v kořenovém adresáři příslušného hostitelského modulu plug-in, konzistentnější by bylo umístit přeložené soubory do kořene fragmentů NL. Například
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Zde si všimněte, že soubor nl1.jar by dříve obsahoval překlady pro plugin.properties. Tyto soubory jsou nyní v kořenovém adresáři fragmentu a soubor JAR obsahuje překlady veškerých přeložitelných prostředků (tj. souborů načítaných pomocí zaváděče tříd) v hostitelském modulu plug-in.
Struktura fragmentů NL z Eclipse 2.1 NL je samozřejmě stále podporována pro hostitelské moduly plug-in z verze 2.1, které běží v Eclipse 3.0. Nemůžete však použít fragment NL z verze 2.1 v modulu plug-in pro verzi 3.0. Fragment je třeba aktualizovat na novou strukturu.
Celý balíček org.eclipse.core.boot je nyní nepřípustný. Třída BootLoader byla sloučena s org.eclipse.core.runtime.Platform, protože nadále nemá smysl rozdělovat zavádění a dobu běhu programu. Všimněte si, že modul plug-in org.eclipse.core.boot byl v podstatě rozebrán a veškerý jeho kód se přesunul buď do nové běhové komponenty, nebo do vrstvy kompatibility.
Rozhraní IPlatformConfiguration bylo vždy typem definovaným komponentou instalace/aktualizace platformy Eclipse a pro tuto komponentu. S reorganizací běhové komponenty můžeme tento typ vrátit do jeho právoplatného domovského umístění. Tato třída zůstává z větší části nezměněna a byla znovu sbalena jako org.eclipse.update.configurator.IPlatformConfiguration.
Rozhraní IPlatformRunnable bylo přesunuto do org.eclipse.core.runtime.IPlatformRunnable.
Metoda getDeclaringPlugin()
(v obou třídách) poskytuje propojení na nadřazený
modul plug-in, který deklaruje příslušné rozšíření nebo bod rozšíření.
Novy model registru odděluje aspekty provádění modulů plug-in od aspektů rozšíření/bodů rozšíření
a nadále neobsahuje rozhraní IPluginDescriptor.
Uživatelé tohoto rozhraní API by měli zvážit novou metodu getParentIdentifier(), která se nalézá
v rozhraní IExtension i IExtensionPoint.
V původní běhové komponentě udržoval registr modulů plug-in kompletní obrázek o konfiguraci běhové komponenty. V Eclipse 3.0 je tento obrázek rozdělen mezi strukturu OSGi a registr rozšíření. Tyto třídy jako takové byly označeny za nepřípustné. Upozornění na nepřípustnost obsahují podrobnosti o způsobu, jak byste měli svůj kód aktualizovat.
V nové běhové komponentě nejsou objekty Plugin nadále spravovány běhovou komponentou a tedy k nim nelze obecně přistupovat prostřednictvím třídy Platform. Podobně registr modulů plug-in nadále neexistuje a neposkytuje přístup k deskriptorům modulů plug-in. Nicméně dostupné jsou vhodné náhradní metody, které jsou podrobně popsány v dokumentaci Javadoc k nepřípustným metodám v těchto třídách.
Všechny typy v tomto balíčku jsou nyní nepřípustné. Viz diskuse o registrech, kde jsou další informace.
Klienti metody IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) by měli přezkoumat, jak tuto metodu používají, a zvážit použití bohatší metody IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Stará metoda IWorkspace.run získává zámek celého pracovního prostoru po dobu trvání IWorkspaceRunnable. To znamená, že operace prováděná pomocí této metody nikdy nebude schopna běžet souběžně s jinými operacemi, které upravují pracovní prostor. V Eclipse 3.0 bylo mnoho dlouhodobých operací přesunuto do vláken na pozadí, takže pravděpodobnost konfliktů mezi operacemi se výrazně zvýšila. Pokud je modální operace na popředí zablokována dlouhodobou operací na pozadí, uživatelské rozhraní se zablokuje, dokud se operace na pozadí nedokončí, nebo dokud se jedna z operací nezruší.
Navrženým řešením je přepnout všechny odkazy na starou metodu IWorkspace.run tak,
aby používaly novou metodu s parametrem pravidla plánování. Pravidlo plánování by mělo být
co nejjemnějším pravidlem, které zahrnuje pravidla pro všechny změny provedené touto
operací. Pokud se operace pokusí upravovat prostředky mimo rozsah pravidla plánování, vyskytne se běhová výjimka. Přesné pravidlo plánování, které požaduje daná operace pracovní plochy, není uvedeno
a může se měnit v závislosti na instalovaném poskytovateli úložiště v daném projektu.
K získání pravidla plánování pro operaci, která mění prostředky, by se měla použít
továrna IResourceRuleFactory
. V případě potřeby lze použít MultiRule
k určení více pravidel prostředků a pohodlnou metodu MultiRule.combine lze použít
ke sloučení pravidel z různých operací, které mění prostředky.
Není-li zamykání nezbytné, lze použít pravidlo plánování null. To umožní objektu procesu runnable upravovat všechny prostředky v pracovním prostoru, ale nezabrání jiným vláknům pracovní prostor souběžně také upravovat. Pro jednoduché změny pracovního prostoru je to často nejjednodušší a z hlediska souběžnosti nejvhodnější řešení.
filteredSelection
) z výběru (selection
):
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())); }
Nyní existuje explicitní pojem typu anotace. Viz Annotation.getType() a Annotation.setType(). Typ anotace se může po dobu jejího trvání změnit. Byl přidán nový bod rozšíření pro deklaraci typů anotací: "org.eclipse.ui.editors.annotationTypes". Typ anotace má název a může se deklarovat jako podtyp jiného deklarovaného typu anotace. Deklarace typu anotace může rovněž používat atributy "markerType" a "markerSeverity" k určení, že značkovače daného typu a dané závažnosti mají být v textových editorech reprezentovány jako anotace konkrétního typu. Atributy "markerType" a "markerSeverity" v "org.eclipse.ui.editors.markerAnnotationSpecification" by se neměly nadále používat. Specifikace anotací značkovačů se tedy stávají nezávislé na značkovačích a název je tedy zavádějící. Nicméně se název zachovává k zajištění zpětné kompatibility.
Instance podtříd třídy AbstractMarkerAnnotationModel automaticky detekují a nastavují správné typy anotací pro anotace, které vytvářejí ze značkovačů. Chcete-li v programu načíst typ anotace pro daný značkovač nebo daný pár atributů markerType a markerSeverity, použijte org.eclipse.ui.texteditor.AnnotationTypeLookup.
Přístup k hierarchii typů anotací poskytuje IAnnotationAccessExtension. Pro daný typ anotace můžete získat řetěz supertypů a zkontrolovat, zda je typ anotace podtypem jiného typu anotace. Třída DefaultMarkerAnnotationAccess implementuje toto rozhraní.
Typ anotace je klíčem, pomocí kterého se hledá přidružená specifikace anotace značkovače. Jelikož typy anotací mohou rozšiřovat jiné typy anotací, existuje také implicitní relace mezi specifikacemi anotací značkovačů. Proto je specifikace anotace značkovače pro daný typ anotace dokončena specifikacemi anotací značkovačů poskytnutých pro supertypy daného typu anotace. Specifikace anotací značkovačů tedy nemusí být úplné, což bylo dříve nezbytné. Specifikace anotací značkovačů se načítají s použitím AnnotationPreferences. Použijete-li org.eclipse.ui.texteditor.AnnotationPreferenceLookup, můžete načíst předvolbu anotace pro daný typ anotace, která transparentně provede dokončení předvolby podél řetězce supertypů anotací.
Specifikace anotace značkovače byla rozšířena o tři další atributy, aby umožňovala definovat vlastní vzhledy daného typu anotace ve vertikálním pravítku. Tyto atributy jsou: "icon", "symbolicIcon" a "annotationImageProvider". Hodnotou atributu "icon" je cesta k souboru, který obsahuje obrázek ikony. Atribut "symbolicIcon" může mít jednu z hodnot "error", "warning", "info", "task", "bookmark". Atribut "symbolicIcon" platformě říká, že se anotace má zobrazit se stejným obrázkem, jaký platforma používá pro prezentaci chyb, varování, informací, úloh a záložek. Hodnotou atributu "annotationImageProvider" je třída, která implementuje org.eclipse.ui.texteditor.IAnnotationImageProvider a umožňuje plně přizpůsobit prezentaci anotací.
Vertikální pravítko používá pro kreslení anotací svá přidružená rozhraní IAnnotationAccess/IAnnotationAccessExtension. Vertikální pravítko nadále nevolá metodu Annotation.paint. Obecně se anotace (Annotation) již nemají samy vykreslovat. Metody "paint" a "getLayer" jsou nyní nepřípustné, aby se anotace nakonec staly nezávislými na uživatelském rozhraní. DefaultMarkerAnnotationAccess slouží jako výchozí implementace rozhraní IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementuje pro vykreslování anotací následující strategii: Pokud anotace implementuje rozhraní IAnnotationPresentation, zavolá se IAnnotationPresentation.paint. Pokud ne, vyhledá se v předvolbě anotace poskytovatel obrázku anotace. Poskytovatel obrázku anotace je k dispozici pouze tehdy, pokud je specifikován a pokud byl již zaveden modul plug-in, který definuje zapouzdřující specifikaci anotace značkovače. Existuje-li poskytovatel obrázku anotace, volání se mu postoupí. Pokud ne, vyhledá se zadaná ikona ("icon"). Jako poslední možnost se použije atribut "symbolicIcon". Pro kreslení anotací je důležitá prezentační vrstva anotací. DefaultMarkerAnnotationAccess vyhledá prezentační vrstvu pomocí následující strategie: Pokud předvolba anotace uvádí prezentační vrstvu, použije se zadaná vrstva. Pokud žádná vrstva neexistuje a anotace implementuje rozhraní IAnnotationPresentation, použije se IAnnotationPresentation.getLayer, jinak se vrátí výchozí prezentační vrstva (což je 0).
Modul plug-in org.eclipse.ui.editors deklaruje následující typy anotací:
<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>
Definovaná rozšíření markerAnnotationSpecification nadále neposkytují atributy "markerType" a "markerSeverity". Definují atribut "symbolicIcon" s příslušnou hodnotou. Takže metody MarkerAnnotation.paint a MarkerAnnotation.getLayer se již nadále nevolají, tj. jejich předefinování nemá žádný efekt. Ovlivnění klienti by měli implementovat rozhraní IAnnotationPresentation.
Od zavedení rozšiřitelných režimů spuštění ve verzi 3.0 může pro daný typ konfigurace spuštění
existovat více delegátů spuštění. Verze starší než 3.0 podporovaly pouze
jednoho delegáta spuštění na typ konfigurace spuštění. Metoda ILaunchConfigurationType.getDelegate()
je nyní nepřípustná. Místo ní by se pro získání delegáta spuštění pro konkrétní režim spuštění
měla používat metoda getDelegate(String mode)
.
Nepřípustná metoda byla změněna tak, že vrací delegáta spuštění pro režim run
.
Skupiny karet spuštění a karty spuštění se nadále neupozorňují, když se spuštění
dokončí. Metoda launched(ILaunch)
v rozhraních ILaunchConfigurationTab
a ILaunchConfigurationTabGroup
je nyní nepřípustná a nadále se
nevolá. Spoléhání se na tuto metodu ve funkcích spuštění bylo vždy problematické, protože
karty existují pouze tehdy, když se spouštění provádí z dialogového okna spuštění.
Rovněž po zavedení spouštění na pozadí nelze tuto metodu nadále volat, protože
dialogové okno spuštění se zavře ještě předtím, než výsledný objekt spuštění začne existovat.
Do rozhraní ILaunchConfigurationTab
byly přidány dvě metody -
activated a deactivated. Tyto nové metody životního cyklu se volají při
vstupu do karty a při jejím opuštění. Stávající implementace rozhraní ILaunchConfigurationTab
,
jenž vytvářejí podtřídu abstraktní třídy, kterou poskytuje modul plug-in ladění (AbstractLaunchConfigurationTab
), jsou binárně kompatibilní, protože metody jsou v abstraktní třídě implementovány.
V předchozích verzích se kartě zasílala zpráva initializeFrom
při aktivaci
a zpráva performApply
při deaktivaci. Tímto způsobem struktura
karet konfigurace spuštění poskytovala komunikaci mezi kartami prostřednictvím
konfigurace spuštění (při opuštění karty se aktualizovala konfigurace s použitím
aktuálních hodnot atributů a aktualizovala se karta, do níž se právě
vstoupilo). Protože však mnoho karet komunikaci mezi kartami neprovádí, může to
být neefektivní. Rovněž nebyla možnost rozlišit mezi kartou, která se aktivuje,
a kartou, která poprvé zobrazuje zvolenou konfiguraci spuštění.
Nově přidané metody kartám umožňují rozeznávat mezi aktivací a inicializací
a mezi deaktivací a ukládáním aktuálních hodnot.
Výchozí implementace metody activated
, kterou poskytuje
abstraktní karta, volá metodu initializeFrom
. Výchozí implementace
metody deactivated
volá performApply
. Karty, které chtějí
využít výhod nového rozhraní API, by měly podle potřeby tyto metody předefinovat.
Obecný doporučený přístup pro karty, které neprovádí komunikaci mezi kartami,
je tyto metody znovu implementovat tak, aby nic nedělaly.
V předchozích verzích se přepínání perspektiv uvádělo v konfiguraci spuštění
prostřednictvím atributů konfigurace spuštění ATTR_TARGET_DEBUG_PERSPECTIVE
a
ATTR_TARGET_RUN_PERSPECTIVE
. Po přidání rozšiřitelných režimů spuštění
ve verzi 3.0 není tento přístup nadále přizpůsobitelný. Přepínání perspektiv se nyní
uvádí na základě typu konfigurace spuštění podle režimu spuštění, který konfigurace
spuštění podporuje. Do třídy DebugUITools
bylo přidáno rozhraní API pro
nastavení a získání perspektivy přidružené k typu konfigurace spuštění pro konkrétní
režim spuštění.
Do bodu rozšíření launchConfigurationTabGroup
se přidal nový volitelný
prvek launchMode
, který umožňuje vložené skupině karet určit výchozí
perspektivu pro režim a typ konfigurace spuštění.
Uživatelé mohou upravit perspektivu přidruženou k typu konfigurace spuštění z uživatelského rozhraní platformy Eclipse tak, že otevřou dialogové okno konfigurace spuštění a vyberou uzel typu konfigurace spuštění ze stromu (místo individuální konfigurace). Zobrazí se karta, která uživateli umožňuje nastavit perspektivu pro každý podporovaný režim spuštění.
Do třídy VMRunnerConfiguration
byly přidány dvě metody pro podporu nastavování a načítání
proměnných prostředí. Implementátory rozhraní IVMRunner
by měly volat
VMRunnerConfiguration.getEnvironment()
a toto prostředí předat spuštěnému
prostředí JVM. Klienti, kteří používají DebugPlugin.exec(String[]
cmdLine, File workingDirectory)
, to mohou místo toho udělat zavoláním DebugPlugin.exec(String[]
cmdLine, File workingDirectory, String[] envp)
. Postačí jednoduché předání výsledku z
getEnvironment()
.
V předchozích verzích měla třída VMRunnerConfiguration
jeden atribut pro
popsání cesty zavedení systému. Atribut je kolekcí hodnot typu String
, které
se uvádějí v argumentu -Xbootclasspath
. Do třídy WMRunnerConfiguration
byly přidány tři nové atributy pro podporu prostředí JVM, která dovolují připojování
na začátek a na konec cesty zavedení systému. Nové přidané metody/atributy
jsou:
getPrependBootClassPath()
- vrátí kolekci položek, které se mají
připojit na začátek cesty zavedení systému (argumentu -Xbootclasspath/p
)
getMainBootClassPath()
- vrátí kolekci položek, které se mají
umístit do cesty zavedení systému (argumentu -Xbootclasspath
)
getAppendBootClassPath()
- vrátí kolekci položek, které se mají
připojit na konec cesty zavedení systému (argumentu -Xbootclasspath/a
)Starý atribut getBootClassPath()
stále existuje a obsahuje úplnou cestu
ekvivalentní těmto třem novým atributům. Nicméně objekty VMRunner
, které
podporují nové volby cesty zavedení systému, by měly využít nové atributy.
Prostředky modelu Java pro pracovní kopie byly ve verzi 3.0 přepracovány a poskytují výrazně vylepšenou funkčnost. Před verzí 3.0 umožňoval Java model vytváření jednotlivých pracovních kopií kompilačních jednotek. Bylo možno provádět změny na pracovní kopii a později je potvrdit. Existovala podpora omezené analýzy pracovní kopie v kontextu zbytku Java modelu. Nicméně neexistoval způsob, jak by tyto analýzy mohly vzít v úvahu více než jednu z těchto pracovních kopií současně.
Změny ve verzi 3.0 umožňují vytvářet a spravovat sady pracovních kopií kompilačních jednotek a provádět analýzy za přítomnosti všech pracovních kopií v sadě. Například je nyní možné, aby klient podobný opětovné deklaraci JDT vytvořil pracovní kopie jedné nebo více kompilačních jednotek, u kterých zvažuje změny, a pak mezi pracovními kopiemi vyřešil typové závislosti. To bylo dříve možné pouze poté, co byly změny v pracovních kopiích kompilačních jednotek potvrzeny.
Rozhraní API Java modelu si pro přidání této vylepšené podpory vyžádalo dvě změny:
(1) Funkčnost, která se dříve nacházela v rozhraní IWorkingCopy
a
dědilo ji rozhraní ICompilationUnit
, se sloučila do rozhraní ICompilationUnit
.
Rozhraní IWorkingCopy
se používalo pouze v tomto jednom místě a bylo
mnohem obecnější, než bylo třeba. Tato změna rozhraní API zjednodušuje. Rozhraní IWorkingCopy
je nyní nepřípustné. Další místa v rozhraní API, kde se IWorkingCopy
používá
jako parametr nebo typ výsledku, jsou nyní rovněž nepřípustná; náhradní metody rozhraní API
zmiňují místo IWorkingCopy
rozhraní ICompilationUnit
.
(2) Rozhraní IBufferFactory
bylo nahrazeno třídou WorkingCopyOwner
.
Vylepšená podpora pracovních kopií vyžaduje, aby existoval objekt, který pracovní
kopie vlastní. Ačkoliv je IBufferFactory
na správném místě, název nedává
patřičně najevo, jak nový mechanizmus pracovních kopií funguje. Název WorkingCopyOwner
naznačuje mnohem více. Kromě toho se WorkingCopyOwner
deklaruje jako
abstraktní třída, nikoliv rozhraní, aby se koncept vlastníka pracovní kopie mohl
v budoucnu dále rozvíjet. Jediná metoda rozhraní IBufferFactory
se
beze změny přesunula do třídy WorkingCopyOwner
. Třída WorkingCopyOwner
neimplementuje rozhraní IBufferFactory
, aby bylo zřejmé, že IBufferFactory
je záležitostí minulosti. Rozhraní IBufferFactory
je nyní nepřípustné. Další místa
v rozhraní API, kde se IBufferFactory
objevuje jako parametr nebo typ výsledku,
jsou nyní rovněž nepřípustná; náhradní metody rozhraní API zmiňují místo
rozhraní IBufferFactory
třídu WorkingCopyOwner
.
Tyto změny nenarušují binární kompatibilitu.
Při migraci by se všechny odkazy na typ IWorkingCopy
měly místo toho
odkazovat na ICompilationUnit
. Jediná implementace rozhraní IWorkingCopy
implementuje rovněž ICompilationUnit
, což znamená, že objekty typu IWorkingCopy
lze bezpečně přetypovat na ICompilationUnit
.
Třídu, která implementuje IBufferFactory
, bude třeba nahradit
podtřídou třídy WorkingCopyOwner
. Ačkoliv třída WorkingCopyOwner
sama neimplementuje rozhraní IBufferFactory
, bylo by možné deklarovat podtřídu
třídy WorkingCopyOwner
, která implementuje IBufferFactory
a tudíž
vytváří most mezi starým a novým přístupem (IBufferFactory
deklaruje createBuffer(IOpenable)
, zatímco WorkingCopyOwner
deklaruje createBuffer(ICompilationUnit)
; ICompilationUnit
rozšiřuje IOpenable
).
Protože změny zahrnující IWorkingCopy
a IBufferFactory
jsou navzájem provázané, doporučujeme se jimi zabývat současně. Podrobnosti o
nepřípustnostech následují:
IWorkingCopy
(balíček org.eclipse.jdt.core
)
public void commit(boolean, IProgressMonitor)
je nyní
nepřípustná.
ICompilationUnit
:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
na ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
public void destroy()
je nyní nepřípustná.
ICompilationUnit
:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
na ((ICompilationUnit)
wc).discardWorkingCopy()
public IJavaElement findSharedWorkingCopy(IBufferFactory)
je nyní nepřípustná.
ICompilationUnit
:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
je náhradou za IBufferFactory.
public IJavaElement getOriginal(IJavaElement)
je nyní
nepřípustná.
IJavaElement
:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
na elt.getPrimaryElement()
IWorkingCopy.getOriginal
metoda IJavaElement.getPrimaryElement
nevrací hodnotu null
, pokud příjemce není pracovní kopií.public IJavaElement getOriginalElement()
je nyní
nepřípustná.
ICompilationUnit
:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
na ((ICompilationUnit)
wc).getPrimary()
IWorkingCopy.getOriginalElement
metoda IWorkingCopy.getPrimary
nevrací hodnotu null
, pokud příjemce není pracovní kopií.public IJavaElement[] findElements(IJavaElement)
je nyní
nepřípustná.
ICompilationUnit
.wc.findElements(elts)
na ((ICompilationUnit)
wc).findElements(elts)
public IType findPrimaryType()
je nyní nepřípustná.
ICompilationUnit
.wc.findPrimaryType()
na ((ICompilationUnit)
wc).findPrimaryType()
public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
je nyní nepřípustná.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
je náhradou za IBufferFactory.
public IJavaElement getWorkingCopy()
je nyní nepřípustná.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
na ((ICompilationUnit)
wc).getWorkingCopy(null)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
je nyní nepřípustná.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
je náhradou za IBufferFactory.
public boolean isBasedOn(IResource)
je nyní nepřípustná.
ICompilationUnit
:
public boolean hasResourceChanged()
wc.isBasesOn(res)
na ((ICompilationUnit)
wc).hasResourceChanged()
public boolean isWorkingCopy()
je nyní nepřípustná.
ICompilationUnit
.wc.isWorkingCopy()
na ((ICompilationUnit)
wc).isWorkingCopy()
public IMarker[] reconcile()
je nyní nepřípustná.
ICompilationUnit
:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
na ((ICompilationUnit)
wc).reconcile(false, null)
null
; náhradní
metoda nevrací žádný výsledek.public void reconcile(boolean, IProgressMonitor)
je nyní
nepřípustná.
ICompilationUnit
.wc.reconcile(b,monitor)
na ((ICompilationUnit)
wc).reconcile(b,monitor)
public void restore()
je nyní nepřípustná.
ICompilationUnit
.wc.restore()
na ((ICompilationUnit)
wc).restore()
IType
(balíček org.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
je nyní nepřípustná.
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
na ICompilationUnit[]
.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
je nyní nepřípustná.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
na ICompilationUnit[]
.IClassFile
(balíček org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
je nyní nepřípustná.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
je náhradou za IBufferFactory.
JavaCore
(balíček org.eclipse.jdt.core
)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
je nyní nepřípustná.
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
je náhradou za IBufferFactory.
ICompilationUnit[]
na IWorkingCopy[]
.SearchEngine
(balíček org.eclipse.jdt.core.search
)
public SearchEngine(IWorkingCopy[])
je nyní nepřípustná.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
na ICompilationUnit[]
.Modul plug-in org.eclipse.help, který udržuje rozhraní API a body rozšíření pro přispívání do systému nápovědy a jeho rozšiřování a také pro zobrazování nápovědy, nyní obsahuje pouze rozhraní API a body rozšíření pro přispívání do prostředků nápovědy a přístup k nim. Část výchozí implementace uživatelského rozhraní nápovědy obsažená v tomto modulu plug-in byla přesunuta do nového modulu plug-in org.eclipse.help.base spolu s rozhraními API pro rozšiřování implementace. Rozhraní API a bod rozšíření pro přispívání do uživatelského rozhraní nápovědy a zobrazování nápovědy se přesunuly do modulu plug-in org.eclipse.ui. Tato restrukturalizace umožňuje aplikacím větší tvárnost s ohledem na systém nápovědy; nová struktura umožňuje aplikacím založeným na obecné pracovní ploše poskytovat jejich vlastní uživatelské rozhraní nápovědy a implementaci nápovědy, nebo systém nápovědy úplně vynechat.
Protože ovlivněné body rozšíření a balíčky API jsou určeny pouze pro použití samotným systémem nápovědy, je nepravděpodobné, že by tato změna ovlivnila stávající moduly plug-in. Zde jsou uvedeny pouze pro úplnost:
Ve verzi 3.0 bylo přidáno nové rozhraní API pro implementaci přizpůsobeného vyhledávání. Původní rozhraní API je ve verzi 3.0 nepřípustné a doporučujeme portovat klienty na nové rozhraní API v balíčcích org.eclipse.search.ui a org.eclipse.search.ui.text.
Klienti budou muset vytvořit implementace rozhraní ISearchQuery
, ISearchResult
a ISearchResultPage
. Implementací ISearchResultPage
je pak třeba přispět do nového bodu rozšíření org.eclipse.search.searchResultViewPages
.
Výchozí implementace rozhraní ISearchResult
a ISearchResultPage
poskytuje balíček org.eclipse.search.ui.text
.
Před verzí 3.0 bylo výsledkem volání metod SWT DirectoryDialog.setMessage(String string) nebo MessageBox.setMessage(String string) s prázdnou hodnotou parametru string dialogové okno bez textu v titulku. Toto chování nebylo specifikováno (předání hodnoty null nebylo nikdy povoleno) a přináší problémy s metodou getMessage, která nesmí vrátit hodnotu null. Ve verzi 3.0 nyní předání hodnoty null vyvolá výjimku IllegalArgumentException; specifikace byly změněny, aby toto obsahovaly a uvedly do souladu s metodou supertřídy Dialog.setMessage. Pokud používáte Dialog.setMessage, zajistěte, aby předávaný řetězec nikdy neměl hodnotu null. Chcete-li zobrazit dialogové okno bez textu v titulku, jednoduše předejte prázdný řetězec.
Podpora souběžných operací vyžaduje důmyslnější způsoby, jak zobrazit modální průběh. Jako součást úsilí o zlepšení odezvy byla implementována dodatečná podpora indikace průběhu ve třídě IProgressService. Stávající způsob zobrazování indikace průběhu pomocí třídy ProgressMonitorDialog stále funguje. Avšak pro zlepšení zkušeností uživatele doporučujeme migrovat na IProgressService.
Dokument Zobrazování modální indikace průběhu v Eclipse 3.0 popisuje, jak migrovat na nový způsob používající IProgressService.
Bod rozšíření pro skupiny akcí ladění (org.eclipse.debug.ui.debugActionGroups) byl odebrán. V Eclipse 3.0 pracovní plocha zavedla podporu aktivit prostřednictvím bodu rozšíření org.eclipse.platform.ui.activities. Tato podpora rovněž poskytuje vše, co poskytovaly skupiny akcí ladění, rovněž se snáze používá (místo úplného určení všech jednotlivých akcí podporuje vzory) a pro svou podporu má programové rozhraní API. Neodebrání odkazů na starý bod rozšíření nezpůsobí žádná selhání. Odkazy na bod rozšíření se budou jednoduše ignorovat. Dodavatelům produktů doporučujeme, aby pro přiřazování akcí ladění specifických pro jazyk k aktivitám specifickým pro jazyk používali podporu aktivit pracovní plochy (například akce ladění pro jazyk C++ se mohou asociovat s aktivitou nazvanou "Vývoj C++").
Rozhraní IBreakpointManager nyní definuje metody setEnabled(boolean) a isEnabled(). Když je správce bodů přerušení znepřístupněn, ladicí programy by měly ignorovat všechny registrované body přerušení. Platforma ladění rovněž poskytuje nový mechanizmus listenerů, IBreakpointManagerListener, který klientům umožňuje registrovat se u správce bodů přerušení a dostat upozornění, když se jeho zpřístupnění změní. Pohled Body přerušení volá toto rozhraní API z nové přepínací akce, která umožňuje uživateli "Přeskočit všechny body přerušení". Ladicí programy, které nedodržují zpřístupnění správce bodů přerušení, budou tedy vypadat poněkud narušené, pokud se uživatel pokusí tuto funkci použít.
Jazyky blízké jazyku Java (např. JSP, SQLJ, JWS, atd.) by se měly být schopny účastnit hledání v kódu Java. Implementátory takových jazyků by konkrétně měly být schopny:
Takový implementátor se nazývá účastník hledání. Rozšiřuje třídu SearchParticipant. Účastníci hledání se předávají vyhledávacím dotazům (viz SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
Pro indexaci nebo vyhledání shod musí účastník hledání definovat podtřídu třídy SearchDocument, která umí načíst obsah dokumentu, a to předefinováním buď getByteContents(), nebo getCharContents(). Instance této podtřídy se vrátí v getDocument(String).
Účastník hledání, který chce indexovat nějaký dokument, použije metodu SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) k naplánování indexace daného dokumentu do daného rejstříku. Jakmile je dokument připraven k indexování, základní rámec zavolá SearchParticipant.indexDocument(SearchDocument, IPath). Účastník hledání pak získá obsah dokumentu, zanalyzuje jej a přidá položky rejstříku pomocí metody SearchDocument.addIndexEntry(char[], char[]).
Jakmile je indexace hotova, lze se rejstříků dotazovat a vyhledávat shody pomocí metody SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Ta nejprve požádá každého účastníka hledání o rejstříky, které jsou pro tento dotaz potřebné, pomocí metody SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). Pro každou položku rejstříku, která vyhovuje danému vzoru, účastníka hledání požádá o vytvoření dokumentu hledání (viz getDocument(String)). Všechny tyto dokumenty se předají účastníku hledání, aby mohl nalézt shody pomocí locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). Účastník hledání upozorní SearchRequestor na nalezené shody pomocí acceptSearchMatch(SearchMatch) a předáním instance podtřídy třídy SearchMatch.
Účastník hledání může delegovat část své práce na výchozího účastníka hledání v kódu Java. Instance tohoto výchozího účastníka se získá pomocí SearchEngine.getDefaultSearchParticipant(). Je-li například účastník SQLJ požádán o nalezení shod, může ze svých dokumentů .sqlj vytvořit dokumenty .java a delegovat práci na výchozího účastníka tím, že mu předá dokumenty .java.