org.eclipse.platform.doc.isv/porting/3.1/incompatibilities.html
Parent Directory
| 
Revision Log
Revision 1.30 - (view) (download) (as text)
| 1 : | johna | 1.1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| 2 : | <html> | ||
| 3 : | |||
| 4 : | <head> | ||
| 5 : | tod | 1.22 | |
| 6 : | <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." > | ||
| 7 : | tod | 1.21 | |
| 8 : | johna | 1.1 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
| 9 : | <meta http-equiv="Content-Style-Type" content="text/css"> | ||
| 10 : | mvalenta | 1.23 | <link rel="STYLESHEET" href="../../book.css" charset="ISO-8859-1" type="text/css"> |
| 11 : | johna | 1.1 | <title>Incompatibilities between Eclipse 3.0 and 3.1</title> |
| 12 : | </head> | ||
| 13 : | |||
| 14 : | <body> | ||
| 15 : | |||
| 16 : | <h1>Incompatibilities between Eclipse 3.0 and 3.1</h1> | ||
| 17 : | dmegert | 1.26 | |
| 18 : | <p> Eclipse changed in | ||
| 19 : | johna | 1.1 | incompatible ways between 3.0 and 3.1 in ways that affect plug-ins. The |
| 20 : | following entries describe the areas that changed and provide instructions for | ||
| 21 : | migrating 3.0 plug-ins to 3.1. Note that you only need to look here if you are experiencing | ||
| 22 : | problems running your 3.0 plug-in on 3.1.</p> | ||
| 23 : | <ol> | ||
| 24 : | <li><a href="#Preference Store">Plug-in Preferences</a></li> | ||
| 25 : | <li><a href="#IPath Changes">Changes to IPath constraints</a></li> | ||
| 26 : | prapicau | 1.3 | <li><a href="#Extension Registry">Extension registry</a></li> |
| 27 : | darins | 1.7 | <li><a href="#Code Formatter Options">Code formatter options</a></li> |
| 28 : | darins | 1.8 | <li><a href="#AntCorePreferences">API contract changes to AntCorePreferences</a></li> |
| 29 : | nick | 1.9 | <li><a href="#JFaceLogPolicy">API contract changes to Policy class in JFace</a></li> |
| 30 : | nick | 1.12 | <li><a href="#NullDefaultPerspective">API contract changes to allow a null default |
| 31 : | perspective</a></li> | ||
| 32 : | mcq | 1.28 | <li><a href="#IViewLayout">API contract changes to IViewLayout</a></li> |
| 33 : | <li><a href="#IVMInstall">API contract changes to IVMInstall</a></li> | ||
| 34 : | nick | 1.14 | <li><a href="#SelectionEnabler.SelectionClass">SelectionEnabler.SelectionClass |
| 35 : | made package-visible</a></li> | ||
| 36 : | darin | 1.16 | <li><a href="#ContributionItem.getParent">ContributionItem.getParent() can return |
| 37 : | null</a></li> | ||
| 38 : | <li><a href="#IPropertySource.isPropertySet">Changes to isPropertySet(boolean) | ||
| 39 : | in IPropertySource and IPropertySource2</a></li> | ||
| 40 : | acovas | 1.17 | <li><a href="#handlerSubmission">handlerSubmission element |
| 41 : | deleted from the org.eclipse.ui.commands extension | ||
| 42 : | point</a></li> | ||
| 43 : | mvalenta | 1.19 | <li><a href="#teamUI">Static non-final API field GLOBAL_IGNORES_CHANGED |
| 44 : | in TeamUI made final</a></li> | ||
| 45 : | bbiggs | 1.25 | <li><a href="#FillData">ClassCastException using FillLayout</a></li> |
| 46 : | <li><a href="#DisposedParent">Creating a widget with a disposed parent</a></li> | ||
| 47 : | johna | 1.1 | </ol> |
| 48 : | <hr> | ||
| 49 : | |||
| 50 : | <h2><a name="Preference Store"></a>1. Plug-in Preferences</h2> | ||
| 51 : | dj | 1.18 | |
| 52 : | <p><strong>What is affected:</strong> Plug-ins who initialize their default plug-in preference values by over-riding <code>Plugin#initializeDefaultPreferences</code> or | ||
| 53 : | use preference change listeners.</p> | ||
| 54 : | <p><strong>Description: </strong> In Eclipse 3.1 the <code>org.eclipse.jface.preference.IPreferenceStore</code> | ||
| 55 : | darins | 1.7 | object obtained from <code>org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore</code> |
| 56 : | dj | 1.18 | was migrated to live on top of the new 3.0 Eclipse preference framework supplied |
| 57 : | by the <code>org.eclipse.core.runtime</code> plug-in. </p> | ||
| 58 : | |||
| 59 : | |||
| 60 : | <p><strong>Action required: </strong> As a result, clients using the preference | ||
| 61 : | APIs should check for two possible issues: </p> | ||
| 62 : | johna | 1.1 | <ol> |
| 63 : | johna | 1.29 | <li>The type of the objects contained in preference change events is not guaranteed; both the old value and |
| 64 : | dj | 1.2 | new value in events can be null, a <code>String</code>, or a typed object. Therefore to be |
| 65 : | a good client, preference change listeners should be able to handle all three of these possible situations.</li> | ||
| 66 : | <li>If your plug-in uses <code>org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences</code> then | ||
| 67 : | you must be sure to include the <code>org.eclipse.core.runtime.compatibility</code> plug-in in your plug-in's list | ||
| 68 : | johna | 1.29 | of required plug-ins as this dependency has been removed from the <code>org.eclipse.ui.workbench</code> |
| 69 : | dj | 1.2 | plug-in.</li> |
| 70 : | johna | 1.1 | </ol> |
| 71 : | johna | 1.29 | <p>See also the <a href="recommended.html#PreferenceStore">JFace Preference Store</a> |
| 72 : | paragraph in the recommended changes section of this guide. | ||
| 73 : | johna | 1.1 | </p> |
| 74 : | <h2><a name="IPath Changes"></a>2. Changes to IPath constraints</h2> | ||
| 75 : | <p> | ||
| 76 : | <b>What is affected:</b> Plug-ins that create, manipulate, or store <tt>IPath</tt> objects. | ||
| 77 : | mcq | 1.28 | </p><p> |
| 78 : | johna | 1.1 | <b>Description:</b> In Eclipse 3.0, <tt>IPath</tt> had a number of restrictions |
| 79 : | on the segments of paths that were more restrictive than the restrictions of the | ||
| 80 : | mcq | 1.28 | underlying operating system. These included:</p> |
| 81 : | johna | 1.1 | <ul> |
| 82 : | <li>Leading and trailing whitespace in path segments were not allowed</li> | ||
| 83 : | <li>The colon character (':') was reserved as a device separator character</li> | ||
| 84 : | <li>The backslash character ('\') was reserved as a segment separator character</li> | ||
| 85 : | </ul> | ||
| 86 : | mcq | 1.28 | <p>These restrictions have been removed in Eclipse 3.1 when the platform's data |
| 87 : | johna | 1.1 | location (workspace) is located on a file system that does not have these restrictions. |
| 88 : | mcq | 1.28 | </p><p> |
| 89 : | johna | 1.1 | <b>Action required:</b> In order to enable the proper treatment of the expanded |
| 90 : | range of paths, all usage of <tt>Path</tt> and <tt>IPath</tt> within plug-ins | ||
| 91 : | should be reviewed and updated as described below. Most unmodified plug-ins | ||
| 92 : | will continue to behave exactly as in 3.0 on all paths considered legal in 3.0. | ||
| 93 : | However, unless these prescribed changes are made, they are likely to fail in | ||
| 94 : | mcq | 1.28 | cases involving paths considered legal in 3.1 that were illegal in 3.0.</p> |
| 95 : | johna | 1.1 | <p> |
| 96 : | Plug-ins that store string representations of paths in a format that needs to be | ||
| 97 : | readable across different platforms should migrate to the new | ||
| 98 : | <tt>Path.fromPortableString</tt> factory method. This method produces | ||
| 99 : | an <tt>IPath</tt> instance from a platform-independent format. This string | ||
| 100 : | representation of paths can be created using the <tt>IPath.toPortableString</tt> method. | ||
| 101 : | Examples of metadata files that are affected include files that are stored inside Eclipse | ||
| 102 : | workspace projects (.project, .classpath, etc), and all paths stored in the preference | ||
| 103 : | mcq | 1.28 | store (<tt>org.eclipse.core.runtime.preferences.IPreferencesService</tt>).</p> |
| 104 : | johna | 1.1 | <p> |
| 105 : | Note: <tt>fromPortableString</tt> will correctly read all path strings that were | ||
| 106 : | created using the Eclipse 3.0 <tt>IPath.toString</tt> method, but not the | ||
| 107 : | Eclipse 3.1 <tt>toString</tt> method. Thus in most cases no change is required | ||
| 108 : | to existing metadata file formats except to begin writing paths with <tt>toPortableString</tt> | ||
| 109 : | mcq | 1.28 | and reading paths with <tt>fromPortableString</tt>.</p> |
| 110 : | johna | 1.1 | <p> |
| 111 : | Plug-ins that were creating paths from hard-coded string literals that assumed | ||
| 112 : | ':' and '\' had special meaning on all platforms will need to migrate. The easiest | ||
| 113 : | solution is to restrict string path literals to the subset that is supported | ||
| 114 : | on all platforms (avoid colon and backslash characters). Path literals can support | ||
| 115 : | the complete set of valid Unix paths by using the portable path string format produced | ||
| 116 : | by <tt>Path.toPortableString</tt>. This format interprets the first single colon (':') | ||
| 117 : | as the device separator, slash ('/') as the segment separator, and double colon ("::") | ||
| 118 : | as a literal colon character. For example, the code <tt>new Path("c:/temp")</tt> | ||
| 119 : | will now create a relative path with two segments on Unix platforms. Similarly, | ||
| 120 : | <tt>new Path("a\\b")</tt> will now create a path with a single segment | ||
| 121 : | mcq | 1.28 | on Unix platforms, and a path with two segments on Windows.</p> |
| 122 : | johna | 1.1 | <p> |
| 123 : | Plug-ins constructing paths using the <tt>IPath.append(String)</tt> method | ||
| 124 : | that assumed ':' and '\' had special meaning on all platforms may need to update their code. | ||
| 125 : | In Eclipse 3.1, this method uses operating-system specific device and segment | ||
| 126 : | delimiters to interpret the provided path string. For example, calling <tt>append("a\\b")</tt> | ||
| 127 : | on Unix platforms will now append a single segment, whereas on Windows it will | ||
| 128 : | mcq | 1.28 | continue to append two segments.</p> |
| 129 : | johna | 1.20 | <p> |
| 130 : | Any data files read and interpreted by the platform will no longer treat ':' and '\' as | ||
| 131 : | special characters on all platforms. All paths stored in data files that can be | ||
| 132 : | read on multiple platforms must be in portable form. For example, paths of | ||
| 133 : | icon files and other paths in <tt>plugin.xml</tt> must use only '/' as | ||
| 134 : | mcq | 1.28 | the path segment separator.</p> |
| 135 : | prapicau | 1.3 | <h2><a name="Extension Registry"></a>3. Extension registry</h2> |
| 136 : | |||
| 137 : | <p><b>What is affected:</b> Plug-ins that manipulate or retain <code>IExtensionPoint</code>, | ||
| 138 : | <code>IExtension</code>, and <code>IConfigurationElement </code>objects from the | ||
| 139 : | Eclipse Platform's plug-in or extension registry.</p> | ||
| 140 : | <p><b>Description: </b>Prior to 3.0, all objects obtained from the extension | ||
| 141 : | registry (of the former plug-in registry) were good forever. Changes were made | ||
| 142 : | in Eclipse 3.0 that allowed plug-ins to be dynamically added or removed without | ||
| 143 : | having to restart Eclipse. When a plug-in is removed without restarting, its | ||
| 144 : | entries in the extension registry necessarily become invalid. This means that | ||
| 145 : | another plug-in holding on to an object obtained previously from the deleted | ||
| 146 : | plug-in's extension registry entry would be left holding an invalid object. The | ||
| 147 : | only hint that a client could get would be from listening to <code>IRegistryChangeEvent</code>. | ||
| 148 : | The problem has existed since Eclipse 3.0, but is rarely encountered in practice | ||
| 149 : | because it is highly unusual for a plug-in to be removed without restarting | ||
| 150 : | Eclipse.</p> | ||
| 151 : | <p>This problem has been addressed in 3.1 by:</p> | ||
| 152 : | <ul> | ||
| 153 : | <li>Existing methods on these <code>IExtensionPoint</code>, <code>IExtension</code>, | ||
| 154 : | and <code>IConfigurationElement</code> now specify that <code>InvalidRegistryObjectException</code> | ||
| 155 : | will be thrown when the object is invalid. The exception is unchecked so | ||
| 156 : | that dynamic unaware clients are not forced to check it.</li> | ||
| 157 : | <li>A new <code>isValid()</code> method was added to these interfaces so that | ||
| 158 : | a client can determine whether an object is still valid.</li> | ||
| 159 : | <li>Recommendations were added to the specs to make it clear that hanging on | ||
| 160 : | to objects obtained from the extension registry is not recommended.</li> | ||
| 161 : | </ul> | ||
| 162 : | <p><b>Action required:</b> If your plug-in needs to be dynamic-aware (i.e. | ||
| 163 : | capable of dealing with the on-the-fly addition or removal of plug-ins), the | ||
| 164 : | code that deals with <code>IExtensionPoint</code>, <code>IExtension</code>, and <code>IConfigurationElement</code> | ||
| 165 : | object sourced from some other plug-in must be changed to catch <code>IRegistryChangeEvent</code>, | ||
| 166 : | exactly as if it were a checked exception. Catching the exception (rather than | ||
| 167 : | an <code>isValid()</code> pre-check) is the only surefire way to deal with the | ||
| 168 : | case of a plug-in being removed by a concurrent thread (which, if it happens, it | ||
| 169 : | almost certainly will be).</p> | ||
| 170 : | johna | 1.1 | |
| 171 : | jeem | 1.5 | <h2><a name="Code Formatter Options"></a>4. Code formatter options</h2> |
| 172 : | <p><b>What is affected:</b> Plug-ins that programmatically access the Java code formatter options.</p> | ||
| 173 : | johna | 1.1 | |
| 174 : | jeem | 1.5 | <p><b>Description:</b> In Eclipse 3.0, the values for the code formatter option |
| 175 : | <code>org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR</code> | ||
| 176 : | could only be <code>TAB</code> or <code>SPACE</code>. The specification made | ||
| 177 : | no explicit mention that the value type was an enumeration that might grow in | ||
| 178 : | jeem | 1.6 | future releases. In Eclipse 3.1, a third possible value, <code>MIXED</code>, |
| 179 : | jeem | 1.5 | was added to address bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=73104">73104</a>. |
| 180 : | The specification has been changed to include this new value, and to allow for | ||
| 181 : | more values being added in the future.</p> | ||
| 182 : | darins | 1.7 | <p><b>Action required:</b> Clients programmatically reading or setting this code |
| 183 : | jeem | 1.5 | formatter option should check their code to take account of the new third value, |
| 184 : | and to ensure that it is written in a robust way that fails gracefully if it | ||
| 185 : | ever encounters an option value that it did not anticipate.</p> | ||
| 186 : | darins | 1.7 | |
| 187 : | darins | 1.8 | <h2><a name="AntCorePreferences"></a>5. API contract changes to AntCorePreferences</h2> |
| 188 : | darins | 1.7 | <p><b>What is affected:</b> Plug-ins that subclass or instantiate <code>org.eclipse.ant.core.AntCorePreferences</code></p> |
| 189 : | |||
| 190 : | <p><b>Description:</b> In Eclipse 3.0, the class <code>org.eclipse.ant.core.AntCorePreferences</code> | ||
| 191 : | was not marked that clients may not instantiate or subclass. | ||
| 192 : | This was an oversight that has been addressed in Eclipse 3.1 with the class marked as not intended to be subclassed or instantiated. | ||
| 193 : | </p> | ||
| 194 : | <p><b>Action required:</b> Clients programmatically creating an instance of <code>org.eclipse.ant.core.AntCorePreferences</code> | ||
| 195 : | should migrate their code to retrieve the preferences using: <code>org.eclipse.ant.core.AntCorePlugin.getPreferences()</code>. | ||
| 196 : | Any subclass will need to be reworked to no longer subclass <code>org.eclipse.ant.core.AntCorePreferences</code>.</p> | ||
| 197 : | |||
| 198 : | nick | 1.9 | <h2><a name="JFaceLogPolicy"></a>6. API contract changes to Policy class in JFace</h2> |
| 199 : | <p><b>What is affected:</b> RCP applications that override the JFace log set by | ||
| 200 : | the workbench.</p> | ||
| 201 : | <p><b>Description:</b> In Eclipse 3.0, the workbench set the workbench's log as | ||
| 202 : | the log to use for logging JFace errors, by passing the workbench plug-in's | ||
| 203 : | log directly to <code>org.eclipse.jface.util.Policy.setLog(ILog)</code>. In | ||
| 204 : | 3.1, the dependency on <code>ILog</code> has been removed from JFace in order | ||
| 205 : | to enable standalone applications using SWT and JFace outside of the eclipse | ||
| 206 : | runtime. A new interface, <code>ILogger</code>, has been introduced to meet | ||
| 207 : | JFace's needs. The workbench has been changed to provide an <code>ILogger</code> | ||
| 208 : | nick | 1.10 | 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> |
| 209 : | nick | 1.9 | <p><b>Action required:</b> Most RCP applications should not need to override the |
| 210 : | log set by the workbench, but if they previously called <code>Policy.setLog(ILog)</code>, | ||
| 211 : | they will need to be changed to pass an <code>ILogger</code> instead.</p> | ||
| 212 : | |||
| 213 : | nick | 1.11 | <h2><a name="NullDefaultPerspective"></a>7. API contract changes to allow a null default |
| 214 : | perspective</h2> | ||
| 215 : | <p><b>What is affected:</b> RCP applications expecting a non-null default perspective.</p> | ||
| 216 : | <p><b>Description:</b> In order to allow RCP applications to start with an empty | ||
| 217 : | window with no perspectives open (enhancement <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=71150">71150</a>), | ||
| 218 : | <code>WorkbenchAdvisor.getInitialWindowPerspectiveId()</code> and <code>IPerspectiveRegistry.getDefaultPerspective()</code> | ||
| 219 : | have been changed to allow null to be returned. In the IDE, there is always | ||
| 220 : | a default perspective, so <code>IPerspectiveRegistry.getDefaultPerspective()</code> | ||
| 221 : | will not return null. Similarly, if an existing RCP app previously returned | ||
| 222 : | a non-null value from <code>WorkbenchAdvisor.getInitialWindowPerspectiveId()</code>, | ||
| 223 : | then <code>IPerspectiveRegistry.getDefaultPerspective()</code> will still return | ||
| 224 : | a non-null value.</p> | ||
| 225 : | <p><b>Action required:</b> No action should be required by clients.</p> | ||
| 226 : | nick | 1.12 | |
| 227 : | <h2><a name="IViewLayout"></a>8. API contract changes to IViewLayout</h2> | ||
| 228 : | nick | 1.13 | <p><b>What is affected:</b> Plug-ins that implement <code>org.eclipse.ui.IViewLayout.</code></p> |
| 229 : | nick | 1.12 | <p><b>Description:</b> In Eclipse 3.0, the class <code>org.eclipse.ui.IViewLayout</code> |
| 230 : | was not marked that clients may not implement. This was an oversight that has | ||
| 231 : | been addressed in Eclipse 3.1 with the class marked as not intended to be implemented | ||
| 232 : | by clients. </p> | ||
| 233 : | <p><b>Action required:</b> Any implementing classes will need to be reworked to | ||
| 234 : | no longer implement <code>org.eclipse.ui.IViewLayout</code>.</p> | ||
| 235 : | darin | 1.16 | <h2><a name="IVMInstall"></a>9. API contract changes to IVMInstall</h2> |
| 236 : | <p><b>What is affected:</b> Plug-ins that implement <code>org.eclipse.jdt.launching.IVMInstall.</code></p> | ||
| 237 : | <p><b>Description:</b> In Eclipse 3.0, the class <code>org.eclipse.jdt.launching.IVMInstall</code> | ||
| 238 : | was not marked that clients may not implement directly. This was an oversight | ||
| 239 : | that has been addressed in Eclipse 3.1 with the class marked as not intended | ||
| 240 : | darin | 1.24 | to be implemented directly by clients. To maintain binary compatibility, we |
| 241 : | still allow clients to implement the interface directly, but strongly recommend | ||
| 242 : | that clients subclass <code>org.eclipse.jdt.launching.AbstractVMInstall</code> | ||
| 243 : | instead. Clients that implement <code>IVMInstall</code> should also implement | ||
| 244 : | the new optional interface <code>org.eclipse.jdt.launching.IVMInstall2</code>, | ||
| 245 : | which <code>AbstractVMInstall</code> now implements. It is recommended that | ||
| 246 : | clients implement the new interface, <code>IVMInstall2</code>, to avoid the | ||
| 247 : | problem noted in bug 73493. The recommended migration is to subclass <code>AbstractVMInstall</code>.</p> | ||
| 248 : | darin | 1.16 | <p><b>Action required:</b> Any implementing classes that do not already subclass |
| 249 : | darin | 1.24 | <code>org.eclipse.jdt.launching.AbstractVMInstall</code> should be reworked |
| 250 : | darin | 1.16 | to subclass <code>org.eclipse.jdt.launching.AbstractVMInstall.</code></p> |
| 251 : | <h2><a name="SelectionEnabler.SelectionClass"></a>10. SelectionEnabler.SelectionClass | ||
| 252 : | made package-visible</h2> | ||
| 253 : | nick | 1.13 | <p><b>What is affected:</b> Plug-ins that use <code>org.eclipse.ui.SelectionEnabler.SelectionClass.</code></p> |
| 254 : | <p><b>Description:</b> In Eclipse 3.0, the nested implementation class <code>org.eclipse.ui.SelectionEnabler.SelectionClass</code> | ||
| 255 : | was public, with no restrictions on its usage. This was an oversight that has | ||
| 256 : | been addressed in Eclipse 3.1 with the class being made package-visible. </p> | ||
| 257 : | <p><b>Action required:</b> Any classes instantiating or extending <code>org.eclipse.ui.SelectionEnabler.SelectionClass</code> | ||
| 258 : | mcq | 1.28 | will need to be reworked to no longer refer to this class.</p> |
| 259 : | nick | 1.14 | |
| 260 : | darin | 1.16 | <h2><a name="ContributionItem.getParent"></a>11. ContributionItem.getParent() |
| 261 : | nick | 1.14 | can return null</h2> |
| 262 : | <p><b>What is affected:</b> Plug-ins that call <code>getParent()</code> on a subclass | ||
| 263 : | of <code>org.eclipse.jface.action.ContributionItem.</code></p> | ||
| 264 : | <p><b>Description:</b> In Eclipse 3.0, method <code>org.eclipse.jface.action.ContributionItem.getParent()</code> | ||
| 265 : | did not specify that it could return null. This was an oversight that has been | ||
| 266 : | addressed in Eclipse 3.1 with Javadoc for the method clarifying when it can | ||
| 267 : | return null. For more details, see bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=92777">92777</a>.</p> | ||
| 268 : | <p><b>Action required:</b> Any code calling <tt>ContributionItem.getParent()</tt> | ||
| 269 : | must ensure that it can handle a null result.</p> | ||
| 270 : | nick | 1.15 | |
| 271 : | darin | 1.16 | <h2><a name="IPropertySource.isPropertySet"></a>12. Changes to isPropertySet(boolean) |
| 272 : | nick | 1.15 | in IPropertySource and IPropertySource2</h2> |
| 273 : | <p><b>What is affected:</b> Plug-ins that implement <code>org.eclipse.ui.views.properties.IPropertySource</code> | ||
| 274 : | or <code>IPropertySource2.</code></p> | ||
| 275 : | <p><b>Description:</b> In Eclipse 3.0, the specification for the method <code>org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean)</code> | ||
| 276 : | was incorrectly changed to specify that true should be returned if the specified | ||
| 277 : | property did not have a meaningful default value. In previous versions, it specified | ||
| 278 : | that false should be returned in this case. This was an inadvertent breaking | ||
| 279 : | API change, although the implementation worked the same as before if the property | ||
| 280 : | source implemented <code>IPropertySource</code> and not <code>IPropertySource2</code>. | ||
| 281 : | This has been corrected in 3.1, with <code>IPropertySource.isPropertySet(boolean)</code> | ||
| 282 : | being reverted back to its earlier specification (that false should be returned | ||
| 283 : | in this case), and IPropertySource2.isPropertySet(boolean) overriding this to | ||
| 284 : | specify that true should be returned in this case. For more details, see bug | ||
| 285 : | <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21756 ">21756</a>.</p> | ||
| 286 : | <p><b>Action required:</b> Any classes implementing IPropertySource or IPropertySource2, | ||
| 287 : | where some of the properties do not have meaningful default values, should be | ||
| 288 : | checked to ensure that they return the appropriate value for isPropertySource(boolean). | ||
| 289 : | Clients should check that the Restore Default Value button in the Properties | ||
| 290 : | view works as expected for their property source.</p> | ||
| 291 : | acovas | 1.17 | |
| 292 : | <h2><a name="handlerSubmission"></a>13. handlerSubmission element | ||
| 293 : | deleted from the org.eclipse.ui.commands extension point</h2> | ||
| 294 : | <p><b>What is affected:</b> Plug-ins that used the experimental | ||
| 295 : | <code>handlerSubmission</code> element introduced into the | ||
| 296 : | <code>org.eclipse.ui.commands</code> extension point Eclipse 3.0. | ||
| 297 : | </p> | ||
| 298 : | <p><b>Description:</b> In Eclipse 3.0, an experimental element was introduced | ||
| 299 : | into the <code>org.eclipse.ui.commands</code> extension point. This element was | ||
| 300 : | intended as a way to register handlers through XML. Since then, a far superior | ||
| 301 : | mechanism, the <code>org.eclipse.ui.handlers</code> extension point, has been | ||
| 302 : | introduced. Since the element was marked as experimental, it has now been | ||
| 303 : | removed.</p> | ||
| 304 : | <p><b>Action required:</b> Any plug-ins defining a | ||
| 305 : | <code>handlerSubmission</code> element should migrate to the | ||
| 306 : | <code>org.eclipse.ui.commands</code> extension point.</p> | ||
| 307 : | |||
| 308 : | mvalenta | 1.19 | <h2><a name="teamUI"></a>14. Static non-final API field GLOBAL_IGNORES_CHANGED |
| 309 : | in TeamUI made final</h2> | ||
| 310 : | <p><b>What is affected:</b> Plug-ins that were setting the GLOBAL_IGNORES_CHANGED | ||
| 311 : | field of TeamUI.</p> | ||
| 312 : | <p><b>Description:</b> In Eclipse 3.0, the GLOBAL_IGNORES_CHANGED field was added | ||
| 313 : | to the TeamUI class. This field is a constant that is used in a property change | ||
| 314 : | johna | 1.30 | event to indicate that the list of global ignores maintained by the Team plug-in |
| 315 : | mvalenta | 1.19 | has changed. This field was not marked final in 3.0 but should have been. It |
| 316 : | has been made final in 3.1.</p> | ||
| 317 : | <p><b>Action required:</b> Any plugins that were setting the above field can no | ||
| 318 : | longer do so.</p> | ||
| 319 : | bbiggs | 1.25 | |
| 320 : | <h2><a name="FillData"></a>15. ClassCastException using FillLayout</h2> | ||
| 321 : | <p><b>What is affected:</b> Plug-ins that incorrectly use FillLayout.</p> | ||
| 322 : | <p><b>Description:</b> In Eclipse 3.0, no layout data was associated with | ||
| 323 : | the FillLayout and if an application assigned layout data to a child that was | ||
| 324 : | managed by a FillLayout, it was ignored. In Eclipse 3.1, support was added to | ||
| 325 : | FillLayout to cache size information in order to improve resize performance. | ||
| 326 : | The cached data is stored in a FillData object associated with each child | ||
| 327 : | managed by the FillLayout. If an application has incorrectly assigned | ||
| 328 : | layout data to a child, a ClassCastException will be thrown when computeSize | ||
| 329 : | is called on the parent.</p> | ||
| 330 : | <p><b>Action required:</b> Find any children in a FillLayout that have layout | ||
| 331 : | data assigned and stop assigning the layout data.</p> | ||
| 332 : | |||
| 333 : | <h2><a name="DisposedParent"></a>16. IllegalArgumentException thrown creating a | ||
| 334 : | widget with a disposed parent</h2> | ||
| 335 : | mcq | 1.28 | <p><b>What is affected:</b> Plug-ins that catch exceptions while creating widgets.</p> |
| 336 : | bbiggs | 1.25 | <p><b>Description:</b> In Eclipse 3.0, if a widget was created with a disposed |
| 337 : | parent, no exception was thrown and the widget code failed at a later point or | ||
| 338 : | an SWTException with text "Widget Is Disposed" was thrown. In Eclipse 3.1, | ||
| 339 : | if a widget is created with a disposed parent, the constructor will throw an | ||
| 340 : | mcq | 1.28 | IllegalArgumentException with text "Argument not valid".</p> |
| 341 : | bbiggs | 1.25 | <p><b>Action required:</b>Any code that handles the SWTException when creating |
| 342 : | mcq | 1.28 | a widget will also need to handle the IllegalArgumentException.</p> |
| 343 : | bbiggs | 1.25 | |
| 344 : | nick | 1.12 | <p> </p> |
| 345 : | tod | 1.21 | |
| 346 : | johna | 1.1 | </body> |
| 347 : | mcq | 1.28 | </html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |