Ändringar som krävs när du inför mekanismer och API:er för 3.2

I det här avsnittet beskrivs de ändringar som krävs när du ändrar ditt insticksprogram från version 3.1 till mekanismerna och API:erna i version 3.2.

  1. Startkonfigurationer
  2. Startlägen
  3. International Components for Unicode for Java (ICU4J)
  4. Delning under körning

Startkonfigurationer

Resursavbildning för startkonfiguration

Eclipse 3.2 har en ny infrastruktur för association av startkonfigurationer med resurser. Med den här avbildningen kan resursbaserad filtrering av startkonfigurationer utföras och startkonfigurationer tas bort när ett associerat projekt tas borts. Startdialogrutan har utökats med en uppsättning filter för att dölja konfigurationer som är associerade med stängda eller borttagna projekt. Dessutom har startdialogrutan funktioner för filtrering baserat på valda arbetsuppsättningar i det aktiva arbetsmiljöfönstret, som också kan öppnas från startdialogrutan.

Det är klientens ansvar att hantera resursavbildning för startkonfigurationer. Ett API har lagts till i ILaunchConfigurationWorkingCopy där resurser som är associerade med en konfiguration anges, och ett API har lagts till i ILaunchConfiguration där resurser som är associerade med en konfiguration kan hämtas. Till exempel bör startflikar, startgenvägar och omfaktoriserande deltagare beaktas vid migrering. Kod som skapar eller ändrar startkonfigurationer ska även uppdatera resursavbildningar.

Migreringsfunktioner för startkonfigurationer

Eclipse 3.2 har en ny infrastruktur för migrering av startkonfigurationer så att de blir kompatibla med nya verktyg. Till exempel har funktioner lagts till i Eclipse 3.2 för resursbaserad filtrering av startkonfigurationer. Startkonfigurationer måste uppgraderas så att den här nya funktionen kan användas av resursavbildningar. Användare kan manuellt migrera startkonfigurationer i arbetsytan från inställningssidan Kör/felsök > Starta > Startkonfigurationer genom att trycka på knappen Migrera.

Ett nytt valfritt delegeringsattribut för migrering har lagts till i utökningspunkten launchConfigurationTypes. Det anger en klass som implementerar det nya gränssnittet ILaunchConfigurationMigrationDelegate. En migreringsdelegat ansvarar för att identifiera migreringskandidater och migrera dem.

Startlägen

Ett nytt valfritt attribut har lagts till i utökningspunkten launchModes för att möjliggöra externalisering av åtgärdsetiketter för överföringsstartmenyer. Klienter som lägger till objekt i startlägen bör ange en lämplig etikett att använda för överföringsstartmenyer, till exempel "Kör som". Det nya attributet har namnet launchAsLabel. Etiketter finns tillgängliga i plattformen för körning, felsökning och profilering av startlägen. För bakåtkompatibilitet, när det nya attributet inte angetts för ett startläge, genereras överföringsmenyetiketterna som tidigare via MessageFormat med "{0} som". Se det relaterade felet 105235.

International Components for Unicode for Java (ICU4J)

ICU4J är en uppsättning Java-bibliotek som tillhandahåller mer omfattande funktioner för Unicode och programvaruglobalisering och -internationalisering. I syfte att tillhandahålla de här funktionerna till Eclipse-användare lades ICU4J till i plattformsbygget för Eclipse 3.2. Det visas i bygget som ett insticksprogram med namnet com.ibm.icu. I Eclipse-plattformen används ICU-API:er i Eclipse 3.2.

Migrering

Migrering av tillämpningskod kan göras stegvis vilket innebär att du inte behöver göra en fullständig implementering av alla ICU4J-funktioner för att dra nytta av fördelarna med ICU4J. Läs ICU4J-sidan på wiki-webbplatsen för Eclipse om du vill ha mer information om hur du migrerar kod för att använda ICU4J.

Ersättningsinsticksprogram för ICU4J

Tack vare tillägget av ICU4J-insticksprogrammet utökas storleken med 3 MB. Det kan hända att det inte går att använda vissa tillämpningar med ICU4J om tillämpningsstorleken åsidosätter användningen av ICU4J-funktionen. Om så är fallet kan du hämta ett ersättningsinsticksprogram (com.ibm.icu.base) från byggsidan för Eclipse-plattformen. Hämta insticksprogrammet, ta bort insticksprogrammet com.ibm.icu och dess källmotsvarighet från katalogen /plugins och placera ersättningsinsticksprogrammet där. Det här är nödvändigt eftersom ICU-API:erna implementerades för version 3.2 av Eclipse-plattformen. Om ICU-insticksprogrammet bara togs bort skulle det resultera i kompileringsfel i plattformskoden. Ersättningsinsticksprogrammet är cirka 100 KB stort och anropar helt enkelt standard-JDK-implementeringen av de vanligast klasserna och API:erna i ICU4J. Även här kan du läsa ICU4J-sidan på wiki-webbplatsen för Eclipse om du vill ha mer information om ersättningsinsticksprogram för ICU.

Effekt på JFace - ViewerSorter och StructuredViewer

I syfte att göra det möjligt att använda ICU4J i JFace krävdes vissa kreativa API-tillägg för att förhindra referens till ICU-klasser i API:t. Det resulterade i följande tillägg:

  1. en ny klass med namnet org.eclipse.jface.viewers.ViewerComparator som org.eclipse.jface.viewers.ViewerSorter nu är underklass till
  2. två nya metoder till org.eclipse.jface.viewers.StructuredViewer för att org.eclipse.jface.viewers.ViewerComparator skulle kunna läggas till

Förklaring

Klassen ViewerSorter har den publika metoden getCollator() som returnerar en java.text.Collator. Eftersom den här metoden är API gick det inte att bara ändra den så att en ICU-samlare användes. Dessutom kan ICU-klasser inte vara en del av API:t (signaturer) eftersom ett direkt insticksprogramsberoende av ICU skulle förhindra att JFace används fristående (med SWT). Som en anpassning till de här begränsningarna infördes klassen ViewerComparator som använder en java.util.Comparator, i stället för en ICU-sorterare. Det gjordes eftersom sorteringsklassen för ICU implementerar java.util.Comparator, så en StructuredViewer kan nu använda ICU-sorteraren i stället för java.text.Collator men JFace behöver inte lägga till ett beroende av ICU4J-insticksprogrammet. De två metoder som lades till i StructuredViewer kan användas tillsammans med ICU-sorteraren till att sortera innehållet i visningsprogrammet via en ViewerComparator i stället för en ViewerSorter. Vi rekommenderar att StructuredViewer nu använder de här metoderna till att hämta/ange visningsprogrammets sorteringsfunktion (jämförelsefunktion) i stället för getSorter()- eller setSorter(ViewerSorter)-metoden.

Delning under körning

Nya körnings-API:er

I samlingspaketet org.eclipse.equinox.common ingår flera nya API-klasser (till exempel Assert och ListenerList) som har samma namn. Om det finns en klass med samma namn i din kod och import *-satser används till att importera både den lokala klassen och klasser från körningen kan det hända att du får följande felmeddelande:

   Typ ABC är tvetydig
  

Du bör kunna lösa problemet genom att sortera importerna och välja lämplig importkälla.

Explicita klassökvägar i anpassade byggskript

Ett resultat av att kod flyttades till nya körningsinsticksprogram är att det kan hända att ett eller flera av följande insticksprogram måste läggas till i anpassade skript som explicit refererar till org.eclispe.core.runtime: