Denne delen beskriver endringer som er nødvendige hvis du prøver å endre en plugin-modul fra 2.1 slik at den tar i bruk mekanismene og APIene for 3.0.
Eclipse 3.0-kjøretiden er betydelig forandret. Den underliggende implementeringen er basert på spesifikasjonen for OSGi-rammeverket. Eclipse 3.0-kjøretiden inkluderer et kompatibilitetslag (i plugin-modulen org.eclipse.core.runtime.compatibility) som vedlikeholder 2.1-APIene. Plugin-utviklere som er interessert i ekstra ytelse og funksjonalitet, bør vurdere å ta i bruke APIene for 3.0 og fjerne avhengigheten av kompatibilitetslaget. Kompatibilitetskode blir vist på tre steder:
Teksten nedenfor inneholder flere opplysninger om hvilke klasser og metoder som finnes av kompatibilitetshensyn, i tillegg til retningslinjer for oppdatering av plugin-modulen.
Eclipse-kjøretiden er refaktorisert til to deler: Klasselasting og nødvendig styring, og styring av utvidelse/utvidelsespunkt. Denne delingen tillater naturlig/sømløs adoptering av spesifikasjonen av OSGi-rammeverk for klasselasting og obligatorisk styring. Dette aktiverer så en serie av ny funksjonalitet i kjøretiden fra installering/oppdatering/avinstallering av dynamisk plugin-modul til sikkerhet og forbedret konfigurerbarhet.
Mer om plugin-moduler: I den nye kjøretiden er en plugin-modul i virkeligheten en bunt pluss noen utvidelser og utvidelsespunkter. Begrepet bunt er definert av spesifikasjonen av OSGi-rammeverket, og det refererer til en samling av typer og ressurser og tilknyttet obligatorisk buntinformasjon. Utvidelsesregisteret er den nye formen for plugin-register, og det inneholder bare informasjon om utvidelser og utvidelsespunkter. APIet for utvidelsesregisteret er stort sett det samme som det relevante APIet for plugin-registeret (du finner mer informasjon under Registre).
I Eclipse 2.x-kjøretiden har plugin-objektet flere roller og ansvarsområder:
I Eclipse 3.0-kjøretiden faktoriseres disse rollene og ansvarsområdene til distinkte objekter.
Plugin implementerer også BundleActivator. Den gjenkjenner fordelen med å ha ett sentralt objekt som representerer livssyklusen og semantikken for en plugin-modul. Du bør imidlertid være oppmerksom på at dette ikke sanksjonerer den stadige initialiseringen av datastrukturer som er vanlig i plugin-moduler i dag. Vi kan ikke fremheve sterkt nok at plugin-moduler kan aktiveres på grunn av at det blir referert til en noe perifer klasse under verifiseringen av en klasse i en annen plugin-modul. Det vil si at selv om plugin-modulen blir aktivert, betyr det ikke nødvendigvis at funksjonen er nødvendig. Vær også oppmerksom på at du kan definere en annen BundleActivator-klasse, eller at du ikke trenger å ha en buntaktivator i det hele tatt.
Trinnene som er nødvendig for å portere Plugin-klasse for 2.x til Eclipse 3.0, avhenger av hva klassen gjør. Som beskrevet ovenfor tilhører det meste av livssyklusarbeidet for oppstart en av disse kategoriene:
I den nye kjøretiden er det et skille mellom informasjonen og strukturene som trengs for å utføre en plugin-modul, og som er relatert til en plugin-moduls utvidelser og utvidelsespunkter. Den første delen defineres og styres spesifikasjonen av OSGi-rammeverket. Den andre delen er Eclipse-spesifikke konsepter og er tilføyd av koden for Eclipse-kjøretiden. Det opprinnelige plugin-registeret og de relaterte objektene er delt i henholdsvis OSGi-bunter og Eclipses utvidelsesregister.
De delene av IPluginRegistry som gjelder utføringsspesifikasjon (for eksempel IPluginDescriptor, ILibrary, IPrequisite) er foreldet, og de resterende delene som gjelder utvidelser og utvidelsespunkter, er flyttet til IExtensionRegistry. Videre er de såkalte modellobjektene som er knyttet til plugin-registeret, nå foreldet i sin helhet. Det ble opprettet forekomst av disse typene og de ble presentert av kjøretiden hovedsakelig for å støtte verktøy som PDE. Uheldigvis skjedde det ofte at det nødvendige informasjonsnivået overskred kjøretidens funksjonalitet eller interesser (for eksempel huske linjenumre for plugin.xml-elementer), og til sist måtte de potensielle konsumentene av kjøretidens informasjon vedlikeholde sine egne strukturer likevel.
I den nye kjøretiden har vi revurdert kjøretidens funksjoner, og leverer nå bare de som enten er viktige for kjøretidsutføring eller er svært vanskelige for andre å utføre. Som nevnt ovenfor, er både plugin-registerets modellobjekter og analyse-APIet for plugin-moduler foreldet. Det nye utvidelsesregisteret vedlikeholder den viktigste utvidelsesrelaterte informasjonen. En ny state-struktur (se org.eclipse.osgi.service.resolver.State og venner) som representerer og tillater endringen av den viktigste utføringsrelaterte informasjonen.
I Eclipse 3.0 er NL-fragmentstrukturen oppdatert til å bli mer konsistent. Tidligere ble det antatt at oversettelser av filer som plugin.properties fantes i JAR-filer som leveres av fragmenter. Siden de opprinnelige filene ligger i roten av den relevante verts-plugin-modulen, vil en mer konsistent plassering få de oversatte filene plassert i roten av NL-fragmentene. Eksempel:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Vær oppmerksom på at filen nl1.jar tidligere inneholdt oversettelsene av plugin.properties. Disse filene ligger nå i roten av fragmentet, og JAR-filen inneholder oversettelser av eventuelle oversettbare ressurser (det vil si filer som lastes inn via klasselasteren) i verts-plugin-modulen.
NL-fragmentstrukturen fra Eclipse 2.1 støttes selvsagt fremdeles for plugin-moduler fra 2.1 som kjøres i Eclipse 3.0. Du kan imidlertid ikke bruke et NL-fragment fra 2-1 i en 3.0-plugin. Fragmentet må oppdateres til den nye strukturen.
Hele org.eclipse.core.boot-pakken er foreldet. BootLoader er slått sammen med org.eclipse.core.runtime.Platform fordi det ikke lenger virker fornuftig å ha en deling mellom oppstart og kjøretid. Vær oppmerksom på at plugin-modulen org.eclipse.core.boot faktisk er delt opp, og all koden er flyttet til enten den nye kjøretiden eller kompatibilitetslaget.
IPlatformConfiguration har alltid vært en type som er definert av og for Eclipse-komponenten Installer/oppdater. Ved hjelp av omorganiseringen av kjøretiden kan vi plassere denne typen der den hører hjemme. Denne klassen forblir stort sett uendret, og den er ompakket som org.eclipse.update.configurator.IPlatformConfiguration.
IPlatformRunnable er flyttet til org.eclipse.core.runtime.IPlatformRunnable.
Metoden getDeclaringPlugin()
(i begge klasser)
gir en link oppover til plugin-modulen som deklarerer utvidelsen eller
utvidelsespunktene (henholdsvis).
Den nye registermodellen skiller
utvidelsesaspektet for plugin-moduler fra utvidelses-/utvidelsespunktaspektene, og
inneholder ikke lenger IPluginDescriptors.
Brukere av dette APIet
bør vurdere den nye metoden getParentIdentifier(), som finnes for både
IExtension og IExtensionPoint.
I den opprinnelige kjøretiden vedlikeholdt plugin-registeret et fullstendig bilde av kjøretidskonfigurasjonen. I Eclipse 3.0 er dette bildet delt på OSGi-rammeverket og utvidelsesregisteret. Disse klassene er foreldet. Foreldelsesmerknadene inneholder detaljert informasjon om hvordan du kan oppdatere koden.
I den nye kjøretiden styres ikke Plugin-objekter lenger av kjøretiden, og det er dermed ikke mulig å få generisk tilgang til dem via plattformen. På liknende måte finnes ikke plugin-registeret lenger eller det gir ikke tilgang til plugin-deskriptorer. Det finnes imidlertid passende erstatningsmetoder som er beskrevet i Javadoc for de foreldede metodene i disse klassene.
Alle typene i denne pakken blir nå foreldet. Du finner mer informasjon i diskusjonen om registre.
Klienter av metoden IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) bør gå tilbake til denne metoden igjen, og vurdere å bruke den mer omfattende metoden IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Den gamle IWorkspace.run-metoden låser hele arbeidsområdet i hele varigheten av IWorkspaceRunnable. Dette betyr at en operasjon som er utført med denne metoden, aldri vil kunne kjøre samtidig med andre operasjoner som endrer arbeidsområdet. I Eclipse 3.0 kan mange operasjoner med lang kjøretid være flyttet til bakgrunnstråder, slik at sannsynligheten for konflikter mellom operasjoner økes betraktelig. Hvis en modal forgrunnsoperasjon er blokkert av en bakgrunnsoperasjon med lang kjøretid, blir brukergrensesnittet blokkert til bakgrunnsoperasjonen er fullført, eller til en av operasjonene avbrytes.
Den foreslåtte løsningen er å endre alle referanser til den gamle IWorkspace.run
til å bruke den nye metoden med en planleggingsregelparameter. Planleggingsregelen
bør være den mest finkornede regelen som omfatter reglene for alle endringer
av denne operasjonen. Hvis operasjonen prøver å endre ressurser
utenfor planleggingsregelens omfang, oppstår et kjøretidsunntak. Nøyaktig hvilken
planleggingsregel som kreves av en gitt operasjon, oppgis ikke, og det kan endres avhengig
av leverandøren av det installerte datalageret for et gitt prosjekt. IResourceRuleFactory
-factory
bør brukes til å hente planleggingsregelen for en
ressursendrende operasjon. Hvis det er ønskelig, kan en MultiRule brukes
til å oppgi flere ressursregler, og metoden MultiRule.combine kan brukes til å kombinere
regler fra forskjellige ressursendrende operasjoner.
Hvis det ikke er nødvendig med en lås, kan en null-planleggingsregel brukes. Dette vil gjøre at den kjørbare kan endre alle ressurser i arbeidsområdet, men det vil ikke hindre at andre tråder også endrer det samtidig. Hvis du skal gjøre enkle endringer i arbeidsområdet, er dette ofte den enkleste og mest samtidighetsvennlige løsningen.
filteredSelection
fra 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())); }
Annotasjonstype er nå et eksplisitt begrep. Se Annotation.getType() og Annotation.setType(). En annotasjonstype kan bli endret i løpet av annotasjonens levetid. Det er lagt til et nytt utvidelsespunkt for deklareringen av annotasjonstyper: org.eclipse.ui.editors.annotationTypes. En annotasjonstype har et navn og kan deklareres som en subtype av en annen deklarert annotasjonstype. En annotasjonstypedeklarasjon kan også bruke attributtene markerType og markerSeverity til å oppgi at merker av en gitt type og med en gitt alvorsgrad skal representeres i tekstredigeringsprogrammer som annotasjoner av en bestemt annotasjonstype. Attributtene markerType og markerSeverity i org.eclipse.ui.editors.markerAnnotationSpecification skal ikke lenger brukes. Spesifikasjoner av merkeannotasjoner blir derved uavhengig av merker, og navnet er derfor villedende. Navnet blir imidlertid beholdt for å sikre tilbakekompatibilitet.
Forekomster av subklasser av AbstractMarkerAnnotationModel oppdager og definerer automatisk de riktige annotasjonstypene for annotasjoner de oppretter fra merker. Når du skal hente annotasjonstypen programmatisk for et gitt merke eller et gitt par av markerType og markerSeverity, bruker du org.eclipse.ui.texteditor.AnnotationTypeLookup.
Tilgang til hierarkiet av annotasjonstyper gis av IAnnotationAccessExtension. For en gitt annotasjonstype kan du hente kjeden av supertyper og kontrollere om en annotasjonstype er en subtype av en annen annotasjonstype. DefaultMarkerAnnotationAccess implementerer dette grensesnittet.
Annotasjonstypen er nøkkelen som brukes til å finne den tilknyttede merkeannotasjonsspesifikasjonen. Siden annotasjonstyper kan utvide andre annotasjonstyper, finnes det også et implisitt forhold mellom merkeannotasjonsspesifikasjoner. Derfor fullføres en merkeannotasjonsspesifikasjon for en gitt annotasjonstype av merkeannotasjonsspesifikasjonene som er gitt for supertypene av den gitte annotasjonstypen. Merkeannotasjonsspesifikasjonen trenger derfor ikke å være fullstendig slik den måtte tidligere. Merkeannotasjonsspesifikasjoner hentes av AnnotationPreferences. Ved hjelp av org.eclipse.ui.texteditor.AnnotationPreferenceLookup kan du hente en annotasjonspreferanse for en gitt annotasjonstype som transparent utfører fullføringen av preferansen sammen med supertypekjeden for annotasjonen.
En merkeannotasjonsspesifikasjon er utvidet med tre tilleggsattributter slik at det blir mulig å definere tilpassede utseender for en gitt annotasjonstype i den loddrette linjalen. Disse attributtene er "icon", "symbolicIcon" og "annotationImageProvider". Verdien for "icon" er banen til en fil som inneholder ikonbildet. Verdien for "symbolicIcon" kan være en av "error", "warning", "info", "task" eller "bookmark". Attributtet "symbolicIcon" brukes til å fortelle plattformen at annotasjonen skal bruke de samme bildene som de som brukes av plattformen til å presentere henholdsvis feil, advarsler, info, oppgaver og bokmerker. Verdien for "annotationImageProvider" er en klasse som implementerer org.eclipse.ui.texteditor.IAnnotationImageProvider som tillater presentasjon av en fullstendig tilpasset annotasjon.
Den loddrette linjalen bruker den tilknyttede IAnnotationAccess/IAnnotationAccessExtension til å tegne annotasjoner. Den loddrette linjalen sender ikke lenger kall til Annotation.paint. Generelt sett skal annotasjoner ikke lenger tegne seg selv. Metodene "paint" og "getLayer" er foreldet fordi det er meningen at annotasjoner skal bli uavhengige av brukergrensesnitt. DefaultMarkerAnnotationAccess tjener som standardimplementering av IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementerer den følgende strategien for tegning av annotasjoner: Hvis en annotasjon implementerer IAnnotationPresentation, sendes det kall til IAnnotationPresentation.paint. Hvis ikke, blir det slått opp på annotasjonsbildeleverandøren i annotasjonspreferansene. Annotasjonsbildeleverandøren er bare tilgjengelig hvis den er oppgitt, og hvis plugin-modulen som definerer den innkapslende merkeannotasjonsspesifikasjonen, allerede er lastet inn. Hvis det finnes en annotasjonsbildeleverandør, blir kallet videresendt til denne. Hvis ikke, blir det slått opp på det oppgitte "icon". "symbolicIcon" brukes som en siste reserve. Annotasjonspresentasjonslaget er relevant til tegning av annotasjoner. DefaultMarkerAnnotationAccess slår opp presentasjonslaget ved hjelp av den følgende strategien: Hvis annotasjonspreferansen oppgir et presentasjonslag, blir det oppgitte laget brukt. Hvis det ikke finnes noe lag og annotasjonen implementerer IAnnotationPresentation, brukes IAnnotationPresentation.getLayer. I andre tilfeller returneres standard presentasjonslag (som er 0).
De følgende annotasjonstypene deklareres av plugin-modulen org.eclipse.ui.editors:
<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>
Den definerte utvidelsen markerAnnotationSpecification har ikke lenger attributtene markerType og markerSeverity. De definerer attributtet symbolicIcon med den tilsvarende verdien. Derfor blir det ikke lenger sendt kall til MarkerAnnotation.paint og MarkerAnnotation.getLayer, noe som betyr at overstyring av disse metodene ikke lenger har noen virkning. Påvirkede klienter bør implementere IAnnotationPresentation.
Med introduksjonen av utvidbare
oppstartsmoduser i 3.0, kan det finnes mer enn en oppstartsdelegat for en
oppstartskonfigurasjonstype. Utgaver før 3.0 støttet bare
en oppstartsdelegat per oppstartskonfigurasjonstype. Metoden ILaunchConfigurationType.getDelegate()
er foreldet. Metoden getDelegate(String mode)
kan i stedet
brukes til å hente oppstartsdelegaten for en bestemt oppstartsmodus.
Den foreldede metoden er
endret til å returnere oppstartsdelegaten for modusen run
.
Oppstartsflippgrupper og oppstartsflipper blir ikke
lenger varslet når en oppstart er fullført. Metoden launched(ILaunch)
i
grensesnittene ILaunchConfigurationTab
og ILaunchConfigurationTabGroup
er foreldet, og det blir ikke lenger sendt kall til dem. Avhengigheten av denne metoden
for oppstartsfunksjon var alltid problematisk, fordi det bare finnes flipper når
oppstarten blir utført fra oppstatsdialogboksen. I tillegg kan det ikke lenger
sendes kall til denne metoden etter introduksjonen av bakgrunnsoppstart, fordi oppstartsdialogboksen
blir lukket før det resulterende oppstartsobjektet finnes.
Det er lagt til to metoder i grensesnittet
ILaunchConfigurationTab
- aktivert og deaktivert. Det blir sendt kall til disse
nye livssyklusmetodene når det blir gått henholdsvis inn på og ut av
en flipp. Eksisterende implementeringer av ILaunchConfigurationTab
som subklassifiserer den abstrakte klassen som er levert av plugin-modulen for feilsøking
(AbstractLaunchConfigurationTab
), er binært kompatible fordi metodene blir implementert
i den abstrakte klassen.
I tidligere utgaver ble meldingen initializeFrom
sendt til en flipp når den ble aktivert, og meldingen
performApply
når den ble deaktivert. På denne måten leverte
oppstartskonfigurasjonsflippen kommunikasjon mellom flippene via en oppstartskonfigurasjon
(ved å oppdatere konfigurasjonen med gjeldende attributtverdier når det blir gått ut av en
flipp, og oppdatere flippen det nylig ble gått inn i). Siden mange flipper ikke utfører
kommunikasjon mellom flipper, kan dette imidlertid være ineffektivt. I tillegg var det ikke
mulig å skille mellom en flipp som ble aktivert, og en flipp som viser en valgt
oppstartskonfigurasjon for første gang. Med de nylig tilføyde metodene
kan flippene skille mellom aktivering og initialisering, og deaktivering og lagring
av gjeldende verdier.
Standardimplementeringen av activated
,
fra den abstrakte flippen, sender kall til initializeFrom
. Og standardimplementeringen
av deactivated
sender kall til performApply
. Flipper som ønsker å
utnytte det nye APIet, bør overstyre disse metodene etter behov.
For flipper som ikke utfører
kommunikasjon mellom flipper, er den anbefalte metoden å implementere disse metodene på nytt
slik at de gjør ingenting.
I tidligere utgaver ble perspektivveksling
oppgitt i en oppstartskonfigurasjon, via oppstartskonfigurasjonsattributtene ATTR_TARGET_DEBUG_PERSPECTIVE
og ATTR_TARGET_RUN_PERSPECTIVE
. Med tilføyingen av
utvidbare oppstartsmoduser i 3.0, utfører denne metoden ikke lenger skalering. Perspektivveksling
blir nå oppgitt på oppstartskonfigurasjonstypebasis, per oppstartsmodus som en
oppstartskonfigurasjonstype støtter. Det er tilføyd et API i DebugUITools
for å definere og hente perspektivet som er knyttet til en oppstartskonfigurasjonstype
for en bestemt oppstartsmodus.
I tillegg er det valgfrie
launchMode
-elementet lagt til i utvidelsespunktet launchConfigurationTabGroup
,
som tillater at en oppgitt flippgruppen kan oppgi et standardperspektiv for en
oppstartskonfigurasjonstype og -modus.
Fra Eclipse-brukergrensesnittet kan brukerne redigere perspektivet som er knyttet til en oppstartskonfigurasjonstype, ved å åpne oppstartskonfigurasjonsdialogboksen og velge en oppstartskonfigurasjonstypenode i treet (i stedet for en individuell konfigurasjon). Det vises en flipp som tillater at brukeren definerer et perspektiv med hver støttede oppstartsmodus.
Det er lagt til to metoder i klassen
VMRunnerConfiguration
som støtter definering og henting av
miljøvariabler. Implementerere av IVMRunner
skal sende kall til VMRunnerConfiguration.getEnvironment()
og sende dette miljøet
til den utførte JVM. Klienter som bruker DebugPlugin.exec(String[]
cmdLine, File workingDirectory)
, kan gjøre dette ved å sende kall til DebugPlugin.exec(String[]
cmdLine, File workingDirectory, String[] envp)
i stedet. Innsending av
resultatet fra getEnvironment()
er tilstrekkelig.
I tidligere utgaver hadde VMRunnerConfiguration
ett attributt for å beskrive en oppstartsbane. Attributtet er en samling av Strings
som skal oppgis i argumentet -Xbootclasspath
. Det er lagt til tre nye
attributter i VMRunnerConfiguration som støtter JVMer som tillater
tilføying før og etter oppstartsbanen. Dette er de nye metodene/attributtene
som er lagt til:
getPrependBootClassPath()
- returnerer en samling av oppføringer
som skal tilføyes før oppstartsbanen (argumentet -Xbootclasspath/p
).getMainBootClassPath()
- returnerer en samling av oppføringer
som skal plasseres i oppstartsbanen (argumentet -Xbootclasspath
).getAppendBootClassPath()
- returnerer en samling av oppføringer
som skal tilføyes etter oppstartsbanen (argumentet -Xbootclasspath/a
).Det gamle attributtet getBootClassPath()
finnes fremdeles, og det inneholder en fullstendig bane som tilsvarer den for
de tre nye attributtene. VMRunners
som støtter de nye
oppstartsbanealternativene, bør imidlertid utnytte de nye attributtene.
Funksjonen for arbeidskopi av Java-modell er omarbeidet i 3.0 slik at den gir forbedret funksjonalitet. Før 3.0 tillot Java-modellen oppretting av individuelle arbeidskopier av kompileringsenheter. Endringer kan gjøres i arbeidskopien og iverksettes senere. Det var støtte for begrenset analyse av en arbeidskopi i konteksten av resten av Java-modellen. Disse endringene kunne imidlertid ikke ta hensyn til mer enn en av arbeidskopiene om gangen.
Ved hjelp av endringene i 3.0 er det mulig å opprette og administrere sett av arbeidskopier av kompileringsenheter, og å utføre analyser av ale arbeidskopiene i et sett. Nå er det for eksempel mulig for en klient som JDT-refaktorisering å opprette arbeidskopier for en eller flere kompileringsenheter som blir vurdert for endring, og deretter å behandle typereferanser mellom arbeidskopiene. Tidligere var dette bare mulig etter ar endringene i arbeidskopiene av kompileringsenheten var iverksatt.
Java-modellens API er endret på to måter for å legge til denne forbedrede støtten:
(1) Funksjonaliteten som tidligere ble funnet
i IWorkingCopy
og arvet av ICompilationUnit
, er konsolidert til
ICompilationUnit
.
Grensesnittet IWorkingCopy
ble bare brukt på dette stedet, og det var mye mer generelt enn det trengte
å være. Denne endringen forenkler APIet. IWorkingCopy
er foreldet. Andre steder der IWorkingCopy
blir brukt som en parameter eller resultattype, er også foreldet. De erstattende API-metodene
nevner ICompilationUnit
i stedet for IWorkingCopy
.
(2) Grensesnittet IBufferFactory
er
erstattet av WorkingCopyOwner
.
Den forbedrede støtten for arbeidskopier krever
at det finnes et objekt som eier arbeidskopiene. Selv om IBufferFactory
er på riktig sted, formidler ikke navnet tilstrekkelig hvordan den nye arbeidskopimekanismen
fungerer. WorkingCopyOwner
er et mer beskrivende navn. I tillegg er WorkingCopyOwner
deklarert som en abstrakt klasse, i stedet for som et grensesnitt, slik at begrepet
arbeidskopieier kan bli brukt i fremtiden. Den ene metoden i
IBufferFactory
flyttes til WorkingCopyOwner
uten endring. WorkingCopyOwner
implementerer ikke
IBufferFactory
, dette gjør det klart at IBufferFactory
er noe som tilhører fortiden. IBufferFactory
er foreldet. Andre steder i
APIet der IBufferFactory
vises som en parameter eller resultattype, er også foreldet.
De erstattende API-metodene nevner WorkingCopyOwner
i stedet for IBufferFactory
.
Disse endringene bryter ikke den binære kompatibiliteten.
Ved migrering bør alle referanser til
typen IWorkingCopy
i stedet referere til ICompilationUnit
. Den eneste
implementeringen av IWorkingCopy
, implementerer ICompilationUnit
også. Det betyr at
objekter av typen IWorkingCopy
trygt kan overføres til ICompilationUnit
.
En klasse som implementerer IBufferFactory
, må erstattes
av en subklasse av WorkingCopyOwner
. Selv om WorkingCopyOwner
ikke implementerer selve IBufferFactory
, vil det være mulig å deklarere subklassen av
WorkingCopyOwner
som implementerer IBufferFactory
og derved oppretter en bro
mellom gamle og nye (IBufferFactory
deklarerer createBuffer(IOpenable)
, mens
WorkingCopyOwner
deklarerer createBuffer(ICompilationUnit)
. ICompilationUnit
utvider IOpenable
).
Siden endringene som
omfatter IWorkingCopy
og IBufferFactory
, er griper inn i hverandre, anbefales
det at du behandler begge samtidig. Dette er detaljene for foreldelsen:
IWorkingCopy
(pakken org.eclipse.jdt.core
)
public void commit(boolean, IProgressMonitor)
er foreldet.
ICompilationUnit
:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
til
((ICompilationUnit) wc).commitWorkingCopy(b,monitor)
public void destroy()
er foreldet.
ICompilationUnit
:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
til
((ICompilationUnit) wc).discardWorkingCopy()
public IJavaElement findSharedWorkingCopy(IBufferFactory)
er foreldet.
ICompilationUnit
:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
erstatter IBufferFactory.
public IJavaElement getOriginal(IJavaElement)
er foreldet.
IJavaElement
:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
til elt.getPrimaryElement()
IWorkingCopy.getOriginal
, returnerer
IJavaElement.getPrimaryElement
ikke null
hvis mottakeren ikke er en arbeidskopi.public IJavaElement getOriginalElement()
er foreldet.
ICompilationUnit
:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
til
((ICompilationUnit) wc).getPrimary()
IWorkingCopy.getOriginalElement
,
returnerer IWorkingCopy.getPrimary
ikke null
hvis mottakeren ikke er en
arbeidskopi.public IJavaElement[] findElements(IJavaElement)
er foreldet.
ICompilationUnit
.wc.findElements(elts)
til
((ICompilationUnit) wc).findElements(elts)
public IType findPrimaryType()
er foreldet.
ICompilationUnit
.wc.findPrimaryType()
til
((ICompilationUnit) wc).findPrimaryType()
public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
er foreldet.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
erstatter IBufferFactory.
public IJavaElement getWorkingCopy()
er foreldet.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
til
((ICompilationUnit) wc).getWorkingCopy(null)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
er foreldet.
ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
erstatter IBufferFactory.
public boolean isBasedOn(IResource)
er foreldet.
ICompilationUnit
:
public boolean hasResourceChanged()
wc.isBasesOn(res)
til
((ICompilationUnit) wc).hasResourceChanged()
public boolean isWorkingCopy()
er foreldet.
ICompilationUnit
.wc.isWorkingCopy()
til
((ICompilationUnit) wc).isWorkingCopy()
public IMarker[] reconcile()
er foreldet.
ICompilationUnit
:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
til
((ICompilationUnit) wc).reconcile(false, null)
null
,
erstatningsmetoden returnerer ikke et resultat.public void reconcile(boolean, IProgressMonitor)
er foreldet.
ICompilationUnit
.wc.reconcile(b,monitor)
til
((ICompilationUnit) wc).reconcile(b.monitor)
public void restore()
er foreldet.
ICompilationUnit
.wc.restore()
til
((ICompilationUnit) wc).restore()
IType
(pakken org.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
er foreldet.
public ITypeHierarchy newSupertypeHierarchy(c, IProgressMonitor)
IWorkingCopy[]
til ICompilationUnit[]
.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
er foreldet.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
til ICompilationUnit[]
.IClassFile
(pakken org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
er foreldet.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner, IProgressMonitor)
WorkingCopyOwner
erstatter IBufferFactory.
JavaCore
(pakken org.eclipse.jdt.core
)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
er foreldet.
public ICompilationUnit[] getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
erstatter IBufferFactory.
ICompilationUnit[]
til IWorkingCopy[]
.SearchEngine
(pakken org.eclipse.jdt.core.search
)
public SearchEngine(IWorkingCopy[])
er foreldet.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
til ICompilationUnit[]
.Plugin-modulen org.eclipse.help, som brukes til å oppbevare APIer og utvidelsespunkter som bidrar til og utvider hjelpesystemer, i tillegg til å vise hjelp, inneholder nå bare APIer og utvidelsespunkter som bidrar og gir tilgang til hjelperessurser. En del av standardimplementeringen av brukergrensesnittet for hjelp som ligger i plugin-modulen, er flyttet til den nye plugin-modulen org.eclipse.help.base sammen med APIer for utvidelse av implementeringen. APIene og utvidelsespunktet for bidrag til brukergrensesnittet for hjelp og for å vise hjelp er flyttet til plugin-modulen org.eclipse.ui. Denne omstruktureringen gir applikasjonene større fleksibilitet når det gjelder hjelpefunksjonen. Den nye strukturen gjør at applikasjoner som er basert på den generiske arbeidsbenken, kan ha sine egne brukergrensesnitt for hjelp og/eller hjelpeimplementeringer, eller utelate hjelpefunksjonen fullstendig.
Siden de påvirkede utvidelsespunktene og API-pakkene bare er beregnet på å bli brukt av selve hjelpefunksjonen, er det usannsynlig at eksisterende plugin-moduler blir påvirket av denne endringen. De er bare tatt med her for å gjøre det hele komplett:
Et nytt API for implementering av tilpassede søk er lagt til i 3.0. Det opprinnelige APIet er foreldet i 3.0, og det anbefales at klienter porterer det nye APIet i pakkene org.eclipse.search.ui og org.eclipse.search.ui.text.
Klienter må opprette
implementeringer av ISearchQuery
, ISearchResult
og
ISearchResultPage
. ISearchResultPage
-implementeringen
må deretter legges inn i det nye utvidelsespunktet
org.eclipse.search.searchResultViewPages
.
Standardimplementeringer for ISearchResult
og ISearchResultPage
leveres i pakken org.eclipse.search.ui.text
.
Hvis det før 3.0 ble sendt kall til SWTs DirectoryDialog.setMessage(Streng streng) eller MessageBox.setMessage(Streng streng) med en nullverdi for streng, ville det resultere i en dialogboks uten tekst i tittelen. Denne virkemåten var uspesifisert (sending av null har aldri vært tillatt) og oppretter problemer med getMessage som ikke er tillatt for å returnere null. I 3.0 resulterer sending av null i at det oppstår et IllegalArgumentException-unntak, og spesifikasjonene er endret for å oppgi dette, noe som setter det på linje med metoden i superklassen Dialog.setMessage. Hvis du bruker Dialog.setMessage, må du forsikre deg om at strengen som sendes, aldri er null. Du kan sende en tom streng hvis du ønsker en dialogboks uten tekst i tittelen.
Støtte for samtidige operasjoner krever mer sofistikerte metoder for å vise modal fremdrift. Som en del av forsøket på å øke mottakeligheten er det implementert ekstra fremdriftsstøtte i klassen IProgressService. Den eksisterende måten å vise fremdrift på med ProgressMonitorDialog, fungerer fremdeles. For å forbedre brukererfaringen, anbefales imidlertid migrering til den nye IProgressService.
Dokumentet om å vise modal fremdrift i Eclipse 3.0 beskriver hvordan du migrerer til den nye IProgressService.
Utvidelsespunktet for feilsøking av handlingsgrupper (org.eclipse.debug.ui.debugActionGroups) er fjernet. I Eclipse 3.0 introduserte arbeidsbenken støtte for aktiviteter via utvidelsespunktet org.eclipse.platform.ui.activities. Denne støtten sørger for all funksjonaliteten i feilsøkingen av handlingsgrupper, og den er også enklere å bruke (støtte for mønstre i stedet for at alle handlinger blir oppgitt fullstendig), og det finnes et programmatisk API som støtter dette. Hvis referanser til det gamle utvidelsespunktet ikke blir fjernet, medfører det ikke noen feil. Referanser til utvidelsespunktet blir ganske enkelt ignorert. Produktleverandører oppfordres til å bruke støtten for arbeidsbenkaktiviteter til å knytte språkspesifikke feilsøkingshandlinger til språkspesifikke aktiviteter (for eksempel kan feilsøkingshandlinger i C++ knyttes til en aktivitet kalt "Developing C++").
IBreakpointManager definerer nå metodene setEnabled(boolean) og isEnabled(). Når avbruddspunktstyreren er deaktivert, skal feilrettingsprogrammene ignorere alle registrerte avbruddspunkter. Feilsøkingsplattformen har også en ny lyttermekanisme, IBreakpointManagerListener, som tillater at klientene blir registrert hos avbruddspunktstyreren for å bli varslet når aktiveringen endres. Avbruddspunktvisningen sender kall til dette APIet fra en ny aktiver/deaktiver-handling som gjør at brukeren kan "hoppe over alle avbruddspunkter". Feilsøkere som ikke overholder avbruddspunktstyrerens aktivering, vil derved virke noe redusert hvis brukeren prøver denne funksjonen.
Språk som likner på Java for (for eksempel JSP, SQLJ, JWS) skal kunne delta i Java-søk. Spesielt skal de som implementerer slike språk, være i stand til å
En slik implementerer kalles en søkedeltaker. Den utvider klassen SearchParticipant. Søkedeltakere sendes til søkespørringer (se SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
For enten indeksering eller søking etter samsvar må en søkedeltaker definere en subklasse av SearchDocument som kan hente innholdet i dokumentet ved å overstyre enten getByteContents() eller getCharContents(). En forekomst av denne subklassen retureneres i getDocument(String).
En søkedeltaker som ønsker å indeksere et eller annet dokument, bruker SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) til å planlegge indekseringen av det gitte dokumentet i den gitte indeksen. Når dokumentet er klart til å bli indeksert, sender det underliggende rammeverket kall til SearchParticipant.indexDocument(SearchDocument, IPath). Søkedeltakeren henter deretter dokumentets innhold, analyserer det og legger til indeksoppføringer ved hjelp av SearchDocument.addIndexEntry(char[], char[]).
Når indekseringen er fullført, er det mulig å sende spørringer på indeksene og finne samsvar ved hjelp av SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Den ber først hver deltaker om indeksene som er nødvendige for denne spørringen, ved hjelp av SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). For hver indeksoppføring som samsvarer med det gitte mønsteret, blir det opprettet et søkedokument ved hjelp av søkedeltakeren (se getDocument(String)). Alle disse dokumentene blir sendt til søkedeltakeren slik at den kan finne samsvar ved hjelp av locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). Søkedeltakeren varsler SearchRequestor om søkesamsvar ved hjelp av acceptSearchMatch(SearchMatch), og det blir sendt en forekomst av en subklasse av SearchMatch.
En søkedeltaker kan delegere en del av arbeidet til standard Java-søkedeltaker. En forekomst av denne standarddeltakeren oppnås ved hjelp av SearchEngine.getDefaultSearchParticipant(). Når en SQLJ-deltaker blir bedt om å finne samsvar, kan SQLJ-deltakeren opprette .java-dokumenter fra .sqlj-dokumentene og delegere arbeidet til standarddeltakeren ved å sende .java-dokumentene.