org.eclipse.platform.doc.isv/porting/3.1/incompatibilities.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.30 - (download) (as text) (annotate)
Thu Jun 1 21:42:14 2006 UTC (3 years, 5 months ago) by johna
Branch: MAIN
CVS Tags: v20070607-1300, v20070607-0010, v20070510-0010, I20070206-0010, v20060602-1302, I20070814-0800, v20070515-0010, v20070109-1100, v20060925, v20070313-1330, v20070607-0011, v20060731, v20070403-0800, v20070424-0800, v20070917-1800, v20070605-0010, v20070605-0011, v20060803, v20070306-0800, v20070806-1800, v20070205, v20070130-0800, R3_3_1_1, v20070430-0010, v20070202, v20060808, v20070319-0010, v20070613, v20061121-0800, v20061213-1300, R3_2_1, v20070531-0010a, v20061129, R3_2_2, v20061017-0800, v20070531-1734, v20061107-0800, v20070427, v20060809-1200, v20070226, v20061211-0010, v20060724, v20070525-0010, v20070528-1858, v20070724-0800, v20070516-0800, v20070911-0800, v20061113, v20060602-1130, r321_v2006030, v20061101-0800, v20070427-1300, v20070427-0010, v20070802-0800, v20070525-1346, v20070607-2219, v20070523-0010, v20060710, v20061213-1300b, v20070205-1800, v20070917_1242, v20061023, v20070220-0800, v20060926-0800, v20070313-0800, v20070815, R3_2, R3_3, v20060829-0800, M20070913-0800, v20061003-0800, v20070116-0800, I20070731-0800, v20061024-0800, v20070828-0800, v20070501-0010, v20070319-1800, v20070524-0800, v20070419, r331_v20070913, pre_R3_3, v20061030-0010, v20070318, v20070416, v20070227-0800, v20070808-1800, v20070430-0800, v20070508-0800, v20070904-0800, v20070503-0800, v20070913-0800, r322_v20070109, v20070316, v20070123, v20070122, v20070925-0800, v20060602-0011sf, v20061006, I20070821-0800, v20070524-0010, v20061205-0800, v20070511-0010, v20070525-1050, v20070404, v20061030-1200, v20061128-0800, v20061120, v20070530-0010, v20070806-0010, v20070710-0800, v20070410-0800, v20060605, v20070525-0010a, v20070525-0010b, I20070814-0800a, v20070524, v20070123-0800, v20070417-0800, M20070822-0800, R32x_v20070115, v20061010-0800, v20070814-0800, v20070205-0010, v20061114-0800, v20070606-0011, v20070601-1520, v20070717-0800, R32x_v20060710, R32x_v20060711, v20070213-0800, v20070319-0800, v20060612-0900, v20070608-1300, v20070606-0010, v20060612, v20070327-0800, v20060821, v20070516-0010, v20060602-0011, v20071002-0800, v20070321-1800, v20070731-0800, v20070108, M20070801-0800, v20070427-0800, v20070607-1800, v20070423, R3_3_1, R3_3_2, v20070821-0800, v20070312, R32x_v20060808, v20070531-1300, v20070531-0010, v20070914, v20070917, v20070919, v20060626, v20061211-1600, v20070219, v20060918, I20060605-1430, v20070525-1225, v20070512-0010, v20070430-1300, v20061208, v20070621, v20070511-0100, v20070530-1714
Branch point for: R3_3_maintenance, R3_2_maintenance
Changes since 1.29: +1 -1 lines 
fixed typos

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>

<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2005. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../../book.css" charset="ISO-8859-1" type="text/css">
<title>Incompatibilities between Eclipse 3.0 and 3.1</title>
</head>

<body>

<h1>Incompatibilities between Eclipse 3.0 and 3.1</h1>

<p> Eclipse changed in
incompatible ways between 3.0 and 3.1 in ways that affect plug-ins. The
following entries describe the areas that changed and provide instructions for
  migrating 3.0 plug-ins to 3.1. Note that you only need to look here if you are experiencing
  problems running your 3.0 plug-in on 3.1.</p>
<ol>
  <li><a href="#Preference Store">Plug-in Preferences</a></li>
  <li><a href="#IPath Changes">Changes to IPath constraints</a></li>
  <li><a href="#Extension Registry">Extension registry</a></li>
  <li><a href="#Code Formatter Options">Code formatter options</a></li>
  <li><a href="#AntCorePreferences">API contract changes to AntCorePreferences</a></li>
  <li><a href="#JFaceLogPolicy">API contract changes to Policy class in JFace</a></li>
  <li><a href="#NullDefaultPerspective">API contract changes to allow a null default 
    perspective</a></li>
  <li><a href="#IViewLayout">API contract changes to IViewLayout</a></li> 
  <li><a href="#IVMInstall">API contract changes to IVMInstall</a></li> 
  <li><a href="#SelectionEnabler.SelectionClass">SelectionEnabler.SelectionClass 
    made package-visible</a></li>
  <li><a href="#ContributionItem.getParent">ContributionItem.getParent() can return 
    null</a></li>
  <li><a href="#IPropertySource.isPropertySet">Changes to isPropertySet(boolean) 
    in IPropertySource and IPropertySource2</a></li>
  <li><a href="#handlerSubmission">handlerSubmission element
    deleted from the org.eclipse.ui.commands extension
    point</a></li>
  <li><a href="#teamUI">Static non-final API field GLOBAL_IGNORES_CHANGED 
  in TeamUI made final</a></li>
  <li><a href="#FillData">ClassCastException using FillLayout</a></li>
  <li><a href="#DisposedParent">Creating a widget with a disposed parent</a></li>
</ol>
<hr>

<h2><a name="Preference Store"></a>1. Plug-in Preferences</h2>
  
<p><strong>What is affected:</strong> Plug-ins who initialize their default plug-in preference values by over-riding <code>Plugin#initializeDefaultPreferences</code> or
use preference change listeners.</p>
<p><strong>Description: </strong> In Eclipse 3.1 the <code>org.eclipse.jface.preference.IPreferenceStore</code> 
  object obtained from <code>org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore</code> 
  was migrated to live on top of the new 3.0 Eclipse preference framework supplied 
  by the <code>org.eclipse.core.runtime</code> plug-in. </p>
  
  
<p><strong>Action required: </strong> As a result, clients using the preference 
  APIs should check for two possible issues: </p>
<ol>
  <li>The type of the objects contained in preference change events is not guaranteed; both the old value and
  new value in events can be null, a <code>String</code>, or a typed object. Therefore to be
  a good client, preference change listeners should be able to handle all three of these possible situations.</li>
  <li>If your plug-in uses <code>org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences</code> then
  you must be sure to include the <code>org.eclipse.core.runtime.compatibility</code> plug-in in your plug-in's list
  of required plug-ins as this dependency has been removed from the <code>org.eclipse.ui.workbench</code> 
    plug-in.</li>
</ol>
<p>See also the <a href="recommended.html#PreferenceStore">JFace Preference Store</a>
paragraph in the recommended changes section of this guide.
</p>
<h2><a name="IPath Changes"></a>2. Changes to IPath constraints</h2>
<p>
<b>What is affected:</b> Plug-ins that create, manipulate, or store <tt>IPath</tt> objects.
</p><p>
<b>Description:</b> In Eclipse 3.0, <tt>IPath</tt> had a number of restrictions
on the segments of paths that were more restrictive than the restrictions of the
underlying operating system. These included:</p>
<ul>
<li>Leading and trailing whitespace in path segments were not allowed</li>
<li>The colon character (':') was reserved as a device separator character</li>
<li>The backslash character ('\') was reserved as a segment separator character</li>
</ul>
<p>These restrictions have been removed in Eclipse 3.1 when the platform's data
location (workspace) is located on a file system that does not have these restrictions.
</p><p>
<b>Action required:</b> In order to enable the proper treatment of the expanded 
range of paths, all usage of <tt>Path</tt> and <tt>IPath</tt> within plug-ins 
should be reviewed and updated as described below. Most unmodified plug-ins 
will continue to behave exactly as in 3.0 on all paths considered legal in 3.0. 
However, unless these prescribed changes are made, they are likely to fail in 
cases involving paths considered legal in 3.1 that were illegal in 3.0.</p>
<p>
Plug-ins that store string representations of paths in a format that needs to be 
readable across different platforms should migrate to the new 
<tt>Path.fromPortableString</tt> factory method. This method produces
an <tt>IPath</tt> instance from a platform-independent format. This string 
representation of paths can be created using the <tt>IPath.toPortableString</tt> method.
Examples of metadata files that are affected include files that are stored inside Eclipse
workspace projects (.project, .classpath, etc), and all paths stored in the preference
store (<tt>org.eclipse.core.runtime.preferences.IPreferencesService</tt>).</p> 
<p>
Note: <tt>fromPortableString</tt> will correctly read all path strings that were
created using the Eclipse 3.0 <tt>IPath.toString</tt> method, but not the
Eclipse 3.1 <tt>toString</tt> method. Thus in most cases no change is required 
to existing metadata file formats except to begin writing paths with <tt>toPortableString</tt>
and reading paths with <tt>fromPortableString</tt>.</p>
<p>
Plug-ins that were creating paths from hard-coded string literals that assumed 
':' and '\' had special meaning on all platforms will need to migrate. The easiest
solution is to restrict string path literals to the subset that is supported
on all platforms (avoid colon and backslash characters).  Path literals can support
the complete set of valid Unix paths by using the portable path string format produced
by <tt>Path.toPortableString</tt>. This format interprets the first single colon (':') 
as the device separator, slash ('/') as the segment separator, and double colon ("::") 
as a literal colon character. For example, the code <tt>new Path("c:/temp")</tt>
will now create a relative path with two segments on Unix platforms.  Similarly,
<tt>new Path("a\\b")</tt> will now create a path with a single segment
on Unix platforms, and a path with two segments on Windows.</p>
<p>
Plug-ins constructing paths using the <tt>IPath.append(String)</tt> method 
that assumed ':' and '\' had special meaning on all platforms may need to update their code.
In Eclipse 3.1, this method uses operating-system specific device and segment
delimiters to interpret the provided path string.  For example, calling <tt>append("a\\b")</tt>
on Unix platforms will now append a single segment, whereas on Windows it will
continue to append two segments.</p>
<p>
Any data files read and interpreted by the platform will no longer treat ':' and '\' as 
special characters on all platforms.  All paths stored in data files that can be
read on multiple platforms must be in portable form.  For example, paths of
icon files and other paths in <tt>plugin.xml</tt> must use only '/' as
the path segment separator.</p>
<h2><a name="Extension Registry"></a>3. Extension registry</h2>

<p><b>What is affected:</b> Plug-ins that manipulate or retain <code>IExtensionPoint</code>,
<code>IExtension</code>, and <code>IConfigurationElement </code>objects from the
Eclipse Platform's plug-in or extension registry.</p>
<p><b>Description: </b>Prior to 3.0, all objects obtained from the extension
registry (of the former plug-in registry) were good forever. Changes were made
in Eclipse 3.0 that allowed plug-ins to be dynamically added or removed without
having to restart Eclipse. When a plug-in is removed without restarting, its
entries in the extension registry necessarily become invalid. This means that
another plug-in holding on to an object obtained previously from the deleted
plug-in's extension registry entry would be left holding an invalid object. The
only hint that a client could get would be from listening to <code>IRegistryChangeEvent</code>.
The problem has existed since Eclipse 3.0, but is rarely encountered in practice
because it is highly unusual for a plug-in to be removed without restarting
Eclipse.</p>
<p>This problem has been addressed in 3.1 by:</p>
<ul>
  <li>Existing methods on these <code>IExtensionPoint</code>, <code>IExtension</code>,
    and <code>IConfigurationElement</code> now specify that <code>InvalidRegistryObjectException</code>
    will be thrown when the object is invalid. The exception is unchecked so
    that dynamic unaware clients are not forced to check it.</li>
  <li>A new <code>isValid()</code> method was added to these interfaces so that
    a client can determine whether an object is still valid.</li>
  <li>Recommendations were added to the specs to make it clear that hanging on
    to objects obtained from the extension registry is not recommended.</li>
</ul>
<p><b>Action required:</b> If your plug-in needs to be dynamic-aware (i.e.
capable of dealing with the on-the-fly addition or removal of plug-ins), the
code that deals with <code>IExtensionPoint</code>, <code>IExtension</code>, and <code>IConfigurationElement</code>
object sourced from some other plug-in must be changed to catch <code>IRegistryChangeEvent</code>,
exactly as if it were a checked exception. Catching the exception (rather than
an <code>isValid()</code> pre-check) is the only surefire way to deal with the
case of a plug-in being removed by a concurrent thread (which, if it happens, it
almost certainly will be).</p>

<h2><a name="Code Formatter Options"></a>4. Code formatter options</h2>
<p><b>What is affected:</b> Plug-ins that programmatically access the Java code formatter options.</p>

<p><b>Description:</b> In Eclipse 3.0, the values for the code formatter option 
  <code>org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR</code> 
  could only be <code>TAB</code> or <code>SPACE</code>. The specification made 
  no explicit mention that the value type was an enumeration that might grow in 
  future releases. In Eclipse 3.1, a third possible value, <code>MIXED</code>, 
  was added to address bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=73104">73104</a>. 
  The specification has been changed to include this new value, and to allow for 
  more values being added in the future.</p>
<p><b>Action required:</b> Clients programmatically reading or setting this code 
  formatter option should check their code to take account of the new third value, 
  and to ensure that it is written in a robust way that fails gracefully if it 
  ever encounters an option value that it did not anticipate.</p>
  
<h2><a name="AntCorePreferences"></a>5. API contract changes to AntCorePreferences</h2>
<p><b>What is affected:</b> Plug-ins that subclass or instantiate <code>org.eclipse.ant.core.AntCorePreferences</code></p>

<p><b>Description:</b> In Eclipse 3.0, the class <code>org.eclipse.ant.core.AntCorePreferences</code> 
  was not marked that clients may not instantiate or subclass.
  This was an oversight that has been addressed in Eclipse 3.1 with the class marked as not intended to be subclassed or instantiated.
  </p>
<p><b>Action required:</b> Clients programmatically creating an instance of <code>org.eclipse.ant.core.AntCorePreferences</code>
 	should migrate their code to retrieve the preferences using: <code>org.eclipse.ant.core.AntCorePlugin.getPreferences()</code>.
	Any subclass will need to be reworked to no longer subclass <code>org.eclipse.ant.core.AntCorePreferences</code>.</p>
	
<h2><a name="JFaceLogPolicy"></a>6. API contract changes to Policy class in JFace</h2>
<p><b>What is affected:</b> RCP applications that override the JFace log set by 
  the workbench.</p>
<p><b>Description:</b> In Eclipse 3.0, the workbench set the workbench's log as 
  the log to use for logging JFace errors, by passing the workbench plug-in's 
  log directly to <code>org.eclipse.jface.util.Policy.setLog(ILog)</code>. In 
  3.1, the dependency on <code>ILog</code> has been removed from JFace in order 
  to enable standalone applications using SWT and JFace outside of the eclipse 
  runtime. A new interface, <code>ILogger</code>, has been introduced to meet 
  JFace's needs. The workbench has been changed to provide an <code>ILogger</code> 
  wrapping the workbench <code>ILog</code>. For further details, see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=88608">88608</a>.</p>
<p><b>Action required:</b> Most RCP applications should not need to override the 
  log set by the workbench, but if they previously called <code>Policy.setLog(ILog)</code>, 
  they will need to be changed to pass an <code>ILogger</code> instead.</p>
	
<h2><a name="NullDefaultPerspective"></a>7. API contract changes to allow a null default 
  perspective</h2>
<p><b>What is affected:</b> RCP applications expecting a non-null default perspective.</p>
<p><b>Description:</b> In order to allow RCP applications to start with an empty 
  window with no perspectives open (enhancement <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71150">71150</a>), 
  <code>WorkbenchAdvisor.getInitialWindowPerspectiveId()</code> and <code>IPerspectiveRegistry.getDefaultPerspective()</code> 
  have been changed to allow null to be returned. In the IDE, there is always 
  a default perspective, so <code>IPerspectiveRegistry.getDefaultPerspective()</code> 
  will not return null. Similarly, if an existing RCP app previously returned 
  a non-null value from <code>WorkbenchAdvisor.getInitialWindowPerspectiveId()</code>, 
  then <code>IPerspectiveRegistry.getDefaultPerspective()</code> will still return 
  a non-null value.</p>
<p><b>Action required:</b> No action should be required by clients.</p>

<h2><a name="IViewLayout"></a>8. API contract changes to IViewLayout</h2>
<p><b>What is affected:</b> Plug-ins that implement <code>org.eclipse.ui.IViewLayout.</code></p>
<p><b>Description:</b> In Eclipse 3.0, the class <code>org.eclipse.ui.IViewLayout</code> 
  was not marked that clients may not implement. This was an oversight that has 
  been addressed in Eclipse 3.1 with the class marked as not intended to be implemented 
  by clients. </p>
<p><b>Action required:</b> Any implementing classes will need to be reworked to 
  no longer implement <code>org.eclipse.ui.IViewLayout</code>.</p>
<h2><a name="IVMInstall"></a>9. API contract changes to IVMInstall</h2>
<p><b>What is affected:</b> Plug-ins that implement <code>org.eclipse.jdt.launching.IVMInstall.</code></p>
<p><b>Description:</b> In Eclipse 3.0, the class <code>org.eclipse.jdt.launching.IVMInstall</code> 
  was not marked that clients may not implement directly. This was an oversight 
  that has been addressed in Eclipse 3.1 with the class marked as not intended 
  to be implemented directly by clients. To maintain binary compatibility, we 
  still allow clients to implement the interface directly, but strongly recommend 
  that clients subclass <code>org.eclipse.jdt.launching.AbstractVMInstall</code> 
  instead. Clients that implement <code>IVMInstall</code> should also implement 
  the new optional interface <code>org.eclipse.jdt.launching.IVMInstall2</code>, 
  which <code>AbstractVMInstall</code> now implements. It is recommended that 
  clients implement the new interface, <code>IVMInstall2</code>, to avoid the 
  problem noted in bug 73493. The recommended migration is to subclass <code>AbstractVMInstall</code>.</p>
<p><b>Action required:</b> Any implementing classes that do not already subclass 
  <code>org.eclipse.jdt.launching.AbstractVMInstall</code> should be reworked 
  to subclass <code>org.eclipse.jdt.launching.AbstractVMInstall.</code></p>
<h2><a name="SelectionEnabler.SelectionClass"></a>10. SelectionEnabler.SelectionClass 
  made package-visible</h2>
<p><b>What is affected:</b> Plug-ins that use <code>org.eclipse.ui.SelectionEnabler.SelectionClass.</code></p>
<p><b>Description:</b> In Eclipse 3.0, the nested implementation class <code>org.eclipse.ui.SelectionEnabler.SelectionClass</code> 
  was public, with no restrictions on its usage. This was an oversight that has 
  been addressed in Eclipse 3.1 with the class being made package-visible. </p>
<p><b>Action required:</b> Any classes instantiating or extending <code>org.eclipse.ui.SelectionEnabler.SelectionClass</code> 
  will need to be reworked to no longer refer to this class.</p>
  
<h2><a name="ContributionItem.getParent"></a>11. ContributionItem.getParent() 
  can return null</h2>
<p><b>What is affected:</b> Plug-ins that call <code>getParent()</code> on a subclass 
  of <code>org.eclipse.jface.action.ContributionItem.</code></p>
<p><b>Description:</b> In Eclipse 3.0, method <code>org.eclipse.jface.action.ContributionItem.getParent()</code> 
  did not specify that it could return null. This was an oversight that has been 
  addressed in Eclipse 3.1 with Javadoc for the method clarifying when it can 
  return null. For more details, see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=92777">92777</a>.</p>
<p><b>Action required:</b> Any code calling <tt>ContributionItem.getParent()</tt> 
  must ensure that it can handle a null result.</p>

<h2><a name="IPropertySource.isPropertySet"></a>12. Changes to isPropertySet(boolean) 
  in IPropertySource and IPropertySource2</h2>
<p><b>What is affected:</b> Plug-ins that implement <code>org.eclipse.ui.views.properties.IPropertySource</code> 
  or <code>IPropertySource2.</code></p>
<p><b>Description:</b> In Eclipse 3.0, the specification for the method <code>org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean)</code> 
  was incorrectly changed to specify that true should be returned if the specified 
  property did not have a meaningful default value. In previous versions, it specified 
  that false should be returned in this case. This was an inadvertent breaking 
  API change, although the implementation worked the same as before if the property 
  source implemented <code>IPropertySource</code> and not <code>IPropertySource2</code>. 
  This has been corrected in 3.1, with <code>IPropertySource.isPropertySet(boolean)</code> 
  being reverted back to its earlier specification (that false should be returned 
  in this case), and IPropertySource2.isPropertySet(boolean) overriding this to 
  specify that true should be returned in this case. For more details, see bug 
  <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21756 ">21756</a>.</p>
<p><b>Action required:</b> Any classes implementing IPropertySource or IPropertySource2, 
  where some of the properties do not have meaningful default values, should be 
  checked to ensure that they return the appropriate value for isPropertySource(boolean). 
  Clients should check that the Restore Default Value button in the Properties 
  view works as expected for their property source.</p>

<h2><a name="handlerSubmission"></a>13. handlerSubmission element
deleted from the org.eclipse.ui.commands extension point</h2>
<p><b>What is affected:</b> Plug-ins that used the experimental
<code>handlerSubmission</code> element introduced into the
<code>org.eclipse.ui.commands</code> extension point Eclipse 3.0.
</p>
<p><b>Description:</b> In Eclipse 3.0, an experimental element was introduced
into the <code>org.eclipse.ui.commands</code> extension point.  This element was
intended as a way to register handlers through XML.  Since then, a far superior
mechanism, the <code>org.eclipse.ui.handlers</code> extension point, has been
introduced.  Since the element was marked as experimental, it has now been
removed.</p>
<p><b>Action required:</b> Any plug-ins defining a
<code>handlerSubmission</code> element should migrate to the
<code>org.eclipse.ui.commands</code> extension point.</p>
  
<h2><a name="teamUI"></a>14. Static non-final API field GLOBAL_IGNORES_CHANGED 
  in TeamUI made final</h2>
<p><b>What is affected:</b> Plug-ins that were setting the GLOBAL_IGNORES_CHANGED 
  field of TeamUI.</p>
<p><b>Description:</b> In Eclipse 3.0, the GLOBAL_IGNORES_CHANGED field was added 
  to the TeamUI class. This field is a constant that is used in a property change 
  event to indicate that the list of global ignores maintained by the Team plug-in 
  has changed. This field was not marked final in 3.0 but should have been. It 
  has been made final in 3.1.</p>
<p><b>Action required:</b> Any plugins that were setting the above field can no 
  longer do so.</p>

<h2><a name="FillData"></a>15. ClassCastException using FillLayout</h2>
<p><b>What is affected:</b> Plug-ins that incorrectly use FillLayout.</p>
<p><b>Description:</b> In Eclipse 3.0, no layout data was associated with 
the FillLayout and if an application assigned layout data to a child that was 
managed by a FillLayout, it was ignored. In Eclipse 3.1, support was added to
FillLayout to cache size information in order to improve resize performance.
The cached data is stored in a FillData object associated with each child
managed by the FillLayout.  If an application has incorrectly assigned  
layout data to a child, a ClassCastException will be thrown when computeSize 
is called on the parent.</p>
<p><b>Action required:</b> Find any children in a FillLayout that have layout 
data assigned and stop assigning the layout data.</p>

<h2><a name="DisposedParent"></a>16. IllegalArgumentException thrown creating a 
widget with a disposed parent</h2>
<p><b>What is affected:</b> Plug-ins that catch exceptions while creating widgets.</p>
<p><b>Description:</b> In Eclipse 3.0, if a widget was created with a disposed 
parent, no exception was thrown and the widget code failed at a later point or 
an SWTException with text "Widget Is Disposed" was thrown.  In Eclipse 3.1, 
if a widget is created with a disposed parent, the constructor will throw an
IllegalArgumentException with text "Argument not valid".</p>
<p><b>Action required:</b>Any code that handles the SWTException when creating
a widget will also need to handle the IllegalArgumentException.</p>

<p>&nbsp;</p>

</body>
</html>