Inkompatibilitás az Eclipse 3.1 és 3.2 verzió között

Az Eclipse inkompatibilis módon változott a 3.1 és 3.2 verzió között, és ez hatással van a bedolgozókra. Az alábbi bejegyzések leírják a módosított területeket, és útmutatást biztosítanak az 3.1 verziószámú bedolgozók átállításához 3.2 verzióra. Ezeket csak akkor kell megtekintenie, ha problémája van a 3.1 verziószámú bedolgozó futtatásával a 3.2 verzión.

  1. Az erőforrások már nem szükségesek a helyi fájlrendszeren
  2. A MultiPageEditorSite API változásai
  3. Tartalommódosítások a config.ini fájlban
  4. Tartalommódosítások a jnlp által telepített alkalmazásokban
  5. Bundle.start() explicit hívásai aktiválódásra kényszerítik a köteget a következő indításkor
  6. A bedolgozó verziószámában az aláhúzás már nem kerül helyettesítésre kötőjellel

1. Az erőforrások már nem szükségesek a helyi fájlrendszeren

Befolyásolt elem:Az IWorkspace API ügyfelei, amely feltételezik, a helyi fájlrendszer erőforrásokat tárol.

Leírás: Az Eclipse 3.2 változat előtt minden meglévő IResource rendelkezett egy megfelelő fájllal vagy könyvtárral a fájlrendszerben, amelyet a java.io.File el tud érni. Az Eclipse 3.2 változatban olyan erőforrások létrehozása támogatott, amelyek tartalmát egy tetszőleges mentési fájlrendszer tárolja. Ezen támogatást használó erőforrások már nem ábrázolhatók közvetlenül java.io.File fájlként.

Szükséges tevékenység: A régi IResource.getLocation() metódus az erőforrás helyi fájlrendszer elérési útját adja meg. Ez a metódus nullértéket ad vissza nem a helyi fájlrendszeren tárolt erőforrások esetén. A getLocation() legtöbb hívója ezt tette a java.io.File példány lekérése érdekében, amely nem a helyi fájlrendszeren tárolt erőforrások esetén nem használható.

Az új org.eclipse.core.filesystem bedolgozó egy általános fájlrendszer alkalmazás programozási felületet biztosít, amely a java.io.File helyett használható. Az org.eclipse.core.filesystem.IFileStore egy példánya nagyjából ugyanazokat a metódusokat biztosítja, mint amelyeket a java.io.File. A következő kódrészlet az IFileStore egy példányát kérdezi le egy adott erőforráshoz:

   IResource resource = ...;//néhány erőforrás
   IFileStore store = EFS.getStore(resource.getLocationURI());

A következő tábla egyenértékű metódusokat biztosít az IFileStore-on az általában java.io.File segítségével végzett műveletekhez:

java.io.FileIFileStore
törlés törlés
getNamegetName
getParentgetParent
listchildNames
mkdirmkdir(EFS.SHALLOW, null)
mkdirsmkdir(EFS.NONE, null)
renameToáthelyezés
new FileInputStream(file)openInputStream
new FileOutputStream(file)openOutputStream

Az IFileStore alkalmazás programozási felületen a fájlokkal kapcsolatos információk nagy része egy IFileInfo nevű struktúrában kerül tárolásra, amely az IFileStore.fetchInfo() meghívásával kérdezhető le. Ez a kialakítás a kód jobb optimalizálást teszi lehetővé a java.io.File használatával, mivel a fájllal kapcsolatos számos jellemző gyakran egy fájlrendszerhívással lekérdezhető. Ne feledje el, hogy az IFileInfo információi elavulttá válnak, ha az alapul szolgáló fájl változik, így a példányokat csak addig kell tárolni, amíg szükség van rájuk. Az alábbiakban látható néhány java.io.File metódus, amelyeknek létezik IFileInfo megfelelője:

java.io.FileIFileInfo
canWriteisReadOnly
existsexists
getNamegetName
isDirectoryisDirectory
isFile!isDirectory()
isHiddenisHidden
lastModifiedgetLastModified
lengthgetLength
setLastModifiedsetLastModified
setReadOnlysetAttribute(EFS.ATTRIBUTE_READ_ONLY, true)

Konkrét példa: a kód, amely korábban a java.io.File.exists() metódust hívta meg, most az IFileStore.fetchInfo().exists() metódust hívja. Ha az IFileInfo módosítva lett, akkor az eredményt el kell tárolni az IFileStore.putInfo metódusban. Ez a részlet például a fájl csak olvasható attribútumát ábrázolja

   IFileStore store = ...;//egy fájltároló
   IFileInfo info = store.fetchInfo();
   boolean readOnly = info.getAttribute(EFS.ATTRIBUTE_READ_ONLY);
   info.setAttribute(EFS.ATTRIBUTE_READ_ONLY, !readOnly);
   store.putInfo(info, EFS.SET_ATTRIBUTES, null);

IProjectDescription.getLocation()

A getLocation() metódushoz hasonlóan, a projektleírás helye már nem a helyi fájlrendszeren található. Az IProjectDescription.getLocationURI() metódus segítségével lekérdezhető az erőforrás helye egy tetszőleges fájlrendszeren.

Helyi ideiglenes tárolás

Néhány ügyfélnek feltétlenül rendelkeznie kell a fájl helyi ábrázolásával. Például elindíthatnak egy natív eszközt a fájlon, vagy használhatnak nem Eclipse-re felkészített könyvtárakat, amelyeket csak a fájlrendszer-erőforrásokat tudják kezelni (mint például a java.util.zip.ZipFile). Ilyen esetekben megkérhet egy IFileStore-t, hogy visszaadja a tartalom ideiglenesen tárolt helyi példányát:

   IFileStore store = ...;//egy fájltároló
   //akkor látható, ha közvetlenül ábrázolható helyi fájlként
   java.io.File local = store.toLocalFile(EFS.NONE, null);
   //ha nem, akkor kérje a fájlról egy ideiglenesen tárolt helyi példányt
   if (local == null)
      local = store.toLocalFile(EFS.CACHE, null);

Ne feledje el, hogy a fájl ideiglenesen tárolt példányának lekérése után nem marad szinkronban az aktuális fájlrendszerrel, amelyről származott. Az ideiglenesen tárolt példány módosításakor az alapul szolgáló fájl nem változik.

Helyreállítható hiba

Az ügyfelek, amelyek nem tudják kezelni a helyi fájlrendszeren kívül lévő erőforrásokat, elképzelhető, hogy továbbra is adaptálni kívánják a kódjukat a könnyebben helyreállítható hiba érdekében. Az ügyfelek ellenőrizhetik, hogy az erőforrás a helyi fájlrendszeren található-e, és figyelmen kívül hagyhatják az erőforrást vagy riasztáshatják a felhasználót, ha olyan erőforrást találnak, amelyet nem tudnak kezelni. Annak megállapításához, hogy az erőforrás a helyi fájlrendszeren van-e, ki meg kell ismerni a fájlrendszer sémát. Ez az erőforrásról kérdezhető le a a következő módon:

   IResource resource = ...;//néhány erőforrás
   URI uri = resource.getLocationURI();
   if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) {
      //a fájl a helyi fájlrendszeren található
   } else {
      //a fájl nem a helyi fájlrendszeren található
   }

Ha van kéznél egy IFileStore példány, akkor a séma a a következőképp kérdezhető le:

   IFileStore store = ...;//fájltároló
   store.getFileSystem().getScheme();

2. A MultiPageEditorSite API változásai

Befolyásolt elem: A MultiPageEditorSite.progressStart() vagy MultiPageEditorSite.progressEnd() metódust meghívó ügyfelek.

Leírás: Az Eclipse 3.0 fejlesztése során ezek a metódusok hozzáadásra kerültek a folyamattámogatási feladat részeként. A 3.0 változat előtt a folyamat kezelési módszere változott, és ez a metódus már nem szükséges. Programozóhiba miatt ezek a nyilvános metódusok megmaradtak a 3.0 kiadásban. Ez a két metódus semmilyen funkciót nem szolgáltatott az Eclipse kiadásban, így törlésre került.

Szükséges tevékenység: A MultiPageEditorSite.progressStart() vagy MultiPageEditorSite.progressEnd() metódust meghívó ügyfeleknek át kell térniük az IWorkbenchSiteProgressService használatára.

3. Tartalommódosítások a config.ini fájlban

Befolyásolt elem: Egyéni config.ini fájllal rendelkező ügyfelek, akik alkalmazásaikat a 3.2 alá helyezik át.

Leírás: A 3.2 előtt a config.ini fájlban az osgi.bundles tipikus értéke org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start volt. A futási környezet átdolgozása miatt, az értéket az alkalmazás sikeres indításához frissíteni szükséges.

Szükséges tevékenység: Módosítsa az osgi.bundles értékét, hogy az org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start értéket tartalmazza.

4. Tartalommódosítások a jnlp által telepített alkalmazásokban

Befolyásolt elem: RCP alkalmazásokat telepítő ügyfelek, amelyek értéket adtak az osgi.bundles tulajdonságnak.

Leírás: A 3.2 előtt a fő jnlp fájlban az osgi.bundles tipikus értéke org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start volt. A futási környezet átdolgozása miatt, az értéket frissíteni kell, különben előfordulhat, hogy NullPointerException történik és az alkalmazás nem indul el.

Szükséges tevékenység: Módosítsa az osgi.bundles értékét, hogy az org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start értéket tartalmazza.

5. Bundle.start() explicit hívásai aktiválódásra kényszerítik a köteget a következő indításkor

Befolyásolt elem: A Bundle.start() metódust meghívó ügyfelek.

Leírás: Az Eclipse termékben a kötegeket késleltetett indítású kötegként az Eclipse-LazyStart fejléc (vagy az elavult Eclipse-AutoStart fejléc) segítségével jelölhető meg. Az Eclipse 3.1 változatában az org.osgi.framework.Bundle.start() metódus a késleltetett indítású kötegeket nem jelölte állandó indításúként. Mivel a késleltetett indítású kötegeket a rendszer sosem jelölte meg állandó indításúként, ezek nem kerültek automatikusan indításra az Eclipse újraindításakor. A Bundle.start() javadoc a metódus hívásakor a következőnek kell történnie:

"Állandóan rögzíthető, hogy a köteg indításra került. A Keretrendszer újraindításakor a köteget automatikusan el kell indítani."

Az Eclipse 3.2 változatában a Bundle.start() metódus javításának köszönhetően a köteget megfelelően állandó indításúnak jelöli meg, még akkor is, ha a köteg késleltetett indítású köteg. A javítást az OSGi keretrendszer-specifikáció tette szükségessé. Ennek eredményeként a Bundle.start() hívói a köteget indításra kényszerítik az Eclipse újraindításakor. Általánosságban ez kerülendő gyakorlatnak minősül, hiszen szükségtelen kötegek kerülnek aktiválásra az Eclipse indításakor. Bizonyos esetekben ez nem várt eredményekkel járhat, például a 134412 számú hiba esetében.

Szükséges tevékenység: A Bundle.start() ügyfeleinek mérlegelniük kell, hogy kívánják-e a köteget minden újraindításkor állandóan aktiválni a köteget. Ha ez nem célja az ügyfélnek, akkor más módszert kell találniuk a köteg aktiválásához. A legtöbb esetben a Bundle.start() hívások elkerülhetők, ha egyszerűen a célkötegnek lehetővé teszik a késleltetett aktiválást, amikor onnan osztályok kerülnek betöltésre. Léteznek olyan ritka esetek, amelyek szükségessé tehetik egy késleltetett indítású köteg agresszív aktiválását, de ez nem jelenti a kötegek állandó megjelölését újraindításkor aktiválódóként. Ezekben a szituációkban a Bundle.loadClass() segítségével lehet a köteg aktiválni kívánt osztályát betölteni a Bundle.start() hívása helyett.

5. A bedolgozó verziószámában az aláhúzás már nem kerül helyettesítésre kötőjellel

Az Eclipse 3.0 rendszer nem támogatta az aláhúzás ('_') karakter használatát a verziószám-azonosító minősítő szegmensében, de ugyanakkor ezt a rendszer nem is tartatta be. Ha egy bedolgozó verziószám-azonosító minősítője aláhúzást tartalmazott, akkor a bedolgozó fájlrendszerre exportálásakor, illetve a bedolgozó frissítési helyről telepítésekor a karaktert a rendszer kötőjelre ('-') cserélte.
Az Eclipse 3.1 változatában a minősítőkben szereplő karakterekre vonatkozó szabályokat enyhítettük, tehát a minősítők tartalmazhatnak aláhúzást. Ennek köszönhetően az eredeti szabályt sértő bedolgozó exportálásakor és telepítésekor megmaradt a minősítő eredeti állapota. Ez az apró módosítás véletlenül kimaradt a 3.0 változatról a 3.1 változatra való áttéréshez tartozó útmutatóból. A történet folytatása (és ez igaz az Eclipse 3.2 változatára is), hogy a továbbiakban is fenntartjuk a kompatibilitást az Eclipse 3.1 változatával, és a verziószámukban aláhúzás karaktert tartalmazó bedolgozóknak tanácsos tekintetbe venni a fent említett módosításokat a régi bedolgozó-változatok kezelésekor (mind exportáláskor, mind pedig akkor, ha frissítési helyen találhatók). Vagyis például az olyan bedolgozó-szolgáltatóknak, amelyek egy telepítési helyen a bedolgozó régi változatát tartják, meg kell győződniük róla, hogy a fájlrendszerben tárolt név megegyezik a bedolgozó nevével.