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.
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ä.
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.
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:
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.
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.
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.
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.
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ä.
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.
Kaikki tämän paketin lajit ovat nyt vanhentuneet. Lisätietoja on rekisterien yhteydessä.
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.
filteredSelection
selection
-objektista:
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())); }
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.
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).
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.
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.
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.
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.
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.
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ää.
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:
getPrependBootClassPath()
- palauttaa merkintöjen joukon, joka liitetään aloituspolun eteen (-Xbootclasspath/p
-argumentti)getMainBootClassPath()
- palauttaa merkintöjen joukon, joka liitetään aloituspolkuun (-Xbootclasspath
-argumentti)getAppendBootClassPath()
- palauttaa merkintöjen joukon, joka liitetään aloituspolun perään (-Xbootclasspath/a
-argumentti)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ä.
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:
IWorkingCopy
(package org.eclipse.jdt.core
)
public void commit(boolean, IProgressMonitor)
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
uudelleen muotoon ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
public void destroy()
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
uudelleen muotoon ((ICompilationUnit)
wc).discardWorkingCopy()
public IJavaElement findSharedWorkingCopy(IBufferFactory)
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
korvaa IBufferFactory
-rajapinnan.public IJavaElement getOriginal(IJavaElement)
on vanhentunut.
IJavaElement
-rajapinnassa:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
uudelleen muotoon elt.getPrimaryElement()
IWorkingCopy.getOriginal
, IJavaElement.getPrimaryElement
ei palauta arvoa null
, jos vastaanottaja ei ole työskentelykopio.public IJavaElement getOriginalElement()
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
uudelleen muotoon ((ICompilationUnit)
wc).getPrimary()
IWorkingCopy.getOriginalElement
, IWorkingCopy.getPrimary
ei palauta arvoa null
, jos vastaanottaja ei ole työskentelykopio.public IJavaElement[] findElements(IJavaElement)
on vanhentunut.
ICompilationUnit
-rajapinnassa.wc.findElements(elts)
uudelleen muotoon ((ICompilationUnit)
wc).findElements(elts)
public IType findPrimaryType()
on vanhentunut.
ICompilationUnit
-rajapinnassa.wc.findPrimaryType()
uudelleen muotoon ((ICompilationUnit)
wc).findPrimaryType()
public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
korvaa IBufferFactory
-rajapinnan.public IJavaElement getWorkingCopy()
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
uudelleen muotoon ((ICompilationUnit)
wc).getWorkingCopy(null)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
korvaa IBufferFactory
-rajapinnan.public boolean isBasedOn(IResource)
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public boolean hasResourceChanged()
wc.isBasesOn(res)
uudelleen muotoon ((ICompilationUnit)
wc).hasResourceChanged()
public boolean isWorkingCopy()
on vanhentunut.
ICompilationUnit
-rajapinnassa.wc.isWorkingCopy()
uudelleen muotoon ((ICompilationUnit)
wc).isWorkingCopy()
public IMarker[] reconcile()
on vanhentunut.
ICompilationUnit
-rajapinnassa:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
uudelleen muotoon ((ICompilationUnit)
wc).reconcile(false, null)
null
; korvaava metodi ei palauta tulosta.public void reconcile(boolean, IProgressMonitor)
on vanhentunut.
ICompilationUnit
-rajapinnassa.wc.reconcile(b,monitor)
uudelleen muotoon ((ICompilationUnit)
wc).reconcile(b.monitor)
public void restore()
on vanhentunut.
ICompilationUnit
-rajapinnassa.wc.restore()
uudelleen muotoon ((ICompilationUnit)
wc).restore()
IType
(paketti org.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
on vanhentunut.
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
vaihdon
lajiksi ICompilationUnit[]
.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
on vanhentunut.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
vaihdon
lajiksi ICompilationUnit[]
.IClassFile
(paketti org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
on vanhentunut.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
korvaa IBufferFactory
-rajapinnan.JavaCore
(paketti org.eclipse.jdt.core
)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
on vanhentunut.
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
korvaa IBufferFactory
-rajapinnan.ICompilationUnit[]
vaihdon
lajiksi IWorkingCopy[]
.SearchEngine
(paketti org.eclipse.jdt.core.search
)
public SearchEngine(IWorkingCopy[])
on vanhentunut.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
vaihdon
lajiksi ICompilationUnit[]
.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 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
.
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ä.
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 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++").
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.
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.