Inkompatibilitäten zwischen Eclipse 3.0 und 3.1

Eclipse wurde in inkompatibler Weise von 3.0 zu 3.1 verändert, was sich auf die Plug-ins auswirkt. Die folgenden Abschnitte beschreiben die Bereiche, die geändert wurden, und enthalten Anweisungen für die Migration eines 3.0-Plug-ins auf 3.1. Beachten Sie, dass Sie nur hier nachsehen müssen, wenn Sie Probleme beim Ausführen Ihres 3.0-Plug-ins auf 3.1 haben.

  1. Plug-in Benutzervorgaben
  2. Änderungen an IPath-Einschränkungen
  3. Erweiterungs-Registrierungsdatenbank
  4. Optionen des Codeformatierungsprogramms
  5. API-Vertragsänderungen an AntCorePreferences
  6. API-Vertragsänderungen an der Richtlinienklasse in JFace
  7. API-Vertragsänderungen zur Ermöglichung einer Standardperspektive Null
  8. API-Vertragsänderungen an IViewLayout
  9. API-Vertragsänderungen an IViewLayout
  10. SelectionEnabler.SelectionClass jetzt paket-sichtbar
  11. ContributionItem.getParent() kann Null zurückgeben
  12. Änderungen an isPropertySet(boolean) in IPropertySource und IPropertySource2
  13. handlerSubmission-Element gelöscht aus dem Erweiterungspunkt org.eclipse.ui.commands
  14. Das statische nicht finale API-Feld GLOBAL_IGNORES_CHANGED in TeamUI wurde jetzt final
  15. ClassCastException unter Verwendung von FillLayout
  16. Erstellen eines Fensterobjekts mit einem entfernten übergeordneten Element

1. Plug-in Benutzervorgaben

Was ist betroffen: Plug-ins, die ihre standardmäßigen Plug-in-Benutzervorgabenwerte durch Überschreiben von Plugin#initializeDefaultPreferences initialisieren oder Benutzervorgabenänderungs-Listenerfunktionen verwenden.

Beschreibung: In Eclipse 3.1 wurde das Objekt org.eclipse.jface.preference.IPreferenceStore, das von org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore erlangt wurde, migriert, um zusätzlich zu dem neuen 3.0 Eclipse-Benutzervorgaben-Framework, das durch das Plug-in org.eclipse.core.runtime wurde, vorhanden zu sein..

Erforderliche Maßnahme: Daher sollten Clients, die die Benutzervorgaben-APIs verwenden, zwei mögliche Probleme prüfen:

  1. Der Typ der Objekte, die in Benutzervorgaben-Änderungsereignissen enthalten sind, ist nicht garantiert; sowohl der alte Wert als auch der neue Wert in Ereignissen kann Null, eine Zeichenfolge oder ein eingegebenes Objekt sein. Daher sollten Listener-Funktionen für Benutzervorgabenänderungen in der Lage sein, allen dieser drei möglichen Situationen fertig zu werden, um ein guter Client zu sein.
  2. Wenn Ihr Plug-in org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences verwendet, müssen Sie sicherstellen, dass das Plug-in org.eclipse.core.runtime.compatibility in der Liste der benötigten Plug-ins ihres Plug-ins enthalten ist, da diese Abhängigkeit aus dem Plug-in org.eclipse.ui.workbench entfernt worden ist.

Weitere Informationen finden Sie in der Dokumentation über Benutzervorgabenspeicher.

2. Änderungen an IPath-Einschränkungen

Was ist betroffen: Plug-ins, die IPath-Objekte erstellen, bearbeiten oder speichern.

Beschreibung: In Eclipse 3.0 hatte IPath eine Zahl von Einschränkungen in Bezug auf die Segmente von Pfaden, die restriktiver waren als die Einschränkungen des zu Grunde liegenden Betriebssystems. Hierzu gehörten:

Diese Einschränkungen sind in Eclipse 3.1 aufgehoben worden, wenn sich die Position der Plattformdaten (Arbeitsbereich) in einem Dateisystem befindet, das diese Einschränkungen nicht hat.

Erforderliche Maßnahme: Um die korrekte Behandlung des erweiterten Pfadbereichs zu ermöglichen, sollten alle Verwendungen von Path und IPath innerhalb von Plug-ins überprüft und wie folgt aktualisiert werden. Die meisten unveränderten Plug-ins werden sich bei allen Pfaden, die in 3.0 als gültig angesehen werden, weiterhin genau so verhalten wie in 3.0. Wenn jedoch die hier beschriebenen Änderungen nicht vorgenommen werden, werden sie in Fällen, die Pfade enthalten, die in 3.1 als zulässig angesehen werden, in 3.0. jedoch unzulässig waren, fehlschlagen.

Plug-ins, die Zeichenfolgedarstellungen von Pfaden in einem Format speichern, das in verschiedenen Plattformen lesbar sein muss, sollten auf die neue Factory-Methode Path.fromPortableString migrieren. Diese Methode erstellt ein IPath-Exemplar von einem plattformunabhängigen Format. Diese Zeichenfolgedarstellung von Pfaden kann mit Hilfe der Methode IPath.toPortableString erstellt werden. Beispiele betroffener Metadatendateien enthalten Dateien, die innerhalb von Eclipse-Arbeitsbereichsprojekten (.project, .classpath, etc.) gespeichert werden und alle Pfade, die im Benutzervorgabespeicher (org.eclipse.core.runtime.preferences.IPreferencesService) gespeichert werden.

Anmerkung: fromPortableString wird alle Pfad-Zeichenfolgen, die mit Hilfe der Eclipse 3.0-Methode IPath.toString, jedoch nicht mit der Eclipse 3.1-Methode toString erstellt wurden, korrekt lesen. Daher ist in den meisten Fällen keine Änderung an den vorhandenen Metadatendateiformaten erforderlich, außer dass das Schreiben von Pfaden mit toPortableString und das Lesen von Pfaden mit fromPortableString begonnen werden muss.

Plug-ins, die Pfade von fest codierten Zeichenfolgeliteralen erstellt haben, die angenommen haben, dass ':' und '\' auf allen Plattformen eine besondere Bedeutung hatten, müssen migriert werden. Die einfachste Lösung ist, Zeichenfolgepfadliterale auf die Untermenge zu beschränken, die von allen Plattformen unterstützt wird (d.h. Vermeidung der Zeichen ':' und '\'). Pfadliterale können die gesamte Menge gültiger Unix-Pfade unterstützen, indem sie das portierbare Pfadzeichenfolgenformat, das durch Path.toPortableString produziert wird, verwenden. Dieses Format interpretiert das erste einzelne Doppelpunktzeichen (':') als Einheitentrennzeichen, das Zeichen '/' als Segmenttrennzeichen und ein doppeltes Doppelpunktzeichen ("::") als ein literales Doppelpunktzeichen. So wird zum Beispiel auf Unix-Plattformen der Code new Path("c:/temp") nun einen relativen Pfad mit zwei Segmenten erstellen. In ähnlicher Weise wird der Code new Path("a\\b") nun einen Pfad mit einem einzelnen Segmebnt auf Unix-Plattformen und einen Pfad mit zwei Segmenten unter Windows erstellen.

Bei Plug-ins, die Pfade mit Hilfe der Methode IPath.append(String) erstellen, die angenommen hat, dass ':' und '\' auf allen Plattformen eine besondere Bedeutung hatten, muss der Code eventuell aktualisiert werden. In Eclipse 3.1 verwendet diese Methode betriebssystemspezifische Einheiten- und Segmentbegrenzer, um die zur Verfügung gestellte Pfadzeichenfolge zu interpretieren. So wird zum Beispiel beim Aufruf von append("a\\b") auf Unix-Plattformen ein einzelnes Segment angehängt, während unter Windows weiterhin zwei Segmente angehängt werden.

Alle Datemdateien, die durch die Plattform gelesen und interpretiert werden, werden ':' und '\' nicht länger als Sonderzeichen auf allen Plattformen behandeln. Alle Pfade, die in Datendateien gespeichert sind, die auf mehreren Plattformen gelesen werden können, müssen in portabler Form vorliegen. So dürfen zum Beispiel Pfade von Symboldateien und andere Pfade in plugin.xml nur das Zeichen '/' als Pfadsegmenttrennzeichen verwenden.

3. Erweiterungs-Registrierungsdatenbank

Was ist betroffen: Plug-ins, die die Objekte IExtensionPoint, IExtension und IConfigurationElement von der Plug-in- oder Erweiterungsdatenbank der Eclipse-Plattform bearbeiten oder bewahren.

Beschreibung: Vor 3.0 waren alle Objekte, die von der Erweiterungs-Registrierungsdatenbank (der früheren Plug-in-Registrierungsdatenbank) gut für immer. In Eclipse 3.0 wurden Änderungen vorgenommen, die es ermöglichten, dass Plug-ins dynamisch hinzugefügt oder entfernt wurden, ohne Eclipse neu starten zu müssen. Wenn ein Plug-in ohne Neustart entfernt wird, werden seine Eintragungen in der Erweiterungs-Registrierungsdatenbank notwendigerweise ungültig. Das bedeutet, dass ein anderes Plug-in, das ein zuvor von der Erweiterungs-Registrierungsdatenbank des gelöschten Plug-ins erhaltenes Objekt behält, dann ein ungültiges Objekt behalten würde. Der einzige Hinweis, den ein Client erhalten könnte, käme aus der Überwachung von IRegistryChangeEvent. Das Problem bestand seit Eclipse 3.0, wurde jedoch in der Praxis selten bemerkt, da es höchst unwahrscheinlich ist, dass ein Plug-in entfernt wird, ohne Eclipse neu zu starten.

Dieses Problem wurde in 3.1 wie folgt angesprochen:

Erforderliche Maßnahme: Wenn Ihr Plug-in dynamisch-empfindlich sein muss (d.h. in der Lage sein muss, das Hinzufügen oder Entfernen von Plug-ins während der Verarbeitung zu handhaben), muss der Code, der sich mit dem Objekt IExtensionPoint, IExtension und IConfigurationElement gefasst, das aus einem anderen Plug-in stammt, so geändert werden, dass IRegistryChangeEvent exakt so abgefangen wird, als sei es eine markierte Ausnahme. Das Abfangen der Ausnahme (statt einer Vorabmarkierung von isValid()) ist der einzige absolut sichere Weg, den Fall eines Plug-ins, das durch einen gleichzeitigen Thread entfernt wird (was, wenn dies geschieht, nahezu sicher so sein wird) zu handhaben.

4. Optionen des Codeformatierungsprogramms

Was ist betroffen: Plug-ins, die über das Programm auf die Java-Code-Formatierungsprogrammoptionen zugreifen.

Beschreibung: In Eclipse 3.0 konnten die Werte für die Code-Formatierungsprogrammoption org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR nur TAB oder SPACE sein. In der Spezifikation wurde nicht ausdrücklich erwähnt, das es sich bei dem Werttyp um eine Aufzählung handelt, die in zukünftigen Releases noch erweitert werden könnte. In Eclipse 3.1 wurde ein dritter, möglicher Wert, MIXED, hinzugefügt, um den Fehler 73104 anzusprechen. Die Spezifikation wurde geändert, indem dieser neue Wert aufgenommen und darauf hingewiesen wurde, dass in Zukunft weitere Werte hinzugefügt werden.

Erforderliche Maßnahme: Clients, die diese Code-Formatierungsprogrammoption über das Programm lesen oder setzen, sollten prüfen, ob ihr Code den neuen, dritten Wert berücksichtigt und sicherstellen, dass er in einer robusten Weise geschrieben ist, die problemlos fehlschlägt, wenn er auf einen unerwarteten Optionswert trifft.

5. API-Vertragsänderungen an AntCorePreferences

Was ist betroffen: Plug-ins, die org.eclipse.ant.core.AntCorePreferences als Unterklasse aufnehmen oder als Exemplar erstellen.

Beschreibung: In Eclipse 3.0 war die Klasse org.eclipse.ant.core.AntCorePreferences nicht so gekennzeichnet, dass Clients kein Exemplar davon erstellen oder sie in Unterklassen aufnehmen dürfen. Dieses war ein Versehen, das in Eclipse 3.1 dadurch korrigiert wurde, dass die Klasse als nicht für die Exemplarerstellung oder Aufnahme in Unterklassen geeignet gekennzeichnet wurde.

Erforderliche Maßnahme: Clients, die über das Programm ein Exemplar von org.eclipse.ant.core.AntCorePreferences erstellen, sollten ihren Code zum Abruf der Benutzervorgaben unter Verwendung von org.eclipse.ant.core.AntCorePlugin.getPreferences() migrieren. Jede Unterklasse muss überarbeitet werden, so dass sie org.eclipse.ant.core.AntCorePreferences nicht länger in Unterklassen aufnimmt.

6. API-Vertragsänderungen an der Richtlinienklasse in JFace

Was ist betroffen: RCP-Anwendungen, die das durch die Workbench gesetzte JFace-Protokoll außer Kraft setzen.

Beschreibung: In Eclipse 3.0 hat die Workbench das Workbench-Protokoll als das Protokoll gesetzt, das für die Protokollierung von JFace-Fehlern zu verwenden ist, indem das Protokoll des Workbench-Plug-ins direkt an org.eclipse.jface.util.Policy.setLog(ILog) übergeben wurde. In 3.1 wurde die Abhängigkeit von ILog aus JFace entfernt, um Standalone-Anwendungen unter Verwendung von SWT und JFace außerhalb der Eclipse-Laufzeit zu ermöglichen. Eine neue Schnittstelle, ILogger, wurde eingeführt, um die Erfordernisse von JFace zu erfüllen. Die Workbench wurde so geändert, dass sie einen ILogger zur Verfügung stellt, der das Workbench-ILog erweitert. Weitere Informationen finden Sie unter Fehler 88608.

Erforderliche Maßnahme: Bei den meisten RCP-Anwendungen sollte es nicht erforderlich, das durch die Workbench gesetzte Protokoll außer Kraft zu setzen. Wenn sie aber zuvor Policy.setLog(ILog) aufgerufen haben, müssen sie s geändert werden, dass sie stattdessen ein ILogger übergeben.

7. API-Vertragsänderungen zur Ermöglichung einer Standardperspektive Null

Was ist betroffen: RCP-Anwendungen, die eine Standardperspektive nicht-Null erwarten.

Beschreibung Um RCP-Anwendungen zu ermöglichen, mit einem leeren Fenster ohne geöffnete Perspektiven zu starten (Erweiterung 71150), wurden WorkbenchAdvisor.getInitialWindowPerspectiveId() und IPerspectiveRegistry.getDefaultPerspective() so geändert, dass auch die Rückgabe von Null zulässig ist. In der IDE gibt es immer eien Standardperspektive, so dass IPerspectiveRegistry.getDefaultPerspective() nicht Null zurückgeben wird. Entsprechend wird, wenn eine vorhandene RCP-Anwendung zuvor einen Wert nicht-Null von WorkbenchAdvisor.getInitialWindowPerspectiveId() zurückgegeben hat, IPerspectiveRegistry.getDefaultPerspective() immer noch einen Wert nicht-Null zurückgeben.

Erforderliche Maßnahme: Von Clients wirk keine Maßnahme erwartet.

8. API-Vertragsänderungen an IViewLayout

Was ist betroffen: Plug-ins, die org.eclipse.ui.IViewLayout. implementieren.

Beschreibung: In Eclipse 3.0 war die Klasse org.eclipse.ui.IViewLayout nicht so markiert, dass Clients sie nicht implementieren dürfen. Dieses war ein Versehen, das in Eclipse 3.1 dadurch korrigiert wurde, dass die Klasse als nicht für die Implementierung durch Clients gekennzeichnet wurde.

Erforderliche Maßnahme: Jede implementierende Klasse muss überarbeitet werden, so dass sie org.eclipse.ui.IViewLayout nicht länger implementiert.

9. API-Vertragsänderungen an IVMInstall

Was ist betroffen: Plug-ins, die org.eclipse.jdt.launching.IVMInstall. implementieren.

Beschreibung: In Eclipse 3.0 war die Klasse org.eclipse.jdt.launching.IVMInstall nicht so markiert, dass Clients sie nicht direkt implementieren dürfen. Dieses war ein Versehen, das in Eclipse 3.1 dadurch korrigiert wurde, dass die Klasse als nicht für die direkte Implementierung durch Clients gekennzeichnet wurde. Um die Binärkompatibilität beizubehalten, erlauben wir es den Clients weiterhin, die Schnittstelle direkt zu implementieren, empfehlen jedoch sehr, dass Clients stattdessen org.eclipse.jdt.launching.AbstractVMInstall in Unterklassen aufnehmen. Clients, die IVMInstall implementieren, sollten auch die neue optionale Schnittstelle org.eclipse.jdt.launching.IVMInstall2 implementieren, die AbstractVMInstall nun implementiert. Es wird empfohlen, dass Clients die neue Schnittstelle IVMInstall2 implementieren, um das in Fehler 73493 aufgeführte Problem zu vermeiden. Die empfohlene Migration ist, AbstractVMInstall in Unterklassen aufzunehmen.

Erforderliche Maßnahme: Jede implementierende Klasse, die org.eclipse.jdt.launching.AbstractVMInstall nicht bereits in Unterklassen aufnimmt, sollte so überarbeitet werden, dass sie org.eclipse.jdt.launching.AbstractVMInstall in Unterklassen aufnimmt.

10. SelectionEnabler.SelectionClass jetzt paket-sichtbar

Was ist betroffen: Plug-ins, die org.eclipse.ui.SelectionEnabler.SelectionClass verwenden.

Beschreibung: In Eclipse 3.0 war die verschachtelte Implementierungsklasse org.eclipse.ui.SelectionEnabler.SelectionClass öffentlich, ohne Einschränkungen hinsichtlich ihrer Verwendung. Dieses war ein Versehen, das in Eclipse 3.1 dadurch korrigiert wurde, dass die Klasse paket-sichtbar gemacht wurde.

Erforderliche Maßnahme: Alle Klassen, die ein Exemplar erstellen von org.eclipse.ui.SelectionEnabler.SelectionClass oder dieses erweitern, müssen überarbeitet werden, so dass sie nicht länger auf diese Klasse verweisen.

11. ContributionItem.getParent() kann Null zurückgeben

Was ist betroffen: Plug-ins, die getParent() bei einer Unterklasse von org.eclipse.jface.action.ContributionItem aufrufen.

Beschreibung: In Eclipse 3.0 hat die Methode org.eclipse.jface.action.ContributionItem.getParent() nicht angegeben, dass sie Null zurückgeben könnte. Dieses war ein Versehen, das in Eclipse 3.1 dadurch korrigiert wurde, dass das Javadoc für die Methode klärt, wann sie Null zurückgeben kann. Weitere Informationen hierzu finden Sie unter Fehler 92777.

Erforderliche Maßnahme: Jeder Code, der ContributionItem.getParent() aufruft, muss sicherstellen, dass er ein Ergebnis Null verarbeiten kann.

12. Änderungen an isPropertySet(boolean) in IPropertySource und IPropertySource2

Was ist betroffen: Plug-ins, die org.eclipse.ui.views.properties.IPropertySource oder IPropertySource2 implementieren.

Beschreibung: In Eclipse 3.0 wurde die Spezifikation für die Methode org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) unrichtigerweise so geändert, dass sie besagt, dass 'true' zurückgegeben werden sollte, wenn die angegebene Eigenschaft keinen aussagekräftigen Standardwert hat. In früheren Versionen wurde angegeben, dass in diesem Fall 'false' zurückgegeben werden sollte. Dies war eine unbeabsichtigte API-Änderung, die eine Unterbrechung zur Folge hat, obschon die Implementierung genau so wie vorher funktionierte, wenn die Eigenschaftsquelle IPropertySource und nicht IPropertySource2 implementierte. Dies wurde in 3.1 dadurch korrigiert, dass die Spezifikation für IPropertySource.isPropertySet(boolean) auf die frühere Angabe zurückgesetzt wurde (nämlich, dass 'false' in diesem Fall zurückgegeben werden sollte) und dass 'IPropertySource2.isPropertySet(boolean)' dies außer Kraft setzt, um anzugeben, dass in diesem Fall 'true' zurückgegeben werden sollte. Weitere Informationen hierzu finden Sie unter Fehler 21756.

Erforderliche Maßnahme: Alle Klassen, die 'IPropertySource' oder 'IPropertySource2' implementieren, wobei einige der Eigenschaften keine aussagekräftigen Standardwerte haben, sollten geprüft werden, um sicherzustellen, dass sie den entsprechenden Wert für 'isPropertySource(boolean)' zurückgeben. Clients sollten überprüfen, ob die Schaltfläche 'Standardwert wiederherstellen' in der Sicht 'Eigenschaften' wie für ihre Eigenschaftsquelle erwartet funktioniert.

13. handlerSubmission-Element gelöscht aus dem Erweiterungspunkt org.eclipse.ui.commands extension point

Was ist betroffen: Plug-ins, die das experimentelle handlerSubmission-Element verwendeten, das in den Eclipse 3.0-Erweiterungspunkt org.eclipse.ui.commands eingeführt wurde.

Beschreibung: In Eclipse 3.0 wurde ein experimentelles Element in den Erweiterungspunkt org.eclipse.ui.commands eingeführt. Dieses Element sollte dazu dienen, Steuerroutinen durch XML zu registrieren. Seitdem wurde ein weit leistungsfähigerer Mechanismus, der Erweiterungspunkt org.eclipse.ui.handlers, eingeführt. Da das Element als experimentell gekennzeichnet war, wurde es nun entfernt.

Erforderliche Maßnahme: Alle Plug-ins, die ein Element handlerSubmission definieren, sollten auf den Erweiterungspunkt org.eclipse.ui.commands migrieren.

14. Das statische nicht finale API-Feld GLOBAL_IGNORES_CHANGED in TeamUI wurde jetzt final

Was ist betroffen: Plug-ins, die das Feld GLOBAL_IGNORES_CHANGED von TeamUI gesetzt haben.

Beschreibung: In Eclipse 3.0 wurde das Feld GLOBAL_IGNORES_CHANGED der Klasse TeamUI hinzugefügt. Dieses Feld ist eine Konstante, die in einem Änderungsereignis für Eigenschaften verwendet wird, um anzuzeigen, dass sich die Liste globaler Ignorierungen, die durch das Team-Plug-in gepflegt wird, geändert hat. Dieses Feld war in 3.0 nicht als final markiert, was es aber sein sollte. Es wurde in 3.1 final gemacht.

Erforderliche Maßnahme: Alle Plug-ins, die das obige Feld gesetzt haben, können dies nicht länger machen.

15. ClassCastException unter Verwendung von FillLayout

Was ist betroffen: Plug-ins, die unrichtigerweise FillLayout verwenden.

Beschreibung: In Eclipse 3.0 wurden FillLayout keine Layoutdaten zugeordnet und wenn eine Anwendung einem untergeordneten Element, das durch ein FillLayout verwaltet wurde, Layoutdaten zugeordnet hat, wurde dies ignoriert. In Eclipse 3.1 wurde FillLayout Untertützung hinzugefügt, um Größeninformationen in den Cache zu stellen, um die Leistung bei der Größenänderung zu verbessern. Die in den Cache gestellten Dtaen werden in einem Objekt 'FillData' gespeichert, das jedem untergeordneten Element zugeordnet ist, das durch FillLayout verwaltet wird. Wenn eine Anwendung unrichtigerweise einem untergeordneten Element Layoutdaten zugeordnet hat, wird eine ClassCastException ausgelöst, wenn computeSize für das übergeordnete Element aufgerufen wird.

Erforderliche Maßnahme: Alle untergeordneten Elemente in einem FillLayout suchen, die Layoutdaten zugeordnet haben und die Zuordnung dieser Layoutdaten stoppen.

16. IllegalArgumentException ausgelöst bei der Erstellung eines Fensterobjekts mit einem entfernten übergeordneten Element

Was ist betroffen: Plug-ins, die bei der Erstellung eines Fensterobjekts Ausnahmen abfangen.

Beschreibung: In Eclipse 3.0 wurde bei der Erstellung eines Fensterobjekts mit einem entfernten übergeordneten Element keine Ausnahme ausgelöst und der Fensterobjektcode schlug zu einem späteren Zeitpunkt fehl oder eine SWTException mit dem Text "Fensterobjekt ist entfernt" wurde ausgelöst. In Eclipse 3.1 wird der Konstruktor bei der Erstellung eines Fensterobjekts mit einem entfernten übergeordneten Element eine IllegalArgumentException mit dem Text 'Argument nicht gültig' auslösen.

Erforderliche Maßnahme:Jeder Code, der die SWTException bei der Erstellung eines Fensterobjekts verarbeitet, muss auch die IllegalArgumentException verarbeiten.