Yhteensopimattomuudet Eclipse 2.1- ja 3.0-versioiden välillä

Eclipse on muuttunut 2.1- ja 3.0-versioiden välillä yhteensopimattomilla tavoilla, jotka vaikuttavat lisäosiin. Seuraavat määritykset kuvaavat muuttuneita alueita. Lisäksi niissä on ohjeita 2.1-lisäosien siirtämisestä 3.0-versioon. Huomaa, että näitä tietoja tarvitsee tutkia vain, jos 2.1-lisäosan ajossa 3.0-versiossa ilmenee ongelmia.

  1. Lisäosan manifest-tiedoston versio
  2. Ympäristön käyttöliittymän lisäosien rakenteen uudelleenjärjestely
  3. Ympäristön ydinosan ajonaikaisten lisäosien rakenteen uudelleenjärjestely
  4. Xerces-lisäosan poisto
  5. Eclipse 3.0 on samanaikaisempi
  6. IFile-tiedostojen avaus muokkausohjelmissa
  7. Muokkausohjelman siirtymismerkintä
  8. Muokkausohjelman aloitustoiminto
  9. Muokkausohjelmarekisteri
  10. Työympäristön merkintäohjerekisteri
  11. Tekstinmuokkausohjelman asiakirjan toimittajat
  12. Tekstinmuokkausohjelmat
  13. Näyttöpäätteetön huomautusten tuki
  14. Konsolinäkymä
  15. Java-keskeytyskohtien kuuntelutoiminnot
  16. Leikepöydän käyttö käyttöliittymän säikeessä
  17. Näppäimenpainallustapahtumat
  18. Mukautettujen ohjausobjektien välilehtien läpikäynti
  19. SWT-taulukon ja -rakenteen widget-objektien valintatapahtuman järjestys
  20. Uusi vakavuustaso tilaobjekteissa
  21. Ilmoitukset koontiin liittyvien resurssien muutoksesta
  22. Väli-ilmoitukset työtilan toimintojen aikana
  23. URL-virran käsittelytoiminnon laajennukset
  24. Luokan latausjärjestys
  25. Luokanlataustoiminnon suojausverkkoaluetta ei ole asetettu
  26. PluginModel-objektin lajinvaihto
  27. ILibrary-toteutus puutteellinen
  28. Virheelliset URL-osoitteiden muotoa koskevat oletukset
  29. BootLoader-metodeja siirretty/poistettu
  30. Lisäosan vienti ei sisällä lisäosan JAR-tiedostoja automaattisesti
  31. Ajonaikaisen sovellusohjelmaliittymän uudelleenvienti
  32. Lisäosan jäsennysmetodit ympäristössä
  33. Fragmenttien toimittamat lisäosakirjastot
  34. Muutokset koonnin komentosarjoihin
  35. Muutokset PDE-koonnin Ant-tehtävään
  36. Muutokset eclipse.build-Ant-tehtävään
  37. Muutokset eclipse.fetch-Ant-tehtävään
  38. install.ini-tiedoston korvaus

1. Lisäosan manifest-tiedoston versio

Lisäosien (ja lisäosafragmenttien) manifest-tiedostojen ylätunniste on muuttunut, ja nyt se sisältää uuden rivin, joka yksilöi oikean lisäosan manifest-tiedoston version. Ennen 3.0-versiota lisäosissa ei ollut <?eclipse ...?>-riviä, mutta 3.0-version jälkeen niillä on aina oltava sellainen. Tämän muutoksen tarkoituksena on antaa Eclipse-ohjelmatiedoston tunnistaa luotettavasti versiota 3.0 edeltävät lisäosat, joita ei ole siirretty 3.0-versioon, jotta se voi automaattisesti toimittaa paremman binaarisen yhteensopivuuden kyseisille lisäosille. Seuraavassa on plugin.xml-tiedoston yleinen muoto (fragment.xml on samankaltainen):

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
    ...
</plugin>

PDE 3.0 -version luomilla lisäosan manifest-tiedostoilla on automaattisesti tämä muoto. On erittäin suositeltavaa käyttää PDE-lisäosan siirtotyökalua. Se lisää kyseisen rivin automaattisesti 2.1-lisäosien ja -lisäosafragmenttien manifest-tiedostoon ja hoitaa monta muutakin tässä kuvattua muutosta.

Jos lisäät tämän ohjeen plugin.xml-tiedostoon (manuaalisesti tai PDE:n avulla), tiedosto on aina päivitettävä, jotta se eksplisiittisesti luettelee lisäosat, joihin se perustuu. Esimerkiksi ennen Eclipse 3.0 -versiota org.eclipse.core.runtime- ja org.eclipse.core.boot-riippuvuussuhteet olivat implisiittisiä. 3.0-version myötä org.eclipse.core.boot-pakettia ei enää tarvita, ja sovelluskehittäjien on valittava sopivaksi org.eclipse.core.runtime tai org.eclipse.core.runtime.compatibility (tai ei kumpikaan näistä).

Huomautus: Tämä on yksi yhteensopimattomuuksista, jotka eivät vaikuta siihen, miten Eclipse 3.0 ajaa binaariset 2.1-lisäosat.

2. Ympäristön käyttöliittymän lisäosien rakenteen uudelleenjärjestely

org.eclipse.ui-lisäosa, joka oli ennen ympäristön käyttöliittymän päälisäosa, toimittaa nykyään vain sovellusohjelmaliittymän ja laajennuspisteet yleiselle (eli ei-IDE-kohtaiselle) työympäristölle. Valinnaiset ja IDE-kohtaiset sovellusohjelmaliittymät ja laajennuspisteet on siirretty toisiin lisäosiin.

Tämän muutoksen vaikutus on kaksijakoinen: (1) siirretyillä org.eclipse.ui-laajennuspisteillä on uudet laajennuspisteen tunnukset, ja (2) pakollisten lisäosien luettelo on muuttunut.

Seuraavassa taulukossa luetellut org.eclipse.ui-laajennuspisteet on siirretty toisiin lisäosiin, joten niiden laajennuspisteen tunnukset ovat muuttuneet. Jos olemassa oleva lisäosa toimittaa laajennuksen siirrettyihin laajennuspisteisiin, lisäosan manifest-tiedoston elementin <extension> määritteessä "point" oleva viittaus on vaihdettava viittaamaan vastaavaan uuteen laajennuspisteen tunnukseen. PDE-lisäosan siirtymistyökalu tekee nämä korjaukset.

Huomautus: Tämä on yksi yhteensopimattomuuksista, jotka eivät vaikuta siihen, miten Eclipse 3.0 ajaa binaariset 2.1-lisäosat. Eclipse 3.0 tunnistaa automaattisesti 3.0-versiota edeltävät lisäosat (siitä, että lisäosan manifest-tiedostosta puuttuu edellä kuvattu rivi <?eclipse version="3.0"?>) ja ratkaisee automaattisesti nämä laajennuspisteen ja lisäosan riippuvuussuhteen muutokset.

Vanha laajennuspisteen tunnus

Uusi laajennuspisteen tunnus

org.eclipse.ui.markerHelp org.eclipse.ui.ide.markerHelp
org.eclipse.ui.markerImageProviders org.eclipse.ui.ide.markerImageProviders
org.eclipse.ui.markerResolution org.eclipse.ui.ide.markerResolution
org.eclipse.ui.projectNatureImages org.eclipse.ui.ide.projectNatureImages
org.eclipse.ui.resourceFilters org.eclipse.ui.ide.resourceFilters
org.eclipse.ui.markerUpdaters org.eclipse.ui.editors.markerUpdaters
org.eclipse.ui.documentProviders org.eclipse.ui.editors.documentProviders
org.eclipse.ui.workbench.texteditor.
markerAnnotationSpecification
org.eclipse.ui.editors.markerAnnotationSpecification

Seuraavassa taulukossa on luettelo org.eclipse.ui-lisäosan aiemmin toimittamista sovellusohjelmaliittymäpaketeista, jotka on siirretty eri lisäosiin. (Sovellusohjelmaliittymäpakettien, luokkien, kenttien ja metodien nimet eivät ole muuttuneet.) Joissakin tapauksissa sovellusohjelmaliittymäpaketit on jaettu useampaan kuin yhteen lisäosaan. Koska tietylle lisäosalle näkyvissä olevat sovellusohjelmaliittymän luokat määräytyvät kyseisen lisäosan pakollisten lisäosien luettelon mukaan, nämä muutokset saattavat edellyttää olemassa olevan lisäosan manifest-tiedoston "<requires>"-elementtien muokkausta, jotta sovellusohjelmaliittymäluokan käyttö on jälleen mahdollista.

Tämä muutos vaikuttaa vain lisäosiin, jotka ovat riippuvaisia org.eclipse.ui-lisäosasta (eli lisäosan manifest-tiedoston <requires>-osassa on <import plugin="org.eclipse.ui"/>); tämä ei vaikuta muihin lisäosiin. Jos vaikutus kohdistuu lisäosaan, on mahdollista, että on tarpeen muuttaa <import>-elementtiä tai lisätä uusia <import>-elementtejä, että kaikki lisäosan tarvitsemat sovellusohjelmaliittymän luokat ovat käyttöalueella. On suositeltavaa, että lisäosat ilmoittavat riippuvuussuhteita vain lisäosiin, joita ne todella käyttävät. Tarpeettomien riippuvuussuhteiden sisällytys heikentää ajonaikaista suorituskykyä, sillä Java-luokanlataustoiminnon on haettava kaikkien riippuvuussuhteiden luokkia. (PDE-lisäosan siirtymistyökalu korjaa riippuvuussuhteet ja auttaa mahdollisimman pienen joukon määrityksessä.)

Sovellusohjelmaliittymäpaketti

2.1-lisäosa

Vastaavat 3.0-lisäosat

org.eclipse.jface.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.ui org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.actions org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.dialogs org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.editors.* org.eclipse.ui org.eclipse.ui.editor
org.eclipse.ui.model org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.part org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.texteditor org.eclipse.ui org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors
org.eclipse.ui.texteditor.* org.eclipse.ui org.eclipse.ui.workbench.texteditor
org.eclipse.ui.views.bookmarkexplorer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.contentoutline org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.markers org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.navigator org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.properties org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.tasklist org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.datatransfer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.newresource org.eclipse.ui org.eclipse.ui.ide

3. Ympäristön ydinosan ajonaikaisten lisäosien rakenteen uudelleenjärjestely

Ajonaikainen Eclipse 3.0 -ympäristö on OSGi-pohjainen, mikä edellyttää muutoksia kahden ajonaikaisen ympäristön lisäosan rakenteeseen. Nämä lisäosat ovat org.eclipse.core.runtime ja org.eclipse.core.boot.

Uusi org.eclipse.core.runtime.compatibility-lisäosa toimittaa toteutussillan vanhojen ja uusien sovellusohjelmaliittymien välille ja on monien käytöstä pois jääneiden, aiemmin org.eclipse.core.runtime- tai org.eclipse.core.boot-lisäosassa sijainneiden sovellusohjelmaliittymien uusi koti. Rakenteen uudelleenjärjestely ei vaikuta ajonaikaisen ympäristön laajennuspisteisiin.

Kun olemassa oleva lisäosa siirretään 3.0-versioon, lisäosan manifest-tiedosto on päivitettävä ajonaikaisen Eclipse-ympäristön lisäosien uuden rakenteen mukaiseksi. PDE-lisäosan manifest-tiedostojen siirtymistyökalu lisää tarvittaessa riippuvuussuhteen org.eclipse.core.runtime.compatibility-lisäosaan.

Huomaa myös, että jos merkitset lisäosan 3.0-version mukaiseksi (rivillä <?eclipse version="3.0"?>) ja lisäosa määrittää lisäosaluokan, on joko eksplisiittisesti lisättävä lisäosan manifest tiedostoon <import plugin="org.eclipse.core.runtime.compatibility"/> tai varmistuttava, että lisäosaluokka määrittää oletuskonstruktorin.

Huomautus: Tämä on yksi yhteensopimattomuuksista, jotka eivät vaikuta siihen, miten Eclipse 3.0 ajaa binaariset 2.1-lisäosat. Eclipse 3.0 tunnistaa automaattisesti 3.0-versiota edeltävät lisäosat (siitä, että lisäosan manifest-tiedostosta puuttuu rivi <?eclipse version="3.0"?>) ja ratkaisee automaattisesti nämä ajonaikaiseen ympäristöön kohdistuneet muutokset.

4. Xerces-lisäosan poisto

org.eclipse.xerces-lisäosaa ei enää tarvita, ja se on poistettu. J2SE 1.4 sisältää XML-jäsennyksen tuen, ja Xerces-lisäosan olemassaolo aiheuttaa luokanlataustoiminnon ristiriitoja. org.eclipse.xerces-lisäosan aiemmin toimittamat sovellusohjelmaliittymäpaketit javax.xml.parsers, org.w3c.dom.* ja org.xml.sax.* ovat nyt käytettävissä J2SE-kirjastoista.

Jos lisäosa edellyttää org.eclipse.xerces-lisäosaa, lisäosan manifest-tiedostoa on muutettava niin, että tämä ilmaistu riippuvuussuhde poistetaan. Kun tämä on tehty, lisäosan koodin käännöksen ja ajon pitäisi onnistua ilman muita muutoksia.

Binaariselta 2.1-lisäosalta, jolla on ilmaistu riippuvuussuhde org.eclipse.xerces-lisäosaan, puuttuu ennakkoehto, kun se ajetaan tavallisessa Eclipse 3.0 -kokoonpanossa. Tämän seurauksena lisäosa ei aktivoidu.

5. Eclipse 3.0 on samanaikaisempi

Ennen Eclipse 3.0 -versiota Eclipse toimi lähinnä yksisäikeisesti. Useimmat sovellusohjelmaliittymämetodit ja -laajennuspisteet toimivat joko käyttöliittymän säikeessä tai säikeessä, joka syntyi käyttöliittymän säikeen lukinneesta tilannetietojen valintaikkunasta. Useimpien lisäosien kirjoitusohjelmien ei tarvinnut erityisesti välittää säieturvallisuudesta muuten kuin varmistamalla, että kaikki käyttöliittymän toiminnot tapahtuivat käyttöliittymän säikeessä. Eclipse 3.0 -versiossa on entiseen verrattuna enemmän samanaikaisuutta. Monet tehtävät tapahtuvat nyt taustasäikeessä, jossa ne voivat ajaa samanaikaisesti toisten säikeiden kanssa, myös käyttöliittymän säikeen. Kaikkien lisäosien, joiden koodi ajetaan taustasäikeessä, tulee olla tietoinen koodinsa säieturvallisuudesta.

Eksplisiittisesti toimintoja taustalla org.eclipse.core.runtime.jobs-sovellusohjelmaliittymällä ajavien lisäosien lisäksi on monia ympäristön sovellusohjelmaliittymän toimintoja ja laajennuspisteitä, jotka käyttävät taustasäikeitä. Näihin toimintoihin kytkeytyvien lisäosien on varmistettava, että niiden oma koodi on säieturvallinen. Seuraavassa taulukossa on yleiskuvaus sovellusohjelmaliittymistä ja laajennuspisteistä, jotka ajavat osan tai kaiken koodinsa taustasäikeessä Eclipse 3.0 -versiossa:

Laajennuspiste tai sovellusohjelmaliittymäluokka

Huomautukset

org.eclipse.core.runtime.IRegistryChangeListener Uusi Eclipse 3.0 -versiossa, ajetaan taustalla
org.eclipse.core.resources.IResourceChangeListener AUTO_BUILD-tapahtumat nyt taustalla
org.eclipse.core.resources.builders (ext. point) Automaattinen koonti nyt taustalla
org.eclipse.core.resources.ISaveParticipant SNAPSHOT nyt taustalla
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (ext. point) Uusi Eclipse 3.0 -versiossa, ajetaan taustalla
org.eclipse.ui.decorators (ext. point) Taustalla jo Eclipse 2.1 -versiossa
org.eclipse.ui.startup (ext. point) Taustalla jo Eclipse 2.1 -versiossa
org.eclipse.team.core.org.eclipse.team.core.repository (ext. point) Monet toiminnot nyt taustalla
org.eclipse.team.ui.synchronizeParticipants (ext. point) Uusi Eclipse 3.0 -versiossa, ajetaan taustalla
org.eclipse.debug.core.launchConfigurationTypes (ext. point) Ajetaan nyt taustalla
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD ajetaan nyt taustalla, POST_RECONCILE ajettiin ennenkin taustalla

Koodista voi tehdä säieturvallista monella eri tavalla. Alkeellinen ratkaisu on varmistaa, että kaikki työ tapahtuu käyttöliittymän säikeessä, jolloin varmistetaan peräkkäinen toteutus. Tämä on yleinen lähestymistapa käyttöliittymän lisäosille, jotka eivät tee suoritinpainotteista käsittelyä. Näin toimittaessa tulee olla tietoinen Display.syncExec-metodissa piilevästä lukkiutumariskistä. Display.asyncExec on yleisesti ottaen turvallisempi, sillä siihen ei liity lukkiutumariskiä, mutta koodin ajohetken tarkka ohjaus saatetaan menettää.

Muita tekniikoita, joilla tuotetaan säieturvallista koodia, ovat muun muassa seuraavat:

6. IFile-tiedostojen avaus muokkausohjelmissa

Seuraavat metodit on poistettu org.eclipse.ui.IWorkbenchPage-rajapinnasta. IWorkbenchPage esitellään yleisessä työympäristössä, mutta metodit ovat lähtökohtaisesti resurssikohtaisia.

Näiden IWorkbenchPage.openEditor-metodien asiakkaiden tulisi niiden sijaan kutsua vastaavia julkisia staattisia metodeja, jotka on esitelty luokassa org.eclipse.ui.ide.IDE (org.eclipse.ui.ide-lisäosassa).

Näiden IWorkbenchPage.openSystemEditor(IFile)-metodien asiakkaiden tulisi muuntaa IFile IEditorInput-rajapinnaksi uuden FileEditorInput(IFile)-konstruktorin avulla ja kutsua sitten openEditor(IEditorInput,String)-metodi. Toisin sanoen kirjoita page.openSystemEditor(file) uudelleen muodossa page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Huomautus: asiakkaiden, jotka käyttävät muokkausohjelman tunnusta IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID, on välitettävä muokkausohjelman syöte, joka toteuttaa org.eclipse.ui.IPathEditorInput-rajapinnan (minkä FileEditorInput tekee).

Huomautus: Tämä on yksi yhteensopimattomuuksista, jotka eivät vaikuta siihen, miten Eclipse 3.0 ajaa binaariset 2.1-lisäosat. Eclipse 3.0 sisältää binaarisen ajonaikaisen yhteensopivuuden mekanismin, joka varmistaa, että olemassa olevat binaariset 2.1-lisäosat, jotka käyttävät poistettuja openEditor- ja openSystemEditor-metodeja, toimivat edelleen samalla tavalla kuin 2.1-versiossa tästä sovellusohjelmaliittymän muutoksesta huolimatta. Fragmentti org.eclipse.ui.workbench.compatibility "lisää takaisin" poistetut metodit.)

7. Muokkausohjelman siirtymismerkintä

Seuraava metodi on poistettu org.eclipse.ui.IEditorPart-rajapinnasta. IEditorPart esitellään yleisessä työympäristössä, mutta metodi on lähtökohtaisesti resurssikohtainen.

Vastaavat metodit on poistettu myös org.eclipse.ui.part-paketin luokista, jotka toteuttavat IEditorPart-rajapinnan, eli EditorPart, MultiEditor, MultiPageEditorPart ja MultiPageEditor. 

Tätä metodia kutsuvien asiakkaiden tulisi niiden sijaan kokeilla, toteuttaako muokkausohjelmaosa org.eclipse.ui.ide.IGotoMarker-rajapinna (lisäosassa org.eclipse.ui.ide) tai on sen mukainen. Jos näin on, kutsu gotoMarker(IMarker). IDE-luokalla on kätevä metodi tämän tekemiseen: IDE.gotoMarker(editor, marker);

Asiakkaiden, jotka toteuttavat itsensä IMarker-tietojen mukaan sijoittamaan pystyvän muokkausohjelman, tulisi toteuttaa tai org.eclipse.ui.ide.IGotoMarker tai sovittua siihen.

Koska IGotoMarker-rajapinnan ainoa metodi on gotoMarker(IMarker) ja sillä on sama tunnus ja määritys kuin vanhalla IEditorPart.gotoMarker(IMarker)-metodilla, olemassa olevat muokkausohjelman toteutukset voivat sopeutua tähän muutokseen yksinkertaisesti sisällyttämällä IGotoMarker-rajapinnan luokan määrityksen implements-lauseeseen.

2.1-binaarilisäosa, jossa oleva koodi kutsuu tätä metodia, aiheuttaa luokanlinkityspoikkeuksen, kun se ajetaan tavallisessa Eclipse 3.0 -kokoonpanossa.

8. Muokkausohjelman aloitustoiminto

Muokkausohjelman aloitustoiminnon rajapinta org.eclipse.ui.IEditorLauncher toteutetaan lisäosilla, jotka toimittavat ulkoisia muokkausohjelmia. Seuraava metodi on poistettu tästä rajapinnasta. IEditorLauncher esitellään yleisessä työympäristössä, mutta metodi on lähtökohtaisesti resurssikohtainen.

Sen on korvannut

Asiakkaiden, jotka kutsuvat IEditorLauncher.open(file)-metodin, tulee sen sijaan kutsua IEditorLauncher.open(file.getLocation()). Asiakkaiden, jotka toteuttavat tämän rajapinnan, tulisi korvata (tai lisätä) open(IFile)-toteutuksensa open(IPath)-toteutuksella.

2.1-binaarilisäosa, jossa oleva koodi kutsuu tätä metodia, aiheuttaa luokanlinkityspoikkeuksen, kun se ajetaan tavallisessa Eclipse 3.0 -kokoonpanossa.

9. Muokkausohjelmarekisteri

Seuraavat metodit on poistettu org.eclipse.ui.IEditorRegistry-rajapinnasta. IEditorRegistry esitellään yleisessä työympäristössä, mutta metodit ovat lähtökohtaisesti resurssikohtaisia.

Asiakkaiden, jotka kutsuvat getEditors(file)- tai getImageDescriptor(file)-metodin, tulisi kutsua "String"-merkkijonoa vastaavia metodeja: Asiakkaiden, jotka kutsuvat setDefaultEditor(IFile file, String editorId)- ja getDefaultEditor(IFile file) -metodeja, tulisi niiden sijaan kutsua vastaavia julkisia staattisia metodeja, jotka on esitelty luokassa org.eclipse.ui.ide.IDE (lisäosassa org.eclipse.ui.ide plug-in): Myös metodin IEditorRegistrygetDefaultEditor() sovellusohjelmaliittymäsopimus on muuttunut. Tämä metodi, joka on nyt myös vanhentunut, palauttaa aina järjestelmän ulkoisen muokkausohjelman kuvaajan. Tämä muutos vaikuttaa asiakkaisiin, jotka olettivat, että palautettu oletusmuokkausohjelma olisi tekstinmuokkausohjelma.

Järjestelmän ulkoisen muokkausohjelman ja järjestelmän sisäisen muokkausohjelman tunnisteita kuvaavat uudet vakiot (SYSTEM_EXTERNAL_EDITOR_ID ja SYSTEM_INPLACE_EDITOR_ID). Nämä kaksi muokkausohjelmaa edellyttävät muokkausohjelman syötettä, joka toteuttaa org.eclipse.ui.IPathEditorInput-rajapinnan tai sovittuu siihen. Huomaa, että sisäisen muokkausohjelman kuvaajaa ei ole Eclipse-kokoonpanoissa, jotka eivät tue sisäistä muokkausta.

10. Työympäristön merkintäohjerekisteri

Seuraava metodi on poistettu org.eclipse.ui.IWorkbench-rajapinnasta. IWorkbench esitellään yleisessä työympäristössä, mutta metodi on lähtökohtaisesti resurssikohtainen.

IWorkbench.getMarkerHelpRegistry()-asiakkaiden tulisi sen sijaan kutsua julkista staattista metodia org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (lisäosassa org.eclipse.ui.ide).

2.1-binaarilisäosa, jossa oleva koodi kutsuu tätä metodia, aiheuttaa poikkeuksen, kun se ajetaan tavallisessa Eclipse 3.0 -kokoonpanossa.

11. Tekstinmuokkausohjelman asiakirjan toimittajat

Jotta org.eclipse.ui.texteditor.AbstractTextEditor ei olisi riippuvainen IFile-tiedostosta, org.eclipse.ui.texteditor.AbstractDocumentProvider esittelee asiakirjan toimittajatoiminnot (DocumentProviderOperation) ja asiakirjan toimittajatoimintojen runner-objektin (IRunnableContext). Kun palautusta, tallennusta tai synkronointia pyydetään, AbstractDocumentProvider luo asiakirjan toimittajatoiminnot ja ajaa ne toimintojen runner-objektin avulla. Aliluokat voivat toimittaa ajettavan kontekstin getOperationRunner-metodin välityksellä. Seuraavassa on yleiskuvaus muutoksista, joihin asiakkaidentulee sopeutua:

AbstractDocumentProvider-aliluokka org.eclipse.ui.editors.text.StorageDocumentProvider toteuttaa getOperationRunner-metodin palauttamaan aina tyhjäarvon. Tämä tarkoittaa sitä, että tämän muutoksen ei pitäisi vaikuttaa StorageDocumentProvider-luokan aliluokkiin.

StorageDocumentProvider-aliluokka org.eclipse.ui.editors.text.FileDocumentProvider toteuttaa getOperationRunner-metodin, joka palauttaa IRunnableContext-rajapinnan määritettyjen DocumentProviderOperation-konstruktorien WorkspaceModifyOperation-luokan sisällä toteuttamista varten. Muita FileDocumentProvider-luokkaan tehtyjä muutoksia ovat seuraavat:

12. Tekstinmuokkausohjelmat

Muutokset org.eclipse.ui.texteditor.AbstractTextEditor-luokkaan:

AbstractTextEditor-aliluokka org.eclipse.ui.texteditor.StatusTextEditor toimittaa predikaattimetodin isErrorStatus(IStatus). Aliluokat voivat ohittaa määrittäessään, tuleeko tiettyä tilaa pitää virheenä.

Muutokset org.eclipse.ui.editors.text.AbstractDecoratedTextEditor-luokkaan:

13. Näyttöpäätteetön huomautusten tuki

Näyttöpäätteettömän huomautusten tuen osana huomautuksiin on tehty seuraavat muutokset:

        org.eclipse.jface.text.source.Annotation 
        org.eclipse.jface.text.source.AnnotationModel 
        org.eclipse.jface.text.source.AnnotationModelEvent 
        org.eclipse.jface.text.source.IAnnotationModel 
        org.eclipse.jface.text.source.IAnnotationModelListener 
        org.eclipse.jface.text.source.IAnnotationModelListenerExtension

14. Konsolinäkymä

Eclipse 3.0 -versiossa on uusi yleinen konsolin tuki. Yleiskonsoli on käytettävissä Ikkuna > Näytä näkymä > Perus > Konsoli -valikosta, ja Eclipse-vianmääritys ja Ant-integrointi käyttävät sitä.

Konsolin näkymätunnus on muuttunut org.eclipse.debug.ui.ConsoleView-näkymästä org.eclipse.ui.console.ConsoleView-näkymään. 2.1-lisäosat, jotka avaavat konsolin ohjelmallisesti, eivät onnistu, sillä vanhaa näkymää ei ole enää olemassa.

15. Java-keskeytyskohtien kuuntelutoiminnot

3.0-versiossa metodien org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) ja installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) palautustyyppi on muuttunut totuusarvosta kokonaisluvuksi, jotta kuuntelutoiminnot voisivat "olla välittämättä". Versiota 3.0 edeltävissä versioissa kuuntelutoimintojen ainoat vaihtoehdot keskeytyskohdan osumisen yhteydessä olivat "keskeytä" tai "älä keskeytä" ja "asenna" tai "älä asenna" keskeytyskohdan asennuksen yhteydessä. Versiossa 3.0 kuuntelutoiminnoilla on valittavissa myös "älä välitä" molempien ilmoitusten kohdalla. Näin asiakkaat voivat tehdä päätöksiä vain tilanteista, joista he väittävät. "Keskeytyskohdan osuman" ilmoitusten yhteydessä keskeytyskohta keskeytetään, jos jokin kuuntelutoiminto valitsee "keskeytä"-vaihtoehdon tai kaikki kuuntelutoiminnot valitsevat "älä välitä"; keskeytys ei tapahdu, jos ainakin yksi kuuntelutoiminto valitsee "älä keskeytä"-vaihtoehdon eikä mikään kuuntelutoiminto valitse "keskeytä"-vaihtoehtoa. Samalla tavalla "keskeytyskohdan asennuksen" ilmoitusten yhteydessä keskeytyskohta asennetaan, jos jokin kuuntelutoiminto valitsee asennuksen tai kaikki kuuntelutoiminnot valitsevat "älä välitä"; asennusta ei tehdä, jos ainakin yksi kuuntelutoiminto valitsee "älä asenna"-vaihtoehdon eikä mikään kuuntelutoiminto valitse "asenna"-vaihtoehtoa. Yleisesti ottaen toteuttajien tulee palauttaa arvo DONT_CARE, ellei niillä ole vahvaa mielipidettä suuntaan tai toiseen. On tärkeää pitää mielessä, että esimerkiksi vaihtoehdon "keskeytä" valinta ohittaa kaikkien muiden kuuntelutoimintojen valinnan "älä keskeytä".

Asiakkaat, jotka luovat Java-koodin keskeytyskohtia tai reagoivat niihin, toteuttavat IJavaBreakpointListener-rajapinnan. Itse JDT:n ulkopuolella on luultavasti erittäin vähän asiakkaita lukuun ottamatta sitä, joka ilmoitti häiriön (virhe 37760), jonka tämä muutos korjaa. Tämä on IJavaBreakpointListener-rajapinnan toteuttavan olemassa olevan koodin keskeytysmuutos. Koodia on muutettava, jotta saadaan likimääräinen kokonaislukuarvo ennen sen käännöstä tai ajoa 3.0-versiossa.

16. Leikepöydän käyttö käyttöliittymän säikeessä

Versiota 3.0 edeltäneissä versioissa SWT-luokan org.eclipse.swt.dnd.Clipboard metodien ajo muissa säikeissä kuin käyttöliittymän säikeissä sallittiin epäsuorasti. Tämä aiheutti häiriöitä GTK:ssa, jossa käyttöjärjestelmä edellyttää kaikkien leikepöydän toimintojen tapahtuvan käyttöliittymän säikeessä. Virhe ei paljastunut aiemmin, sillä monet sovellukset ovat yksisäikeisiä ja suurin osa niiden testauksesta tapahtuu Windowsissa. Jotta Leikepöytä-sovellusohjelmaliittymä olisi vakaa ja sekaympäristöinen, 3.0-versiossa kaikki Leikepöytä-sovellusohjelmaliittymän metodien määritykset ja toteutukset on muutettu tuottamaan SWT-poikkeus (ERROR_THREAD_INVALID_ACCESS), jos niitä kutsutaan säikeestä, joka ei ole käyttöliittymän säie. Eclipsen komponentit, esimerkiksi tekstinmuokkausohjelma, toimittavat leikepöytätoiminnot yleensä automaattisesti, mikä eristää monet asiakkaat tästä keskeytysmuutoksesta. Olemassa olevan koodin, joka käyttää Leikepöytää suoraan, tulisi varmistaa, että sovellusohjelmaliittymän metodit kutsutaan oikeassa säikeessä, siirtämällä käytön tarvittaessa käyttöliittymän säikeeseen Display.asyncExec- tai syncExec-metodilla.

17. Näppäimenpainallustapahtumat

3.0-versiossa SWT ilmoittaa näppäimenpainallustapahtumat ennen työn tekemistä käyttöjärjestelmässä. Tämä tapahtuu paljon aikaisemmin kuin 3.0-versiota edeltäneissä versioissa. Muutoksen tarkoituksena on tukea Eclipse-ympäristön näppäinsidontoja, jotka edellyttävät näppäintapahtumien sieppausta, ennen kuin millään widget-objektilla on mahdollisuus käsitellä merkki. Muutoksen seuraukset näkyvät koodille, joka käsittelee alatason org.eclipse.swt.SWT.KeyDown-tapahtumahakemistoa. Se tarkoittaa esimerkiksi sitä, että kun tekstin widget-olion kuuntelutoiminto vastaanottaa näppäintapahtuman, widget-objektin sisältö (getText()) ei vielä sisällytä juuri näppäiltyä painiketta (minkä se olisi tehnyt ennen 3.0-versiota). Suositeltu tapa täyden tekstin hakuun nykyisen näppäimen sisältävästä widget-objektista on käsitellä ylätason SWT.Modify- tai SWT.Verify-tapahtumia eikä alatason SWT.KeyDown-tapahtumaa; tämä muutos ei vaikuta koodiin, joka tekee sen jo tällä tavalla.

18. Mukautettujen ohjausobjektien välilehtien läpikäynti

Kun tarkennus oli 3.0-versiota edeltäneissä versioissa SWT-luokassa org.eclipse.swt.widgets.Canvas tai jossain sen aliluokista (mukaan luettuina mukautetut widget-objektit), näppäinyhdistelmä Ctrl+sarkain, vaihto+sarkain, Ctrl+PgUp tai Ctrl+PgDn liipaisivat automaattisesti siirtymisen seuraavaan tai edelliseen widget-objektiin ilman näppäintapahtuman ilmoitusta. Tätä toimintaa ei ollut määritetty, ja se oli sen periaatteen vastainen, että Canvas-luokkien pitää nähdä kaikki niissä painetut näppäimet. Oikea tapa käsitellä siirtymistä on rekisteröidä siirtymisen kuuntelutoiminto. Eclipsen näppäinsidontojen oikeanlainen tuki on toteutettu 3.0-versiossa muuttamalla oletustoimintaa niin, että nyt Canvas-luokka näkee Ctrl+sarkain-, vaihto+sarkain-, Ctrl+PgUp- ja Ctrl+PgDn-näppäintapahtumat siirtymisen sijaan. Jos käytössä on muotoilematon Canvas-luokka tai määritetään Canvas-luokan aliluokka, on rekisteröitävä siirtymisen kuuntelutoiminto.

19. SWT-taulukon ja -rakenteen widget-objektien valintapahtuman järjestys

SWT-luokkien org.eclipse.swt.widgets.Table ja Tree objektien hiirivalinnat luovat tapahtumasarjan MouseDown-Selection-MouseUp yhtäläisesti kaikissa käyttöympäristöissä. Vastaavasti näppäimistövalinnat luovat tapahtumasarjan KeyDown-Selection-KeyUp yhtäläisesti kaikissa käyttöympäristöissä. Ennen 3.0-versiota tapahtumien järjestys ei ollut yhtäläinen, vaan Motif ja Photon erosivat muista ilmoittamalla aina ensin Selection-tapahtuman, eli järjestys oli Selection-MouseDown-MouseUp tai Selection-KeyDown-KeyUp. 3.0-versiossa Motif- ja Photon-tapahtumajärjestys on muutettu vastaamaan muita. Tällä ei todennäköisesti ole vaikutusta olemassa olevaan koodiin, joka toimi oikein {Windows, GTK}- ja {Motif, Photon} -järjestelmissä. On kuitenkin hyvä tarkistaa koodista, ettei se perustu virheelliseen tapahtumajärjestykseen.

20. Uusi vakavuustaso tilaobjekteissa

org.eclipse.core.runtime.IStatus sisältää uuden vakavuusvakion IStatus.CANCEL, jota voidaan käyttää osoittamaan peruutusta. Tämä lisäys vaikuttaa IStatus.getSeverity()-metodin kutsujiin, jotka turvautuvat mahdollisten vakavuuksien joukkoon, joka sisältää ainoastaan vakiot IStatus.OK, INFO, WARNING ja ERROR. getSeverity-metodin kutsujien koodi tulee päivittää sisältämään uusi vakavuus.

21. Ilmoitukset koontiin liittyvien resurssien muutoksesta

Eclipse 3.0 -versiossa työtilan automaattiset koonnit tapahtuvat taustasäikeessä. Tämä edellytti sovellusohjelmaliittymäsopimuksen muutosta org.eclipse.core.resources.IResourceChangeEvent-rajapintaan. Aiemmin IResourceChangeEvent-rajapinnan sopimus varmisti seuraavan kaikkien työtilan muutosten tapahtumien järjestyksen:

  1. Ilmoitus mahdollisesta PRE_DELETE- tai PRE_CLOSE-tapahtumasta
  2. Toiminnon tekeminen
  3. Ilmoitus PRE_AUTO_BUILD-tapahtumasta
  4. Jos automaattinen koonti on käytössä, vaiheittainen työtilan koonti
  5. Ilmoitus POST_AUTO_BUILD-tapahtumasta
  6. Ilmoitus POST_CHANGE-tapahtumasta

Kun automaattinen koonti ajetaan nyt taustalla, AUTO_BUILD-tapahtumien ja POST_CHANGE-tapahtuman ajallista suhdetta ei voida taata. Eclipse 3.0 -versiossa edellä kuvatun rakenteen vaiheet 3 - 5 on poistettu käytöstä. Tulos näyttää seuraavalta:

  1. Ilmoitus mahdollisesta PRE_DELETE- tai PRE_CLOSE-tapahtumasta
  2. Toiminnon tekeminen
  3. Ilmoitus POST_CHANGE-tapahtumasta

Ympäristö tekee ajoittain taustalla työtilan koonnin. Huomaa, että tämä tapahtuu riippumatta siitä, onko automaattinen koonti käytössä. Koonnin tarkkaa tapahtumahetkeä ei määritetä. Koontitoiminnon rakenne näyttää seuraavalta:

  1. Ilmoitus PRE_BUILD-tapahtumasta (PRE_BUILD on uusi nimi PRE_AUTO_BUILD-tapahtumalle)
  2. Jos automaattinen koonti on käytössä, vaiheittainen työtilan koonti
  3. Ilmoitus POST_BUILD-tapahtumasta (POST_BUILD on uusi nimi POST_AUTO_BUILD-tapahtumalle)
  4. Ilmoitus POST_CHANGE-tapahtumasta

Automaattisen koonnin kuuntelutoimintojen vastaanottamien deltojen viitekohta on eri kuin post-change-tapahtuman kuuntelutoimintojen. Koonnin kuuntelutoiminnot saavat ilmoituksen kaikista viime koontitoiminnon lopun jälkeen tapahtuneista muutoksista. Post-change-tapahtuman kuuntelutoiminnot saavat deltan, joka kuvaa kaikki muutokset edellisen post-change-ilmoituksen jälkeen. Tämä uusi rakenne sisältää edelleen kolme resurssien muutosten kuuntelutoimintojen ominaisuutta, jotka ovat olleet mukana Eclipse 1.0 -versiosta lähtien:

Tässä lähestymistavassa on kuitenkin muutamia merkittäviä eroja. Ennen Eclipse 3.0 -versiota automaattisen koonnin kuuntelutoiminnot kutsuttiin aina ennen POST_CHANGE-kuuntelutoimintoja. Tämän vuoksi automaattisen koonnin kuuntelutoimintojen vastaanottama delta oli aina POST_CHANGE-kuuntelutoimintojen vastaanottaman deltan osajoukko. Tämä suhde on nyt pääosin päinvastainen. Automaattisen koonnin kuuntelutoiminnot vastaanottavat deltan, joka on kaikkien edellisen taustakoonnin lopun jälkeen POST_CHANGE-kuuntelutoiminnoille toimitettujen deltojen yläjoukko. Kuten ennenkin, automaattisen koonnin kuuntelutoiminnoilla on oikeus muuttaa työtilaa ja post-change-kuuntelutoiminnoilla puolestaan ei.

Enää ei ole niin, että AUTO_BUILD-tapahtuman kuuntelutoiminnoille on ilmoitettu työtilan muutostoiminnon päättymisen yhteydessä. Tällä muutoksella ei todennäköisesti ole vaikutusta asiakaskoodiin, joka rekisteröi resurssien muutoksen kuuntelutoimintojaIWorkspace.addResourceChangeListener(IResourceChangeListener)-metodilla, sillä näille kuuntelutoiminnoille ei ole koskaan ilmoitettu AUTO_BUILD-tapahtumista. Tämä muutos kuitenkin todennäköisesti keskeyttää asiakkaat, jotka käyttävätIWorkspace.addResourceChangeListener(IResourceChangeListener,int)-metodia ja määrittävät tapahtumapeitteen, joka sisältää AUTO_BUILD-tapahtumat, jos ne tekevät oletuksia siitä, milloin automaattisen koonnin kuuntelutoiminnot ajetaan tai missä säikeessä ne ajetaan. Jos automaattisen koonnin kuuntelutoiminto esimerkiksi päivittää verkkoaluemallia työtilaan tehtyjen muutosten mukaiseksi, tätä päivitystä ei ehkä ole tapahtunut, kun työtilaa muuttava toiminto palautuu. Tulisi huomata, että näin voi vaikuttaa ainoastaan käyttöliittymän tason koodiin. Ydinosan tason koodi, joka kutsutaan sovellusohjelmaliittymän kautta, voidaan kutsua IWorkspaceRunnable-rajapinnan mukaisesti, joten se ei voi koskaan olla varma, milloin resurssien muutoksen kuuntelutoimintoja kutsutaan. Tämän ongelman ehdotettu tilapäiskorjaus on käyttää POST_CHANGE-kuuntelutoimintoja koonnin kuuntelutoimintojen sijaan, jos on tarve saada ilmoitus tapahtumaan ennen toiminnon päättymistä.

22. Väli-ilmoitukset työtilan toimintojen aikana

Enää ei ole varmaa, että kaikki IWorkspaceRunnable-rajapinnan dynaamisen alueen aikana tapahtuvat resurssien muutokset kootaan yhdeksi ilmoitukseksi. Tätä mekanismia voi edelleen käyttää muutosten kokoamisessa tarpeettomien koontien ja ilmoitusten välttämistä varten, mutta ympäristö voi nyt päättää tehdä ilmoituksia toiminnan aikana. Tämä sovellusohjelmaliittymäsopimuksen muutos ei todennäköisesti ole keskeyttävä muutos nykyisille asiakkaille. Se vastaa sitä, että ympäristö päättää kutsua IWorkspace.checkpoint-metodia ajoittain pitkään kestävien toimien aikana. Tämän muutoksen syynä on, että nyt moni säie voi muokata työtilaa samanaikaisesti. Kun yksi säie lopettaa työtilan muuttamisen, edellytetään ilmoitusta reagointivirheiden välttämistä varten, vaikka jokin toinen toimi ei olisikaan vielä valmis. Tämän muutoksen ansiosta myös käyttäjät voivat aloittaa resurssien käsittelyn ennen toimen päättymistä. Esimerkiksi käyttäjä voi nyt alkaa selata edelleen tarkistettavassa projektissa olevia tiedostoja. Uudella metodilla IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) on valinnainen määrite AVOID_UPDATE, jota käyttämällä toiminnot voivat vihjata ympäristöä määrittämään, ovatko ajoittaiset päivitykset toivottuja.

23. URL-virran käsittelytoiminnon laajennukset

Mitä muutos koskee: Lisäosia, jotka toimittavat laajennuksia org.eclipse.core.runtime.urlHandlers-laajennuspisteeseen.

Kuvaus: org.eclipse.core.runtime.urlHandlers-laajennuspisteen sopimusta on muutettu käyttämään OSGi:n toimittamaa URL Stream Handler -palvelua. OSGi-tuki on ylivertainen Eclipse 2.1 -versiossa olleeseen, ja se käsittelee dynaamisia käsittelytoimintoja oikein. Useiden Javan URL-peruskäsittelytoiminnon toimintaan liittyvien rakenteellisten seikkojen vuoksi OSGi-käsittelytoimintopalvelulla rekisteröityjen URLStreamHandlers-käsittelytoimintojen on toteutettava org.osgi.service.url.URLStreamHandlerService.

Edellytetty toimi: Aiemmin käsittelytoiminnon luokan piti toteuttaa java.net.URLStreamHandler ja laajentaaurlHandlers-laajennuspiste. Laajennuspistettä ei enää tueta, ja käsittelytoiminto on päivitettävä toteuttamaan org.osgi.service.url.URLStreamHandlerService-rajapinta. OSGi-kehys toimittaa abstraktin kantaluokan(org.osgi.service.url.AbstractURLStreamHandlerService), johon voidaan lisätä tätä varten vähäpätöisiä aliluokkia.

Sen sijaan, että lisäosat rekisteröisivät käsittelytoiminnon laajennuspisteen avulla, ne tekevät sen nyt rekisteröimällä käsittelytoimintonsa palveluksi. Esimerkki:

    Hashtable properties = new Hashtable(1);
    properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL});
    String serviceClass = URLStreamHandlerService.class.getName();
    context.registerService(serviceClass, new MyHandler(), properties);

24. Luokan latausjärjestys

Mitä muutos koskee: Lisäosia, jotka toimittavat paketteja, jotka myös toiset lisäosat toimittavat. Tämä muutos vaikuttaa erittäin harvoihin lisäosiin, ja jotkin niistä, joihin se vaikuttaa, itse asiassa hyötyvät siitä (lisää jäljempänä).

Kuvaus: Eclipse 2.x -versiossa luokanlataustoiminnot hakevat luokkia seuraavassa järjestyksessä: (1) pääluokan lataustoiminto (käytännössä tämä on Java-aloitusluokan lataustoiminto), sitten (2) sen oman luokkapolun sisältö ja lopuksi (3) kaikki sen ennakkoehdot esitellyssä järjestyksessä. OSGi:n malli on tätä mallia optimimpi. Sen lähestymistavassa luokanlataustoiminto hakee ensin (1) pääluokan lataustoiminnon (jälleen tosiasiassa Java-aloitusluokan lataustoiminto), sitten joko (2a) yksittäisen ennakkoehdon, jonka tiedetään toimittavan kyseltävässä paketissa olevia luokkia tai (2b) sen oman luokkapolun merkinnöistä haluttua luokkaa.

Luokanlataustoiminto määrittää, tuleeko sen kysellä itseltään vai ennakkoehdoiltaan tuotujen ja pakollisten pakettiensa mukaan. Nämä tiedot tulevat lisäosan sisällöstä perinteisten lisäosien osalta ja suoraan määritettyinä, jos kyse on lisäosista, joilla on eksplisiittinen OSGi-palvelupaketin manifest-tiedosto. Molemmissa tapauksissa tiedossa on etukäteen, mitkä luokanlataustoiminnot toimittavat luokat millekin paketeille. Tämä parantaa suoritustehoa ja ratkaisee harmillisen ongelman, että useat ennakkoehdot toimittavat samat luokat.

Esimerkkinä voisivat olla Xerces ja Xalan, jotka molemmat sisältävät useita luokkia org.xml-paketeista. Ensimmäistä menettelyä käytettäessä Xerces-lisäosa näkisi näiden luokkien kopionsa, kun taas Xalan-lisäosa näkisi niiden kopion. Koska näiden lisäosien on oltava yhteydessä toistensa kanssa, seurauksena on ClassCastExceptions-poikkeuksia. Toista menettelytapaa käytettäessä vain toinen kahdesta lisäosasta toimittaa päällekkäiset luokat, ja molemmat lisäosat näkevät samat kopiot.

Edellytetty toimi: Edellytetty toimi vaihtelee käyttötapauksen mukaan. Sovelluskehittäjien, joihin muutoksella on vaikutusta, on tarkastettava luokkapolkunsa ja ratkaistava mahdolliset ristiriidat.

25. Luokanlataustoiminnon suojausverkkoaluetta ei ole asetettu

Mitä muutos koskee: Lisäosia, jotka odottavat luokanlataustoimintonsa suojausverkkoalueen olevan aina asetettu.

Kuvaus: Eclipse 2.1 -versiossa lisäosan luokanlataustoiminnot olivat java.security.SecureClassloaders-toimintoja ja näin ollen niillä oli aina asetettu suojausverkkoalue. Eclipse 3.0 -versiossa luokanlataustoiminnot eivät laajenna SecureClassloader-luokkaa, ja ne asettavat suojausverkkoalueen vain, jos Java-suojaukset on otettu käyttöön (ei normaalisti).

Edellytetty toimi: Edellytetty toimi vaihtelee sen skenaarion mukaan, milloin lisäosa käyttää suojausverkkoaluettaan.

26. PluginModel-objektin lajinvaihto

Mitä muutos koskee: Lisäosia, jotka vaihtavan lajin org.eclipse.core.runtime.IPlugin* objektien lajiksi org.eclipse.core.runtime.model.Plugin*Model. Vaikka näiden rajapintojen ja malliluokkien välistä suhdetta ei ole määritetty Eclipse 2.1 -sovellusohjelmaliittymässä, tämä muutos on tehty siksi, että on löydetty lisäosien ilmentymiä, jotka perustuvat tähän 2.1-toteutuksen suhteeseen.

Kuvaus: Eclipse-sovellusohjelmaliittymässä on joukko rajapintoja (esimerkiksi IPluginDescriptor) ja niin sanottuja "malliluokkia" (esimerkiksi PluginDescriptorModel), jotka liittyvät lisäosiin ja lisäosarekisteriin. Eclipse 2.1 -toteutuksessa malliluokat toteuttavat vastaavat rajapinnat. Uudessa OSGi-pohjaisessa ohjelmassa lisäosarekisteriä on muotoiltu merkittävissä määrin uudelleen niin, että se mahdollistaa luokkien latauksen ja lisäosien ennakkoehtojen erotuksen laajennuksista ja laajennuspisteistä. Eclipse 3.0 -ohjelma ei itsessään pysty pitämään yllä 2.1-version toteutussuhdetta.

Edellytetty toimi: Tähän sovellusohjelmaliittymän ulkopuoliseen suhteeseen perustuvien lisäosien koodi on muotoiltava uudelleen käyttötapauksen mukaan. Lisätietoja on tämän asiakirjan suositeltuja muutoksia koskevassa osiossa ja aiheeseen liittyvien luokkien ja metodien Javadocissa.

27. ILibrary-toteutus puutteellinen

Mitä muutos koskee: Lisäosia, jotka käyttävät org.eclipse.core.runtime.ILibrary-rajapintaa.

Kuvaus: Uusi ohjelmatiedosto pitää luokkapolun merkintöjä yllä erilaisessa, Eclipsen kanssa yhteensopimattomassa muodossa. Tämän seurauksena yhteensopivuuskerros ei pysty mallintamaan perustana olevia OSGi-rakenteita ILibrary-objekteina. Ohjelmatiedoston yhteensopivuuden tuki luo ILibrary-objektit, mutta sen on käytettävä oletusarvoja kaiken muun kuin kirjaston polun osalta.

Edellytetty toimi: ILibrary-rajapinnan käyttäjien tulisi harkita haluttujen ylätunnisteen arvojen (esimerkiksi Bundle-Classpath) käyttöä vastaavasta palvelupaketista (katso Bundle.getHeaders()) ja ManifestElement-apuluokan käyttöä merkintöjen tulkintaan. Lisätietoja on luokan Javadocissa.

28 Virheelliset URL-osoitteiden muotoa koskevat oletukset

Mitä muutos koskee: Lisäosia, jotka tekevät oletuksia asennusrakenteensa, sijaintinsa ja paikallisen tiedostojärjestelmän rakenteen suhteen.

Kuvaus: Jotkin metodit, esimerkiksi IPluginDescriptor.getInstallURL(), palauttavat tietyn muotoisia URL-osoitteita. Vaikka niiden muotoa ei olekaan määritetty, monet lisäosat tekevät oletuksia nykyisen toteutuksen mukaan. Ne voivat esimerkiksi odottaa saavansa file:-alkuisen URL-osoitteen, käyttävänsä URL.getFile() ja käyttävänsä tulokseen java.io.File-käsittelyä. Tähän asti tämä on ollut käyttökelpoinen, mutta melko vioille altis menetelmä. Jos lisäosa on asennettu esimerkiksi Web-palvelimeen, on mahdollista, että palautuva URL-osoite on muotoa http:. Uusi Eclipse 3.0 -ohjelma on vielä joustavampi, ja se avaa mahdollisuuksia toteutuksen määrityksiin (esimerkiksi kokonaisten lisäosien pitäminen JAR-tiedostoissa sen sijaan, että ne olisivat laajennettuina hakemistoissa). Toisin sanoen vaikka uusi OSGi-pohjainen ajoympäristö ei varsinaisesti hajota 2.1-sovellusohjelmaliittymää, se paljastaa useita tapauksia, joissa nykyisissä lisäosissa tehdyt oletukset ovat virheellisiä.

Edellytetty toimi: Lisäosien kirjoittajien tulee varmistaa, että tieto, jota pitää käyttää, on saatavissa getResource()-metodilla (ja on luokkapolussa) tai käyttää vastaavaa sovellusohjelmaliittymää lisäosan sisällön käyttöön (esimerkiksi Bundle.getEntry(String)).

29. BootLoader-metodeja siirretty/poistettu

Mitä muutos koskee: Lisäosien ulkopuolista koodia, joka kutsuu tiettyjä metodeja luokasta org.eclipse.core.boot.BootLoader.

Kuvaus: Staattiset metodit BootLoader.startup(), shutdown() ja run() on siirretty luokkaan org.eclipse.core.runtime.adaptor.EclipseStarter, joka on osa OSGi-kehystä. Tämä sovellusohjelmaliittymä on rajapinta startup.jar-kirjaston main()-metodin ja OSGi-kehyksen/Eclipse-ohjelman välillä. Ohjelman rakenteen uudelleenjärjestely ei sallinut näiden metodien jäämistä BootLoader-luokkaan. Vanha BootLoader-luokka sijaitsee nyt ohjelman yhteensopivuuskerroksessa vanhentuneena, ja siirretyt metodit on typistetty olemaan tekemättä mitään.

Vanhalle BootLoader.getRunnable()-metodille ei ole korviketta, sillä ohjelma ei enää tue yksittäisten sovellusten hankintaa. Sen sijaan käyttäjien tulee ilmaista kiinnostava sovellus ympäristön käynnistyksen yhteydessä.

Edellytetty toimi: Yleisesti ottaen hyvin harvat ihmiset käyttävät tätä sovellusohjelmaliittymää (sitä ei voi käyttää Eclipse-lisäosasta). Niissä harvoissa tapauksissa, joissa sitä käytetään, koodi on sovitettava käyttämään EclipseStarter-luokan vastaavia metodeja.

30. Lisäosan vienti ei sisällä lisäosan JAR-tiedostoja automaattisesti

Mitä muutos koskee: Kaikkia lisäosia.

Kuvaus: Eclipse 2.1 -versiossa lisäosan build.properties-tiedoston rivin bin.includes ei tarvinnut sisältää JAR-tiedostojen luetteloa plugin.xml-tiedostossa olevasta kirjastonsa esittelystä; nämä JAR-tiedostot lisättiin automaattisesti. Eclipse 3.0 -versiossa build.properties-tiedoston bin.includes-osan tiedostoluettelo on poissulkeva, ja sen pitää sisältää kaikki lajit, jotka lisäosakehittäjät aikovat sisällyttää lisäosaansa koonnin tai viennin yhteydessä.

Edellytetty toimi: Varmista, että build.properties-tiedoston rivi bin.includes sisältää kaikki plugin.xml-tiedostossa luetellut JAR-tiedostot.

31. Ajonaikaisen sovellusohjelmaliittymän uudelleenvienti

Mitä muutos koskee: Lisäosia, jotka paljastavat sovellusohjelmaliittymän, joka sisältää elementtejä muuttuneesta ajonaikaisesta sovellusohjelmaliittymästä.

Kuvaus: Monet lisäosat paljastavat sovellusohjelmaliittymän, jossa on elementtejä ajonaikaisesta sovellusohjelmaliittymästä. Tässä kuvattujen Eclipse 3.0 -version muutosten myötä asiakaslisäosien on tarkistettava sovellusohjelmaliittymässään oleva ajonaikaisen sovellusohjelmaliittymän käyttö.

Edellytetty toimi: Tämä skenaario on melko harvinainen, sillä Eclipsen ajonaikainen sovellusohjelmaliittymä on muuttunut erittäin vähän. Skenaarion mukaan asiakkaiden on mahdollisesti muutettava sovellusohjelmaliittymäänsä tai jatkaa luottamista yhteensopivuuskerrokseen.

32. Lisäosan jäsennysmetodit ympäristössä

Mitä muutos koskee: Lisäosia, jotka käyttävät metodia org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).

Kuvaus: Metodi org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) on siirretty. Factory-argumenttiin liittyvä sovellusohjelmaliittymä on siirretty org.eclipse.core.runtime-lisäosasta org.eclipse.core.runtime.compatibility-lisäosaan (joka on riippuvainen ajonaikaisesta lisäosasta). Tämän seurauksena myös jäsennysmetodi on siirretty.

Edellytetty toimi: Tämän metodin käyttäjien tulee käyttää samaa metodia luokassa org.eclipse.core.runtime.model.PluginRegistryModel.

33. Fragmenttien toimittamat lisäosakirjastot

Mitä muutos koskee: Lisäosia, jotka määrittävät koodia luokkapolussaan mutta eivät toimita kyseistä koodia (eli JAR-kirjaston toimittaa fragmentti, esimerkiksi org.eclipse.swt-lisäosa).

Kuvaus: Uuden ajoympäristön on muunnettava plug.xml-tiedostot manifest.mf-tiedostoiksi kulissien takana. Tämä tapahtuu lisäosan toimittamien ja luettelemien jar-kirjastojen suoralla mekaanisella muunnolla ja analysoinnilla. Jos lisäosa määrittää jar-kirjaston luokkapolussaan mutta ei toimita sitä, analysoitavaa koodia ei ole eikä lisäosan muunnin voi muodostaa oikeaa manifest.mf-tiedostoa.

Edellytetty toimi: Tällaisten lisäosien toimittajien on joko toimitettava oikea jar-kirjasto itse lisäosassa tai luotava itse/pidettävä yllä META-INF/MANIFEST.MF-tiedosto lisäosalle. Tavallisesti tämän voi tehdä hakemalla alku-manifest-tiedoston PDE:n avulla ja lisäämällä sitten sopivan toimittaja-paketti-ylätunnisteen.

34. Muutokset koonnin komentosarjoihin

Mitä muutos koskee: Komentosarjoja (esimerkiksi Ant build.xml -tiedostot), jotka määrittävät luokkapolkuja, joissa on ajonaikaiseen ympäristöön liittyviä jar-kirjastoja ja luokkahakemistoja.

Kuvaus: Uusi ajonaikainen ympäristö sisältää joukon uusia lisäosia ja jar-kirjastoja. Niiden lisäyksen teki pakolliseksi ajonaikaisen ympäristön koodin parannus määritettävissä oleviin osiin. Useimmissa ajonaikaisissa tilanteissa nämä muutokset ovat läpinäkyviä. Jos sinulla on kuitenkin mukautettuja build.xml- (tai vastaavia) komentosarjoja, jotka kääntävät nykyään koodia org.eclipse.core.runtime-lisäosasta, ne on päivitettävä, ennen kuin ne toimivat oikein. Tyypillinen komentosarja sisältää luokkapolun merkinnän <javac>-tehtävässä, joka viittaa org.eclipse.core.runtime-lisäosaan seuraavasti:

    ../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar

Ajonaikainen lisäosa sisältää edelleen suuren osan alkuperäisestä ajonaikaisesta koodista. Ajonaikaisen ympäristön monet osat, jotka ovat ainoastaan yhteensopivuutta varten, sisältyvät yhteensopivuuslisäosaan (org.eclipse.core.runtime.compatibility). Suurin osa uudesta ajonaikaisesta koodista sisältyy lisäosien kokoelmaan (org.eclipse.osgi.*).

Edellytetty toimi: Sovelluskehittäjien tulee lisätä seuraavat merkinnät tarpeen mukaan käännösvirheiden poistamista varten. Vaikka seuraavassa on lueteltu täydellinen jar-kirjastojen joukko, tavallisesti käyttö edellyttää vain osaa niistä luokkapolussa käännöksen yhteydessä. Kuten tavallista, /bin-hakemistojen sisällytys on harkinnanvaraista. Merkinnät on lueteltu tässä loogisesti toimittavan lisäosan mukaan ryhmiteltynä:

Lisäksi erikoistapauksissa saatetaan tarvita seuraavia jar-kirjastoja:

Tällaisten komentosarjojen päivityksen yhteydessä tulisi myös siivota (eli poistaa) viittaukset org.eclipse.core.boot-lisäosaan. Tämä lisäosa on jäänyt pois käytöstä, eikä se enää sisällä koodia. Merkinnät voi jättää luokkapolkuun, mutta niillä ei ole tarkoitusta, joten ne tulisi poistaa. Poista

    ../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar

35. Muutokset PDE-koonnin Ant-tehtävään

Mitä muutos koskee: Komentosarjoja (esimerkiksi Ant build.xml -tiedosto), jotka käyttävät eclipse.buildScript-tehtävää.

Kuvaus: PDE-koonti on tuonut eclipse.buildScript-tehtävään uuden ominaisuuden, jolla ohjataan lisäosan koonnin komentosarjojen muodostusta. Uuden OSGi-pohjaisen ajonaikaisen ympäristön tulo on tehnyt tämän tarpeelliseksi.

Edellytetty toimi: Jos haluat käyttää Eclipse 3.0 -versiota 2.1-pohjaisen tuotteen koontiin, lisää ominaisuus "buildingOSGi" eclipse.buildScript-tehtävään ja määritä sen arvoksi false. Esimerkki:

<eclipse.buildScript ... buildingOSGi="false"/>

36. Muutokset eclipse.build-Ant-tehtävään

Mitä muutos koskee: Komentosarjoja (esimerkiksi Ant build.xml -tiedosto), jotka käyttävät eclipse.buildScript-tehtävää.

Kuvaus: PDE-koonti on tuonut eclipse.buildScript-tehtävään uuden ominaisuuden, jolla ohjataan lisäosan koonnin komentosarjojen muodostusta. Uuden OSGi-pohjaisen ajonaikaisen ympäristön tulo on tehnyt tämän tarpeelliseksi.

Edellytetty toimi: Jos haluat käyttää Eclipse 3.0 -versiota 2.1-pohjaisen tuotteen koontiin, lisää ominaisuus "buildingOSGi" eclipse.buildScript-tehtävään ja määritä sen arvoksi false. Esimerkiksi:

<eclipse.buildScript ... buildingOSGi="false"/>

37. Muutokset eclipse.fetch-Ant-tehtävään

Mitä muutos koskee: Komentosarjoja (esimerkiksi Ant build.xml -tiedosto), jotka käyttävät eclipse.buildScript-tehtävää.

Kuvaus: PDE-koonti muutti eclipse.fetch-tehtävän kuvausta helpottamaan eclipsen koontia automaattisena koontina. Elementtien tyyli tukee nyt vain yhtä merkintää kerrallaan, ja scriptName ohitetaan aina.

Edellytetty toimi: Jos eclipse.fetch-kutsun "elements"-tunnisteessa oli merkintöjen luettelo, jaa ne useisiin eri eclipse.fetch-kutsuihin. Jos asetat scriptName-argumentin, huomaa, että nyt muodostetun fetch-komentosarjan nimi on aina "fetch_{elementId}". Esimerkiksi:

<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>

muutetaan muotoon

<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../>
<eclipse.fetch elements="feature@org.eclipse.platform" .../>

38. install.ini-tiedoston korvaus

Tiedosto install.ini ei enää sisälly tuotteeseen. Sen paikalla on uusi config.ini-tiedosto kokoonpanon alihakemistossa. Tuotteiden, jotka käyttivät install.ini-tiedostoa määrittämään ensisijaisen tuoteominaisuuden (esimerkiksi tuottamaan tuotteistustiedot), on tehtävä sen sijaan muutokset tiedostoon config.ini. Uuden tiedoston nimen lisäksi myös avainten nimet ovat muuttuneet.

2.1-version avaimen feature.default.id arvo tulisi asettaa uuden eclipse.product-avaimen arvoksi. eclipse.application-arvoksi tulisi asettaa "org.eclipse.ui.ide.workbench".

Lopuksi 2.1-versiossa aloituskuva oli aina splash.bmp tuotteistuslisäosan hakemistosta. 3.0-versiossa aloituskuvan sijainnin toimittaa eksplisiittisesti config.ini-tiedoston avain osgi.splashPath.