3.0-version toimintojen ja sovellusohjelmaliittymien käyttöönoton yhteydessä edellytetyt muutokset

Tässä osassa kuvataan muutoksia, jotka ovat pakollisia, jos yrität muuttaa 2.1-lisäosan ottamaan käyttöön 3.0-version toiminnot ja sovellusohjelmaliittymät.

org.eclipse.core.runtime.compatibility-lisäosasta luopuminen

Eclipse 3.0-ajoympäristö on merkittävästi erilainen. Pohjalla oleva toteutus perustuu OSGi-kehysmääritykseen. Eclipse 3.0 -ajoympäristössä on yhteensopivuuskerros (org.eclipse.core.runtime.compatibility-lisäosassa), joka pitää yllä 2.1-sovellusohjelmaliittymät. Lisäosien kehittäjien, jotka ovat kiinnostuneita suorituskyvyn ja toiminnan parantamisesta, tulisi harkita 3.0-sovellusohjelmaliittymien käyttöönottoa ja yhteensopivuuskerroksesta riippuvuuden hylkäystä. Yhteensopivuuskoodi näkyy kolmessa paikassa:

Seuraavassa tarkastellaan yksityiskohtaisemmin, mitkä luokat ja metodit ovat olemassa yhteensopivuussyistä, ja opastetaan lisäosien päivityksessä.

Lisäosat ja resurssijoukot

Eclipse-ajoympäristö on muutettu kahteen osaan; luokkien latauksen ja ennakkoehtojen hallintaan ja laajennusten/laajennuspisteiden hallintaan. Tämä jako mahdollistaa OSGi-kehysmäärityksen luonnollisen/saumattoman käyttöönoton luokkien latausta ja ennakkoehtojen hallintaa varten. Tämä puolestaan mahdollistaa joukon uusia ajonaikaisia ominaisuuksia dynaamisesta lisäosien asennuksesta/päivityksestä/asennuksen poistosta suojaukseen ja lisääntyneen määriteltävyyteen.

Vaikka edelleen puhutaan lisäosista, uudessa ajoympäristössä lisäosa on itse asiassa palvelupaketti ja joitakin laajennuksia ja laajennuspisteitä. Käsite palvelupaketti on määritetty OSGi-kehysmäärityksessä, ja se viittaa lajien ja resurssien kokoelmaan ja siihen liittyviin palvelupakettien välisiin ennakkoehtotietoihin. Laajennusrekisteri on lisäosarekisterin uusi muoto, ja se kuvaa ainoastaan laajennusten ja laajennuspisteiden tiedot. Laajennusrekisterin sovellusohjelmaliittymä on pitkälti sama kuin vastaava lisäosarekisterin sovellusohjelmaliittymä (lisätietoja on ohjeaiheessa Rekisterit).

Eclipse 2.x -ajoympäristössä lisäosaobjektilla on joukko rooleja ja velvollisuuksia:

Eclipse 3.0 -ajoympäristössä nämä roolit ja vastuut on muutettu erillisiksi objekteiksi.

Palvelupaketti
Palvelupaketit ovat OSGi:n modulaarisuuden yksikkö. Yhtä palvelupakettia kohti on yksi luokanlataustoiminto, ja Eclipsen kaltaisia palvelupakettien välisiä luokanlatauksen riippuvuuskaavioita voidaan rakentaa. Palvelupaketeilla on elinkaari aloitusta ja lopetusta varten, ja OSGi-kehys lähettää palvelupakettiin liittyvät tapahtumat (esim. asennus, tulkinta, aloitus, lopetus ja asennuksen peruutus) kiinnostuneille osapuolille. Toisin kuin Eclipsen Plugin-luokka, OSGi:n Bundle-luokka ei ole laajennettavissa. Toisin sanoen sovelluskehittäjät eivät voi määrittää omia palvelupakettiluokkiaan.
BundleActivator
BundleActivator on OSGi-kehyksen määrittämä rajapinta. Jokainen palvelupaketti voi määrittää palvelupaketin aktivointitoimintoluokan pitkälti samoin kuin lisäosa voi määrittää Plugin-luokkansa. Kehys luo määritetyn luokan ilmentymän, jota käytetään elinkaaren start()- ja stop()-käsittelyyn. Tämän elinkaaren käsittelyn luonteessa on kuitenkin suuri ero. Eclipsessä on yleistä (joskaan ei suositeltavaa), että Plugin-luokat tekevät sekä alustuksen että rekisteröinnin. OSGi:ssä aktivointitoimintojen pitää tehdä vain rekisteröinti. Jos BundleActivator.start()-metodissa tehdään paljon alustusta (tai mitä tahansa muuta työtä), järjestelmän toiminta vaarantuu.
BundleContext
BundleContext-rajapinnat ovat OSGi:n mekanismi järjestelmän yleisen toiminnan paljastamiseen yksittäisille palvelupaketeille. Jokaisella palvelupaketilla on yksilöllinen ja yksityinen BundleContext-ilmentymä, jota se käyttää järjestelmän toimintojen käyttämiseen (esim. getBundles() järjestelmän kaikkien palvelupakettien tunnistamista varten).
Plugin
Uusi Plugin on hyvin pitkälti samanlainen kuin alkuperäinen Eclipsen Plugin-luokka seuraavia poikkeuksia lukuun ottamatta: ajoympäristö ei enää tarvitse tai hallitse Plugin-objekteja, ja monet metodit ovat vanhentuneet. Se on pohjimmiltaan kätevämpi tapa tuottaa joukko hyödyllisiä toimintoja ja mekanismeja, mutta se ei ole enää ehdottoman pakollinen. Monet tässä toimitetuista toiminnoista ovat käytettävissä myös ajoympäristön Platform-luokassa.

Plugin toteuttaa myös BundleActivator-rajapinnan. Tässä otetaan huomioon etu siitä, että lisäosan elinkaarta ja merkitystä kuvaa yksi keskusobjekti. Huomaa, että tämä ei kuitenkaan pyhitä tietorakenteiden ahkeraa alustusta, joka on nykyään yleistä lisäosissa. Ei voida tarpeeksi painottaa sitä, että lisäosia voidaan ottaa käyttöön, koska johonkin oheisluokkaan on viitattu luokan todennuksen aikana toisessa lisäosassa. Toisin sanoen se, että lisäosa on otettu käyttöön, ei välttämättä tarkoita, että sen toimintaa tarvittaisiin. Huomaa myös, että voit vapaasti määrittää eri BundleActivator-luokan tai jättää palvelupaketin aktivointitoiminnon kokonaan pois.

2.x-version Plugin-luokan siirtoon Eclipse 3.0 -versioon tarvittavat toimet vaihtelevat sen mukaan, mitä luokka tekee. Kuten edellä on kuvattu, suurin osa aloituksen elinkaarityöstä kuuluu johonkin seuraavista luokista:

Alustus
Tietorakenteen ja mallien alustus tapahtuu melko usein Plugin.startup()-metodissa. Luonnollinen/ilmeinen määritys olisi tehdä tämä työ BundleActivator.start()-metodissa eli jättää toiminto Plugin-luokkaan. Tätä ei suositella. Kuten 2.x-lisäosien kohdalla, 3.0-lisäosat/palvelupaketit voidaan aloittaa monista eri syistä monissa eri tilanteissa.
Todellinen esimerkki Eclipse 2.0 -version ajoilta valaisee tätä tapausta. Eräs lisäosa alusti suuren mallin, mikä edellytti noin 11 megatavun koodin ja monien megatavujen tietojen latausta. Melko yleisissä tapauksissa tämä lisäosa aktivoitiin selvittämään, tuleeko navigaattorissa näkyvä projektin kuvake koristella tietyillä merkinnöillä. Tämä testi ei edellyttänyt mitään startup()-tehdyistä alustuksista, mutta silti kaikkien käyttäjien piti kaikissa tapauksissa kärsiä tämän innokkaan alustuksen aiheuttamasta muisti- ja aikahäviöstä.
Vaihtoehtoinen tapa on tehdä tällainen alustus perinteiseen tapaan tarpeen mukaan. Esimerkiksi sen sijaan, että mallit alustettaisiin lisäosan/palvelupaketin aktivoinnin yhteydessä, tee se silloin, kun niitä oikeasti tarvitaan (esim. keskitetyn mallin aksessorimetodissa). Monissa tapauksissa tämä tarkoittaa lähes samaa ajankohtaa, mutta toisissa skenaarioissa tämä menettelytapa lykkää alustusta (mahdollisesti loputtomasti). On suositeltavaa käyttää aikaa 2.1-lisäosien siirron yhteydessä käytetyn alustusstrategian harkintaan.
Rekisteröinti
Lisäosan aloitus on kätevä hetki kuuntelutoimintojen, palveluiden yms. rekisteröintiin ja taustakäsittelysäikeiden aloitukseen (esim. vastakkeen kuuntelu). Plugin.start() voi olla hyvä paikka tämän tekemiseen. Voi olla myös järkevää lykätä osaa johonkin liipaisimeen asti (esim. tietyn toiminnon tai tieto-osan käyttö).
Lisäosan yleistiedot
Plugin-luokka voi edelleen olla tässä roolissa. Tärkein seikka on, että Plugin-objektit eivät ole enää yleisesti käytettävissä järjestelmän hallitseman luettelon kautta. Eclipse 2.x -versiossa lisäosarekisteristä pystyi löytämään minkä tahansa lisäosan Plugin-objektin. Tämä ei ole enää mahdollista. Useimmissa tilanteissa tällainen käyttö ei ole pakollista. Plugin-luokkia, joita käytetään rekisterin kautta, käytetään tavallisemmin yleisinä Plugin-luokkina kuin verkkoaluekohtaisten metodien kutsumiseen. Vastaavan ominaisuuden voi toteuttaa käyttämällä ja käsittelemällä vastaavia Bundle-objekteja.

Rekisterit ja lisäosamalli

Uudessa ajoympäristössä on ero lisäosan ajamiseen tarvittavien ja lisäosan laajennuksiin ja laajennuspisteisiin liittyvien tietojen ja rakenteiden välillä. OSGi-kehysmääritys määrittää ja hallitsee edelliset. Jälkimmäiset ovat Eclipsen käsitteitä, ja Eclipsen ajonaikainen koodi lisää ne. Alkuperäinen lisäosarekisteri ja siihen liittyvät objektit on jaettu vastaavasti OSGi-palvelupaketteihin ja Eclipse-laajennusrekisteriin.

IPluginRegistry-rajapinnan osat, jotka käsittelevät ajomääritystä (esim. IPluginDescriptor, ILibrary, IPrequisite) ovat vanhentuneet, ja jäljelle jääneet laajennuksiin ja laajennuspisteeseen liittyvät osat on siirretty IExtensionRegistry-rajapintaan. Lisäksi lisäosarekisteriin liittyvät niin sanotut malliobjektit ovat nyt kokonaisuudessaan vanhentuneet. Ajoympäristö esitteli ja alusti nämä lajit ensisijaisesti PDE:n ja muiden työvälinejärjestelmien tukemista varten. Valitettavasti monesti oli niin, että tarvittava tietojen taso ylitti ajoympäristön toiminnot tai kiinnostuksen kohteet (esimerkiksi plugin.xml-elementtien rivinumeroiden muistaminen) ja lopulta ajoympäristön tietojen mahdollisten käyttäjien piti joka tapauksessa pitää yllä omia rakenteitaan.

Uudessa ajoympäristössä ajoympäristön toimittamia välineitä on tarkasteltu uudelleen, ja nyt toimitetaan ainoastaan ne, jotka ovat joko välttämättömiä ajoympäristön ajossa tai ovat erittäin hankalasti muiden tehtävissä. Kuten edellä on mainittu, lisäosarekisterin malliobjektit ovat vanhentuneet, kuten myös lisäosan jäsennyksen sovellusohjelmaliittymä. Välttämättömät laajennuksiin liittyvät tiedot ovat uudessa laajennusrekisterissä. Uusi state-rakenne (katso org.eclipse.osgi.service.resolver.State ja vastaavat) esittää välttämättömät toteutukseen liittyvät tiedot ja mahdollistaa niiden käsittelyn.

NL-fragmenttirakenne

Eclipse 3.0 -versiossa NL-fragmenttirakenne on päivitetty yhdenmukaisemmaksi. Aiemmin plugin.properties-tiedostojen ja muiden vastaavien käännösten oletettiin olevan fragmenttien toimittamien JAR-arkistojen sisällä. Koska alkuperäiset tiedostot ovat vastaavan isäntälisäosan juuressa, yhdenmukaisempi sijainti olisi, että käännetyt tiedostot olisivat NL-fragmenttien juuressa. Esimerkki:

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar

Huomaa, että tässä tiedosto nl1.jar olisi aiemmin sisältänyt plugin.properties-tiedoston käännökset. Nämä tiedostot ovat nyt fragmentin juuressa, ja JAR sisältää kaikkien käännettävissä olevien isäntälisäosan resurssien (eli luokanlataustoiminnon kautta ladattujen tiedostojen) käännökset.

Eclipse 2.1 NL -fragmenttirakenne on luonnollisesti edelleen tuettu 2.1-isäntälisäosille, jotka ajetaan Eclipse 3.0 -ympäristössä. Et voi kuitenkaan käyttää 2.1 NL -fragmenttia 3.0-lisäosassa. Fragmentti on päivitettävä uuteen rakenteeseen.

Sovellusohjelmaliittymämuutosten yleiskuvaus

org.eclipse.core.boot (paketti org.eclipse.core.boot)

Koko org.eclipse.core.boot-paketti on vanhentunut. BootLoader on yhdistetty org.eclipse.core.runtime.Platform-luokkaan, sillä enää ei ollut mieltä tehdä jakoa alkulatauksen ja ajoympäristön välillä. Huomaa, että itse asiassa org.eclipse.core.boot-lisäosa on hajotettu ja sen koodi on siirretty joko uuteen ajoympäristöön tai yhteensopivuuskerrokseen.

IPlatformConfiguration on aina ollut Eclipsen Asenna/päivitä-komponentin määrittämä ja sille määritettävä laji. Ajoympäristön uudelleenjärjestelyn myötä tämä laji voidaan palauttaa oikeaan kotiinsa. Tämä luokka on pitkälti muuttumaton, ja se on paketoitu uudelleen org.eclipse.update.configurator.IPlatformConfiguration-rajapinnaksi.

IPlatformRunnable on siirretty org.eclipse.core.runtime.IPlatformRunnable-rajapintaan.

IExtension ja IExtensionPoint (paketti org.eclipse.core.runtime)

getDeclaringPlugin()-metodi (molemmissa luokissa) antaa laajennuksen (IExtension) tai laajennuspisteen (IExtensionPoint) esittelevälle lisäosalle linkin ylöspäin. Uusi rekisterimalli tekee eron lisäosien ajon ja laajennuksen/laajennuspisteiden välille, eikä se enää sisällä IPluginDescriptors-rajapintaa. Tämän sovellusohjelmaliittymän käyttäjien tulisi harkita uutta metodia getParentIdentifier(), joka on sekä IExtension- että IExtensionPoint-rajapinnassa.

ILibrary, IPluginDescriptor, IPluginRegistry ja IPrerequisite (paketti org.eclipse.core.runtime)

Alkuperäisessä ajoympäristössä lisäosarekisteri piti yllä kokonaiskuvaa ajoympäristön kokoonpanosta. Eclipse 3.0 -versiossa tämä kuva on jaettu OSGi-kehykseen ja laajennusrekisteriin. Nämä luokat ovat näin ollen vanhentuneet. Vanhentumisilmoituksissa on lisätietoja koodin päivityksestä.

Ympäristö ja Plugin (paketti org.eclipse.core.runtime)

Uudessa ajoympäristössä Plugin-objektit eivät ole enää ajoympäristön hallinnassa, joten niitä ei voi käyttää yleisesti ympäristön välityksellä. Vastaavasti lisäosarekisteriä ei enää ole tai se ei enää tarjoa pääsyä lisäosien kuvaajiin. Käytettävissä on kuitenkin sopivia korvaavia menetelmiä, jotka on kuvattu näiden luokkien vanhentuneiden metodien Javadocissa.

org.eclipse.core.runtime.model (paketti org.eclipse.core.runtime.model)

Kaikki tämän paketin lajit ovat nyt vanhentuneet. Lisätietoja on rekisterien yhteydessä.

IWorkspaceRunnable ja IWorkspace.run (paketti org.eclipse.core.resources)

IWorkspace.run(IWorkspaceRunnable,IProgressMonitor)-metodin asiakkaiden tulisi käydä uudelleen läpi tämän metodin käyttö ja harkittava monipuolisemman metodin IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor) käyttöä. Vanha IWorkspace.run-metodi lukitseee koko työtilan IWorkspaceRunnable-rajapinnan ajaksi. Tämä tarkoittaa sitä, että tällä metodilla tehtyä toimintaa ei voi koskaan ajaa samanaikaisesti muiden työtilaa muuttavien toimien kanssa. Eclipse 3.0 -versiossa monet pitkäkestoiset työt on siirretty taustasäikeisiin, joten toimintojen välisten ristiriitojen todennäköisyys on lisääntynyt huomattavasti. Jos pitkäkestoinen taustatyö estää modaalisen edustatoiminnan, käyttöliittymä on lukkiutunut taustatoimen valmistumiseen asti tai kunnes toinen toiminnoista peruutetaan.

Ehdotettu ratkaisu on vaihtaa kaikki viittaukset vanhaan IWorkspace.run-metodiin käyttämään uutta metodia ajoitussäännön parametrilla. Ajoitussäännön tulisi olla yksityiskohtaisin sääntö, joka kattaa kaikki kyseisen toimen tekemien muutosten säännöt. Jos toiminto yrittää muuttaa resursseja ajoitussäännön vaikutusalueen ulkopuolella, seurauksena on ajonaikainen poikkeus. Tietyn työtilan toimen edellyttämää tarkkaa ajoitussääntöä ei ole määritetty, ja se voi vaihdella tietyssä projektissa asennetun tietosäilön toimittajan mukaan. IResourceRuleFactory-factory-rajapinnan tulisi hakea ajoitussääntö resurssia muuttaville toimille. Haluttaessa voidaan käyttää MultiRule-luokkaa määrittämään useita resurssisääntöjä, ja hyödyllistä MultiRule.combine-metodia voi käyttää yhdistämään useiden resurssia muuttavien toimien sääntöjä.

Jos lukitus ei ole tarpeen, voidaan käyttää ajoitussääntöä null. Tällöin runnable-objekti voi muuttaa kaikkia työtilan resursseja, mutta se ei estä toisia säikeitä muuttamasta työtilaa samanaikaisesti. Kun työtilaan tehdään yksinkertaisia muutoksia, tämä on usein helpoin ja samanaikaisuuden suhteen ystävällisin ratkaisu.

IWorkbenchPage (paketti org.eclipse.ui)

IEditorDescriptor (paketti org.eclipse.ui)

ISharedImages (paketti org.eclipse.ui)

IWorkbenchActionConstants (paketti org.eclipse.ui)

IWorkbenchPreferenceConstants (paketti org.eclipse.ui)

IExportWizard (paketti org.eclipse.ui)

IImportWizard (paketti org.eclipse.ui)

INewWizard (paketti org.eclipse.ui)

WorkbenchHelp (paketti org.eclipse.ui.help)

IHelp (paketti org.eclipse.help)

ITextEditorActionConstants (paketti org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (paketti org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (paketti org.eclipse.ui.texteditor)

TextEditorActionContributor (paketti org.eclipse.ui.editors.text)

annotationTypes-laajennuspiste (lisäosa org.eclipse.ui.editors)

Nykyään on olemassa eksplisiittinen huomautuslaji. Katso Annotation.getType() ja Annotation.setType(). Huomautuksen laji voi muuttua sen voimassaoloaikana. Huomautuslajien esittelyille on lisätty uusi laajennuspiste: "org.eclipse.ui.editors.annotationTypes". Huomautuslajilla on nimi, ja se voidaan esitellä toisen esitellyn huomautuslajin alilajina. Huomautuslajin esittely voi käyttää myös määritteitä "markerType" ja "markerSeverity" määrittämään, että tietyn lajin ja tietyn vakavuuden merkinnät tulee esittää tekstinmuokkausohjelmissa tietyn huomautuslajin huomautuksina. "org.eclipse.ui.editors.markerAnnotationSpecification"-laajennuspisteen määritteitä "markerType" ja "markerSeverity" ei tule enää käyttää. Merkintöjen huomautusten määritykset ovat näin ollen tulossa merkinnöistä riippumattomiksi ja näin ollen niiden nimi harhaanjohtavaksi. Nimi on kuitenkin pidetty taaksepäin yhteensopivuuden varmistamista varten.

AbstractMarkerAnnotationModel-luokan aliluokkien ilmentymät tunnistavat merkinnöistä luomansa huomautukset ja asettavat niille oikean huomautuksen lajin automaattisesti. Käytä org.eclipse.ui.texteditor.AnnotationTypeLookup-luokkaa tietyn merkinnän tai tietyn markerType- ja markerSeverity-parin huomautuksen lajin ohjelmalliseen noutoon.

Huomautusten lajien hierarkian käytön toimittaa IAnnotationAccessExtension. Tietylle huomautuksen lajille voi hakea ylilajien ketjun ja tarkistaa, onko huomautuksen laji toisen huomautuksen lajin alilaji. DefaultMarkerAnnotationAccess toteuttaa tämän rajapinnan.

markerAnnotationSpecification-laajennuspiste (lisäosa org.eclipse.ui.editors)

Huomautuksen laji on avain, jolla etsitään liittyvä merkinnän huomautuksen määritys. Koska huomautusten lajit voivat laajentaa muita huomautusten lajeja, myös merkinnän huomautuksen määrityksillä on implisiittinen suhde. Näin ollen tietyn huomautuksen lajin merkinnän huomautuksen määrityksen täydentävät tietyn huomautuksen lajin ylilajien merkintöjen huomautusten määritykset. Sen vuoksi merkinnän huomautuksen määrityksen ei tarvitse olla kattava kuten ennen. Merkintöjen huomautusten määritykset noutaa AnnotationPreferences. org.eclipse.ui.texteditor.AnnotationPreferenceLookup-luokan avulla voit noutaa tietylle huomautuksen lajille huomautuksen oletusasetuksen, joka läpinäkyvästi täydentää oletusasetuksen huomautuksen ylilajiketjun mukaisesti.

Merkinnän huomautuksen määritystä on laajennettu kolmella lisämääritteellä, jotta tietyllä huomautuksen lajilla voi olla mukautettu ulkoasu pystyviivaimessa. Nämä määritteet ovat "icon", "symbolicIcon" ja "annotationImageProvider". Määritteen "icon" arvo on polku tiedostoon, joka sisältää kuvakekuvan. Määritteen "symbolicIcon" arvona voi olla "error", "warning", "info", "task" tai "bookmark". Määritettä "symbolicIcon" käytetään kertomaan ympäristölle, että huomautus tulee kuvata samoilla kuvilla, joita ympäristö käyttää kuvaamaan virheet, varoitukset, tiedot, tehtävät ja kirjanmerkit. Määritteen "annotationImageProvider" arvo on org.eclipse.ui.texteditor.IAnnotationImageProvider-rajapinnan toteuttava luokka, joka sallii täysin mukautetun huomautuksen esityksen.

Pystyviivain käyttää huomautusten piirtämiseen siihen liitettyä IAnnotationAccess/IAnnotationAccessExtension-rajapintaa. Pystyviivain ei enää kutsu Annotation.paint-metodia. Yleisesti ottaen huomautusten ei enää odoteta piirtävän itsensä. Metodit "paint" ja "getLayer" ovat vanhentuneet, jotta huomautus voisi lopulta tulla käyttöliittymästä riippumattomaksi. DefaultMarkerAnnotationAccess onIAnnotationAccess/IAnnotationAccessExtension-rajapinnan oletustoteutus. DefaultMarkerAnnotationAccess toteuttaa seuraavan strategian huomautusten maalausta varten: Jos huomautus toteuttaa IAnnotationPresentation-rajapinnan, IAnnotationPresentation.paint kutsutaan. Jos ei, huomautuksen kuvan lähde etsitään huomautuksen oletusasetuksesta. Huomautuksen kuvan lähde on käytettävissä vain, jos se on määritetty ja sisällyttävän merkinnän huomautuksen määrityksen määrittävä lisäosa on jo ladattu. Jos huomautuksen kuvan lähde on olemassa, kutsu välitetään sille. Jos ei, määritteen "icon" kuvake etsitään. Viimeisenä vaihtoehtona käytetään määritteen "symbolicIcon" mukaista kuvaketta. Huomautuksen esityskerros on merkityksellinen huomautusten piirtämisessä. DefaultMarkerAnnotationAccess etsii esityskerroksen seuraavan strategian mukaan: Jos huomautuksen oletusasetus määrittää esityskerroksen, käytetään määritettyä kerrosta. Jos kerrosta ei ole, ja huomautus toteuttaa IAnnotationPresentation-rajapinnan, käytetään IAnnotationPresentation.getLayer-metodia. Muussa tapauksessa palautetaan oletusesityskerros (joka on 0).

Siirtyminen annotationTypes-laajennuspisteeseen (lisäosa org.eclipse.ui.editors)

org.eclipse.ui.editors-lisäosa esittelee seuraavat huomautuksen lajit:

   <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>

Määritetty markerAnnotationSpecification-laajennus ei enää toimita "markerType"- ja "markerSeverity"-määritteitä. Ne määrittävät"symbolicIcon"-määritteen ja vastaavan arvon. Niinpä MarkerAnnotation.paint- ja MarkerAnnotation.getLayer-metodeja ei enää kutsuta, eli näiden metodien ohituksella ei ole enää vaikutusta. Asiakkaiden, joita tämä muutos koskee, tulee toteuttaa IAnnotationPresentation-rajapinta.

ILaunchConfigurationType (paketti org.eclipse.debug.core)

Kun 3.0-versioon on lisätty laajennettavia aloitustiloja, aloituskokoonpanon lajille voi olla useita aloitusdelegaatteja. Versiota 3.0 edeltävät versiot tukivat yhtä aloitusdelegaattia aloituskokoonpanon lajia kohti. Metodi ILaunchConfigurationType.getDelegate() on nyt vanhentunut. Metodia getDelegate(String mode) tulee käyttää sen sijaan tietyn aloitustilan aloitusdelegaatin noutoon. Vanhentunut metodi on muutettu run-tilan aloitusdelegaatin palauttamista varten.

ILaunchConfigurationTab ja ILaunchConfigurationTabGroup (paketti org.eclipse.debug.ui)

Aloituksen välilehtiryhmät ja aloituksen välilehdet eivät enää saa ilmoitusta, kun aloitus on valmis. Metodi launched(ILaunch) rajapinnoissa ILaunchConfigurationTab ja ILaunchConfigurationTabGroup on vanhentunut, eikä sitä enää kutsuta. Tämän metodin käyttö aloitustoiminnossa oli aina ongelmallista, sillä välilehdet ovat olemassa vain, kun aloitus on tehty aloituksen valintaikkunasta. Lisäksi tausta-aloituksen lisäämisen myötä tätä metodia ei voi enää kutsua, sillä aloituksen valintaikkuna suljetaan ennen kuin sen tuloksena oleva aloitusobjekti on olemassa.

ILaunchConfigurationTab ja AbstractLaunchConfigurationTab (paketti org.eclipse.debug.ui)

Rajapintaan ILaunchConfigurationTab on lisätty kaksi metodia - activated ja deactivated. Näitä uusia elinkaarimetodeja kutsutaan, kun välilehteen siirrytään (activated) ja siitä poistutaan (deactivated). Rajapinnan ILaunchConfigurationTab olemassa olevat toteutukset, jotka ovat vianmäärityslisäosan toimittaman abstraktin luokan (AbstractLaunchConfigurationTab) aliluokkia, ovat binaarisesti yhteensopivia, sillä metodit on toteutettu abstraktissa luokassa.

Aiemmissa laitoksissa välilehdelle lähetettiin sanoma initializeFrom sen aktivoinnin yhteydessä ja performApply sen käytöstä poiston yhteydessä. Tällä tavalla aloituskokoonpanon välilehti toimitti välilehtien välisen viestinnän aloituskokoonpanon välityksellä (päivittämällä aloituskokoonpanoon nykyiset määritteiden arvot välilehdestä poistumisen yhteydessä ja päivittämällä sen välilehden, johon siirryttiin). Koska monet välilehdet eivät kuitenkaan viesti välilehtien välillä, tämä voi olla tehotonta. Lisäksi ei myöskään ollut mitään tapaa erottaa aktivoitu välilehti välilehdestä, joka näytti valitun aloituskokoonpanon ensimmäistä kertaa. Uusien lisättyjen metodien avulla välilehdet voivat tehdä eron aktivoinnin ja alustuksen välille sekä käytöstä poiston ja nykyisten arvojen tallennuksen välille.

Abstraktin välilehden toimittama activated-metodin oletustoteutus kutsuu initializeFrom-metodia. deactivated- metodin oletustoteutus puolestaan kutsuu performApply-metodia. Välilehtien, jotka haluavat käyttää uutta sovellusohjelmaliittymää hyväkseen, tulee ohittaa nämä metodit tarpeen mukaan. Yleisesti ottaen välilehdillä, jotka eivät viesti välilehtien välillä, suositeltu menettely on toteuttaa nämä metodit uudelleen olemaan tekemättä mitään.

launchConfigurationTabGroup-laajennuspisteen laji (paketti org.eclipse.debug.ui)

Aiemmissa laitoksissa perspektiivin vaihto määritettiin aloituskokoonpanossa aloituskokoonpanon määritteiden ATTR_TARGET_DEBUG_PERSPECTIVE ja ATTR_TARGET_RUN_PERSPECTIVE avulla. Kun 3.0-versioon on lisätty laajennettavia aloitustiloja, tämä menettely ei enää skaalaudu. Perspektiivin vaihto määritetään nyt aloituskokoonpanon lajin mukaan, aloituskokoonpanon lajin tukemalle aloitustilalle. DebugUITools-luokkaan on lisätty sovellusohjelmaliittymä asettamaan ja noutamaan perspektiivin, joka liittyy määritetyn aloitustilan aloituskokoonpanon lajiin.

Lisäksi valinnainen launchMode-elementti on lisätty launchConfigurationTabGroup-laajennuspisteeseen. Sen avulla lisätty välilehtiryhmä voi määrittää oletusperspektiivin aloituskokoonpanon tyypille ja tilalle.

Käyttäjät voivat muokata Eclipse-käyttöliittymästä aloituskokoonpanon lajiin liittyvää perspektiiviä avaamalla aloituskokoonpanon valintaikkunan ja valitsemalla aloituskokoonpanon lajin solmun rakenteesta (yksittäisen kokoonpanon sijaan). Näyttöön tulee välilehti, josta käyttäjä voi asettaa perspektiivin kullekin tuetulle aloitustilalle.

[Vain JDT] IVMRunner (paketti org.eclipse.jdt.launching)

VMRunnerConfiguration-luokkaan on lisätty kaksi metodia tukemaan ympäristömuuttujien asetusta ja noutoa. IVMRunner-rajapinnan toteuttajien tulisi kutsua VMRunnerConfiguration.getEnvironment() ja välittää kyseinen ympäristö laajennettuun Java-näennäiskoneeseen. Asiakkaat, jotka käyttävät DebugPlugin.exec(String[] cmdLine, File workingDirectory) -metodia, voivat tehdä tämän kutsumalla sen sijaan DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp) -metodia. Pelkkä tuloksen välitys getEnvironment()-metodista riittää.

[Vain JDT] VMRunnerConfiguration- ja Bootstrap-luokat (paketti org.eclipse.jdt.launching)

Aiemmissa versioissa VMRunnerConfiguration-luokalla oli yksi määrite aloituspolun kuvaamista varten. Määrite on kokoelma String-merkkijonoja, jotka määritetään -Xbootclasspath-argumentissa. VMRunnerConfiguration-luokkaan on lisätty kolme uutta määritettä tukemaan Java-näennäiskoneita, jotka sallivat liitokset aloituspolun eteen ja loppuun. Uudet lisätyt metodit/määritteet ovat seuraavat:

Vanha määrite getBootClassPath() on edelleen olemassa, ja se sisältää tarkennetun polun, joka vastaa kolmen uuden määritteen polkua. Uusia aloituspolun vaihtoehtoja tukevien VMRunner-rajapintojen tulisi kuitenkin hyödyntää uusia määritteitä.

[Vain JDT] Parannettu työskentelykopioiden tuki (paketti org.eclipse.jdt.core)

Java-mallin työskentelykopio-ominaisuutta on muunneltu 3.0-versiossa tuottamaan paljon parempi toiminta. Ennen 3.0-versiota Java-malli mahdollisti käännösyksiköiden yksittäisten työskentelykopioiden luonnin. Työskentelykopioon pystyi tekemään muutoksia, jotka vahvistettiin myöhemmin. Työskentelykopioiden rajoitetulle analysoinnille muun Java-mallin kontekstissa oli rajoitettu tuki. Nämä analyysit eivät kuitenkaan voineet koskaan ottaa huomioon useampaa kuin yhtä työskentelykopiota kerralla.

3.0-version muutokset mahdollistavat useiden käännösyksiköiden työskentelykopioiden luonnin ja hallinnan ja joukon kaikkia työskentelykopioita koskevien analyysien teon. Nyt esimerkiksi JDT-koodinparannus voi luoda työskentelykopioita yhdelle tai usealle käännösyksikölle, jonka muuttamista se harkitsee, ja selvittää lajien viittaukset työskentelykopioiden välillä. Aiemmin tämä oli mahdollista vasta, kun muutokset käännösyksikön työskentelykopioihin oli vahvistettu.

Java-mallin sovellusohjelmaliittymä on muuttunut kahdella tapaa tämän parannetun tuen lisäystä varten:

(1) Toiminnot, jotka aiemmin olivat IWorkingCopy-rajapinnassa ja periytyivät ICompilationUnit-rajapinnalle, on yhdistetty ICompilationUnit-rajapintaan. IWorkingCopy-rajapintaa käytettiin vain tässä kohdin, ja se oli tarpeettoman yleinen. Tämä muutos yksinkertaistaa sovellusohjelmaliittymää. IWorkingCopy on vanhentunut. Myös muut sovellusohjelmaliittymän kohdat, joissa IWorkingCopy-rajapintaa käytetään parametrina tai tuloksen lajina, ovat vanhentuneet; korvaavat sovellusohjelmaliittymät mainitsevat ICompilationUnit-rajapinnanIWorkingCopy-rajapinnan sijaan.

(2) IBufferFactory-rajapinta on korvattu WorkingCopyOwner-rajapinnalla. Työskentelykopioiden parannettu tuki edellyttää työskentelykopiot omistavan objektin olemassaoloa. Vaikka IBufferFactory-rajapinta on oikeassa paikassa, nimi ei välitä riittävän hyvin sitä, miten uusi työskentelykopiomekanismi toimii. WorkingCopyOwner on paljon kuvaavampi. Lisäksi WorkingCopyOwner on esitelty abstraktina luokkana eikä rajapintana, että työskentelykopion omistajan käsite voi kehittyä tulevaisuudessa. IBufferFactory-rajapinnan yksi metodi siirtyy WorkingCopyOwner-luokkaan muuttumattomana. WorkingCopyOwner ei toteuta IBufferFactory-rajapintaa selvennyksenä siitä, että IBufferFactory on mennyttä. IBufferFactory on vanhentunut. Myös muut sovellusohjelmaliittymän kohdat, joissa IBufferFactory-rajapintaa käytetään parametrina tai tuloksen lajina, ovat vanhentuneet; korvaavat sovellusohjelmaliittymät mainitsevat WorkingCopyOwner-luokan IBufferFactory-rajapinnan sijaan.

Nämä muutokset eivät häiritse binaarista yhteensopivuutta.

Siirron yhteydessä kaikkien IWorkingCopy-viittausten tulisi viitata sen sijaan rajapintaan ICompilationUnit. IWorkingCopy-rajapinnan ainut toteutus toteuttaa myös ICompilationUnit-rajapinnan, eli IWorkingCopy-lajin objektien lajiksi voi turvallisesti muuttaa ICompilationUnit.

Luokka, joka toteuttaa IBufferFactory-rajapinnan, tulee korvata WorkingCopyOwner-luokan aliluokalla. VaikkaWorkingCopyOwner ei toteuta itse IBufferFactory-rajapintaa, olisi mahdollista esitellä WorkingCopyOwner-luokan aliluokka, joka toteuttaa IBufferFactory-rajapinnan ja luo näin sillan vanhan ja uuden välille (IBufferFactory esittelee createBuffer(IOpenable)-metodin, kun taas WorkingCopyOwner esittelee createBuffer(ICompilationUnit)-metodin; ICompilationUnit laajentaa IOpenable-rajapinnan).

Koska IWorkingCopy- ja IBufferFactory-rajapintoihin liittyvät muutokset kietoutuvat toisiinsa, on suositeltavaa käsitellä molempia yhtä aikaa. Vanhentumisten yksityiskohdat ovat seuraavat:

org.eclipse.help-lisäosan rakenteen uudelleenjärjestely

org.eclipse.help-lisäosa, joka aiemmin säilytti sovellusohjelmaliittymät ja laajennuspisteet ohjejärjestelmän lisäystä ja laajentamista sekä ohjeen näyttöä varten, sisältää nyt ainoastaan sovellusohjelmaliittymät ja laajennuspisteet ohjeresurssien lisäystä ja käyttöä varten. Osa kyseisen lisäosan sisältämästä ohjekäyttöliittymän oletustoteutuksesta on siirretty uuteen org.eclipse.help.base-lisäosaan yhdessä toteutuksen laajennuksen sovellusohjelmaliittymien kanssa. Ohjekäyttöliittymän lisäyksen ja ohjeen näytön sovellusohjelmaliittymät ja laajennuspiste on siirretty org.eclipse.ui-lisäosaan. Tämä rakenteen uudelleenjärjestely lisää sovellusten joustavuutta ohjejärjestelmän suhteen; uuden rakenteen ansiosta yleiseen työympäristöön perustuvat sovellukset voivat toimittaa oman ohjekäyttöliittymänsä ja/tai ohjeen toteutuksensa tai poistaa ohjejärjestelmän kokonaan.

Koska laajennuspisteet ja sovellusohjelmaliittymäpaketit on tarkoitettu ainoastaan ohjejärjestelmän käyttöön, ei ole todennäköistä, että tämä muutos vaikuttaisi olemassa oleviin lisäosiin. Ne on sisällytetty tähän ainoastaan, että esitys olisi kattava:

Uusi hakukäyttöliittymän sovellusohjelmaliittymä

Uusi sovellusohjelmaliittymä mukautettujen hakujen toteuttamista varten on lisätty 3.0-versiossa. Alkuperäinen sovellusohjelmaliittymä on vanhentunut 3.0-versiossa, ja asiakkaiden on suositeltavaa siirtyä uuteen sovellusohjelmaliittymään paketeissa org.eclipse.search.ui ja org.eclipse.search.ui.text.

Asiakkaiden on luotava ISearchQuery-, ISearchResult- ja ISearchResultPage-toteutukset. ISearchResultPage-toteutus on sitten lisättävä uuteen org.eclipse.search.searchResultViewPages-laajennuspisteeseen.

ISearchResult- ja ISearchResultPage-rajapintojen oletustoteutukset on toimitettu paketissa org.eclipse.search.ui.text.

null-sanomat MessageBox- ja DirectoryDialog-luokissa (paketti org.eclipse.swt.widgets)

Versiota 3.0 edeltäneissä versioissa SWN:n DirectoryDialog.setMessage(String string)- tai MessageBox.setMessage(String string)-kutsu merkkijonon arvolla null tuotti valintaikkunan, jonka otsikossa ei ollut tekstiä. Tämä toiminta oli määrittämätön (null-arvon välitystä ei ole koskaan sallittu), ja se luo ongelmia getMessage-metodin kanssa, joka ei saa palauttaa null-arvoa. 3.0-versiossa null-arvon välitys tuottaa IllegalArgumentException-poikkeuksen, ja määritystä on muutettu ilmaisemaan tämä, jolloin se on yhdenmukainen niiden yliluokan Dialog.setMessage metodin kanssa. Jos käytät Dialog.setMessage-metodia, varmista, että välitetty merkkijono ei ole koskaan null. Välitä vain tyhjä merkkijono, jos haluat valintaikkunan, jonka otsikossa ei ole tekstiä.

Modaalisten tilannetietojen palautteen parannus

Samanaikaisten toimien tuki edellyttää kehittyneempiä tapoja modaalisten tilannetietojen näyttöön. Vastauksena palautteeseen IProgressService-luokassa on toteutettu tilannetietojen lisätuki. Aiempi tapa näyttää tilannetiedot ProgressMonitorDialog-luokan avulla toimii edelleen. Käyttötuntuman parantamista varten on kuitenkin suositeltavaa siirtyä uuteen IProgressService-rajapintaan.

Asiakirjassa Modaalisten tilannetietojen näyttö Eclipse 3.0 -versiossa kuvataan siirtymistä uuteen IProgressService-rajapintaan.

Vianmäärityksen toimintoryhmiä on poistettu

Vianmäärityksen toimintoryhmien laajennuspiste (org.eclipse.debug.ui.debugActionGroups) on poistettu. Eclipse 3.0 -versiossa työympäristöön tuli tapahtumien tuki org.eclipse.platform.ui.activities-laajennuspisteen avulla. Tämä tuki toimittaa kaiken saman, mitä vianmäärityksen toimintoryhmätkin, ja se on helppokäyttöisempi (se tukee malleja kaikkien toimintojen poissulkevan määrityksen sijaan), ja sitä tukemassa on ohjelmallinen sovellusohjelmaliittymä. Vanhan laajennuspisteen viittausten poistamatta jättäminen ei aiheuta häiriöitä. Viittaukset laajennuspisteeseen vain ohitetaan. Tuotteiden myyjien suositellaan käyttävän tapahtumien tukea liittämään kielikohtaiset vianmääritystoimet kielikohtaisiin tapahtumiin (esimerkiksi C++-vianmääritystoimet voi liittää tapahtumaan "Developing C++").

BreakpointManager-rajapinnan voi poistaa käytöstä

IBreakpointManager määrittää nyt metodit setEnabled(boolean) ja isEnabled(). Kun keskeytyskohtien hallintaohjelma on poistettu käytöstä, vianmääritysohjelmien tulisi ohittaa kaikki rekisteröidyt keskeytyskohdat. Vianmääritysympäristö toimittaa myös uuden kuuntelutoiminnon IBreakpointManagerListener, jonka avulla asiakkaat voivat rekisteröityä keskeytyskohtien hallintaohjelmaan, jolle annetaan ilmoitus käyttöönoton muutoksista. Keskeytyskohdat-näkymä kutsuu tätä sovellusohjelmaliittymää uudesta vaihtotapahtumasta, jonka avulla käyttäjä voi "ohittaa kaikki keskeytyskohdat." Tämän vuoksi vianmääritysohjelmat, jotka eivät noudata keskeytyskohtien valvontaohjelman käyttöönottoasetusta, voivat vaikuttaa toimimattomilta, jos käyttäjä yrittää käyttää tätä tuoteominaisuutta.

[Vain JDT] Java-haun osapuolet (paketti org.eclipse.jdt.core.search)

Javaa lähellä olevien kielten (esimerkiksi JSP, SQLJ ja JWS) tulisi pystyä osallistumaan Java-hakuihin. Tällaisten kielten toteuttajien tulisi pystyä erityisesti

Tällaista toteuttajaa kutsutaan haun osapuoleksi. Se laajentaa SearchParticipant-luokan. Haun osapuolet välitetään hakukyselyille (katsoSearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).

Vastineiden indeksointia tai hakua varten haun osapuolen on määritettävä SearchDocument-luokan aliluokka, joka voi noutaa asiakirjan sisällön ohittamalla joko getByteContents()- tai getCharContents()-metodin. Tämän aliluokan ilmentymä palautetaan getDocument(String)-metodissa.

Haun osapuoli, joka haluaa indeksoida jonkin asiakirjan, ajoittaa määritetyn indeksoinnin tietyssä indeksissä SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath)-metodilla. Kun asiakirja on valmis indeksointia varten, pohjalla oleva kehys kutsuu SearchParticipant.indexDocument(SearchDocument, IPath) -metodin. Haun osapuoli saa tällöin asiakirjan sisällön, jäsentää sen ja lisää indeksimerkinnät SearchDocument.addIndexEntry(char[], char[]) -metodilla.

Kun indeksointi on tehty, voidaan kysellä indeksejä ja hakea vastineita metodilla SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Tämä kysyy ensin kultakin haun osapuolelta kyselyn tarvitsemia indeksejä SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope) -metodilla. Kunkin määritettyä mallia vastaavan indeksin merkinnän osalta luodaan hakuasiakirja kysymällä haun osapuolelta (katso getDocument(String)). Kaikki asiakirjat välitetään haun osapuolelle niin, että se voi hakea vastineet locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) -metodilla. Haun osapuoli ilmoittaa SearchRequestor-luokalle hakuvastineista acceptSearchMatch(SearchMatch)-metodilla ja välittämällä SearchMatch-luokan aliluokan ilmentymän.

Haun osapuoli voi delegoida osan työstään Java-haun oletusosapuolelle. Tämän oletusosapuolen ilmentymä saadaan SearchEngine.getDefaultSearchParticipant()-metodilla. Esimerkiksi kun SQLJ-osapuolta pyydetään hakemaan vastineita, se voi luoda asiakirjojen .java-asiakirjoja .sqlj-asiakirjoistaan ja delegoida työn oletusosapuolelle välittämällä sille .java-asiakirjat.