development/readme_eclipse_2_1.html

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

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Eclipse Project Release Notes 2.1.0</title>
</head>

<body>

<h1>Eclipse Project Release Notes</h1>
<p>Release 2.1.0<br>
 March 27, 2003</p>
<p align="left"><strong>This software is OSI Certified Open Source Software.<br>
OSI Certified is a certification mark of the Open Source Initiative.&nbsp;</strong></p>
<blockquote>
  <p align="left"><a href="#Target Operating Environments">1. Target Operating
  Environments</a><br>
  <a href="#Compatibility with Previous Release">2. Compatibility with Previous Releases</a><br>
  <a href="#Known Issues">3. Known Issues</a><br>
  <a href="#Running Eclipse">4. Running Eclipse</a><br>
  <a href="#Upgrading">5. Upgrading a Workspace from a Previous Release</a><br>
  <a href="#Interoperability with Previous Releases">6. Interoperability with Previous Releases</a><br>
  </p>
</blockquote>
<h2>1. <a name="Target Operating Environments"></a> Target Operating
Environments</h2>
<p>Most of the Eclipse SDK is &quot;pure&quot; Java code and has no direct
dependence on the underlying operating system. The chief dependence is therefore
on the Java 2 Platform itself. Like the 2.0 release, the 2.1 release of the
Eclipse Project is written and compiled against version 1.3 of the Java 2
Platform APIs, and targeted to run on either version 1.3 or 1.4 of the Java 2
Runtime Environment, Standard Edition.</p>
<p>Eclipse SDK 2.1 has been tested and validated on the following Java 2
Platform implementations:</p>
<table width="91%" border="1">
  <tbody>
    <tr>
      <td width="21%"><b>Operating system</b></td>
      <td width="18%"><b>Processor architecture</b></td>
      <td width="73%"><b>Java 2 Platforms</b></td>
    </tr>
    <tr>
      <td width="21%" rowspan="4">Microsoft<br>
        Windows</td>
      <td width="18%" rowspan="4">Intel x86</td>
      <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for
        Microsoft Windows</td>
    </tr>
    <tr>
      <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for
        Microsoft Windows</td>
    </tr>
    <tr>
      <td width="73%">IBM Developer Kit for Windows, Java 2 Technology Edition,
        version 1.3.1 SR-2</td>
    </tr>
    <tr>
      <td width="73%">IBM 32-bit SDK for Windows, Java 2 Technology Edition,
        version 1.4.0</td>
    </tr>
    <tr>
      <td width="21%" rowspan="3">Linux</td>
      <td width="18%" rowspan="3">Intel x86</td>
      <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for
        Linux x86</td>
    </tr>
    <tr>
      <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for
        Linux x86</td>
    </tr>
    <tr>
      <td width="73%">IBM Developer Kit for Linux, Java 2 Technology Edition,
        version 1.3.1 SR-2</td>
    </tr>
    <tr>
      <td width="21%" rowspan="2">Sun Solaris</td>
      <td width="18%" rowspan="2">SPARC</td>
      <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for
        Solaris SPARC</td>
    </tr>
    <tr>
      <td width="73%">Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for
        Solaris SPARC</td>
    </tr>
    <tr>
      <td width="21%">HP HP-UX</td>
      <td width="18%">hp9000 PA-RISC</td>
      <td width="73%"><span class="header">HP-UX SDK for the Java 2 platform,
        version 1.3.1 for hp9000 PA-RISC</span></td>
    </tr>
    <tr>
      <td width="21%">IBM AIX</td>
      <td width="18%">PowerPC</td>
      <td width="73%">IBM Developer Kit for AIX, Java 2 Technology Edition,
        version 1.3.1</td>
    </tr>
    <tr>
      <td width="21%" rowspan="2">Apple Mac OS</td>
      <td width="18%" rowspan="2">PowerPC</td>
      <td width="73%">Java 2 Platform, Standard Edition, version 1.3.1 for Mac
        OS X</td>
    </tr>
    <tr>
      <td width="73%">Java 2 Platform, Standard Edition, version 1.4.1 for Mac
        OS X</td>
    </tr>
    <tr>
      <td width="21%"><span class="title">QNX
        Neutrino RTOS</span></td>
      <td width="18%">Intel x86</td>
      <td width="73%">IBM J9 VM for QNX, version 2.0</td>
    </tr>
  </tbody>
</table>
<p><span class="header">The following table describes the combinations of
operating system and Java 2 Platform used when testing the Eclipse SDK
configurations. The status column indicates the level of testing:
&quot;Primary&quot; means a full tested configuration; &quot;</span>Secondary&quot;
means a configuration which is only lightly tested; &quot;Untested&quot; means a
configuration that has received no testing, but which should work. Note that the
Mac OS X configuration is considered early access for the 2.1 release; it has
been tested, but is not product quality in this release.</p>
<table width="91%" border="1" height="415">
  <tbody>
    <tr>
      <td width="11%" height="32"><b>Window system</b></td>
      <td width="28%" height="32"><b>Java 2 Platform<br>
        (see above table)</b></td>
      <td width="42%" height="32"><b>Operating Environment</b></td>
      <td width="19%" height="32"><b>Testing Status</b></td>
    </tr>
    <tr>
      <td width="11%" rowspan="5" height="104">Win32</td>
      <td width="28%" rowspan="5" height="104">Windows on Intel x86</td>
      <td width="42%" height="16">Windows XP</td>
      <td width="19%" height="16">Primary</td>
    </tr>
    <tr>
      <td width="42%" height="16">Windows 2000</td>
      <td width="19%" height="16">Primary</td>
    </tr>
    <tr>
      <td width="42%" height="16">Windows ME</td>
      <td width="19%" height="16">Secondary</td>
    </tr>
    <tr>
      <td width="42%" height="16">Windows 98SE</td>
      <td width="19%" height="16">Secondary</td>
    </tr>
    <tr>
      <td width="42%" height="16">Windows NT</td>
      <td width="19%" height="16">Secondary</td>
    </tr>
    <tr>
      <td width="11%" rowspan="6" height="152">Motif</td>
      <td width="28%" rowspan="3" height="86">&nbsp;
        <p>Linux on Intel x86</p>
        <p>&nbsp;</p>
      </td>
      <td width="42%" height="25">RedHat Linux 8.0 x86</td>
      <td width="19%" height="25">Primary</td>
    </tr>
    <tr>
      <td width="42%" height="25">SuSE Linux 8.1 x86</td>
      <td width="19%" height="25">Primary</td>
    </tr>
    <tr>
      <td width="42%" height="24">Other Linux; kernel version 2.4.7, and XFree86
        version 4.1.0</td>
      <td width="19%" height="24">Untested</td>
    </tr>
    <tr>
      <td width="28%" height="16">Solaris on SPARC&nbsp;</td>
      <td width="42%" height="16">Sun Solaris 8 SPARC</td>
      <td width="19%" height="16">Primary</td>
    </tr>
    <tr>
      <td width="28%" height="16">HP-UX on hp9000 PA-RISC</td>
      <td width="42%" height="16">HP-UX 11i hp9000</td>
      <td width="19%" height="16">Primary</td>
    </tr>
    <tr>
      <td width="28%" height="16">AIX on PowerPC</td>
      <td width="42%" height="16">IBM AIX 5.1 on PowerPC</td>
      <td width="19%" height="16">Primary</td>
    </tr>
    <tr>
      <td width="11%" rowspan="4" height="81">GTK</td>
      <td width="28%" rowspan="4" height="81">Linux on Intel x86</td>
    </tr>
    <tr>
      <td height="15">RedHat Linux 8.0 x86 (GTK 2.2 required for DBCS)</td>
      <td height="15">Primary</td>
    </tr>
    <tr>
      <td width="42%" height="16">SuSE Linux 8.1 x86 (Latin-1 only)</td>
      <td width="19%" height="16">Primary</td>
    </tr>
    <tr>
      <td width="42%" height="16">Other Linux; GTK 2.0.6 (GTK 2.2 required for
        DBCS)</td>
      <td width="19%" height="16">Untested</td>
    </tr>
    <tr>
      <td width="11%" height="16">Carbon</td>
      <td width="28%" height="16">Mac OS X on PowerPC</td>
      <td width="42%" height="16">Mac OS X 10.2</td>
      <td width="19%" height="16"><i>Early access</i></td>
    </tr>
    <tr>
      <td width="11%" height="16">Photon</td>
      <td width="28%" height="16">IBM J9 VM for QNX</td>
      <td width="42%" height="16">QNX Neutrino RTOS 6.2.1&nbsp;</td>
      <td width="19%" height="16">Primary</td>
    </tr>
  </tbody>
</table>
<h4>Internationalization</h4>
<p>The Eclipse Platform is designed as the basis for internationalized products.
The user interface elements provided by the Eclipse SDK components, including
dialogs and error messages, are externalized. The English strings are provided
as the default resource bundles.</p>
<p>Latin-1 locales are supported by the Eclipse SDK on all of the above
operating environments; DBCS locales are supported by the Eclipse SDK on the
Windows, GTK, and Motif window systems; BIDI locales are supported by the
Eclipse SDK only on Windows operating environments.
<p>The Eclipse SDK supports GB 18030, the new Chinese code page standard, on
Windows 2000 and XP, and Linux. Note, however, that GB 18030 also requires
locale and character encoding support from the Java 2 Runtime Environment; this
support is standard in version 1.4, and also available in some 1.3 JREs.
<p>German and Japanese locales have been tested.
<h4>BIDI support</h4>
<p>The Eclipse SDK is a development environment targeted at technical
professionals - not an end user application. However, the Eclipse SDK tools will
permit technical professionals who are working in English to build Hebrew/Arabic
end user Java programs which are themselves not based on the Eclipse SDK. The
BIDI support in the Eclipse SDK allows a Java programmer to work with BIDI
strings, code comments, etc. but the Eclipse SDK itself is not designed to be
localized for BIDI locales and its widget orientation cannot be changed.</p>
<p><i>IMPORTANT: The above BIDI support is available only for Windows operating
environments.</i></p>

<h2>2. <a name="Compatibility with Previous Release"></a> Compatibility with
Previous Releases</h2>
<h3>Compatibility of Release 2.1 with 2.0</h3>
Eclipse SDK 2.1 is intended to be upwards compatible with Eclipse SDK 2.0. We
have made exceptions only in areas where slavishly maintaining compatibility
would not be in the best interests of Eclipse or its clients. The exceptions are
noted in the next section.
<p><b>API Contract Compatibility:</b> Eclipse SDK 2.1 is upwards
contract-compatible with Eclipse SDK 2.0 except as noted in the next section.
This means that programs in full compliance with contracts specified in Eclipse
SDK 2.0 APIs is automatically in full compliance with Eclipse SDK 2.1 APIs. (API
is construed broadly to include such things as plug-in extension points.)
Downward contract compatibility is not supported. There is no guarantee that
compliance with Eclipse SDK 2.1 APIs ensures compliance with Eclipse SDK 2.0
APIs. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that
maintain contract compatibility.</p>
<p><b>Binary (plug-in) Compatibility:</b> Eclipse SDK 2.1 is upwards
binary-compatible with Eclipse SDK 2.0 except as noted in the next section. This
means that plug-ins built for Eclipse SDK 2.0 will continue to work correctly in
Eclipse SDK 2.1 without change. Downward plug-in compatibility is not supported.
Plug-ins for Eclipse SDK 2.1 are unlikely to be usable in Eclipse SDK 2.0.
Plug-ins with hard-coded references in their plug-in manifest file to 2.0
versions of prerequisite Eclipse Project plug-ins will work in 2.1 provided the
version match rule is &quot;greaterOrEqual&quot; or &quot;compatible&quot; (the
default); references using &quot;perfect&quot; or &quot;equivalent&quot; match
rules will be broken. Refer to <i><a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that
maintain binary compatibility.
<p><b>Source Compatibility:</b> Eclipse SDK 2.1 is upwards source-compatible
with Eclipse SDK 2.0 except as noted in the next section. This means that source
files written to use Eclipse SDK 2.0 APIs can be successfully compiled and run
against Eclipse SDK 2.1 APIs. Since source incompatibilities are easy to deal
with, maintaining source compatibility is considered much less important than
maintaining contract and binary compatibility. Downward source compatibility is
not supported. If source files use new Eclipse SDK APIs, they will not be usable
with an earlier version of Eclipse SDK.
<p><b>Workspace Compatibility:</b> Eclipse SDK 2.1 is upwards
workspace-compatible with Eclipse SDK 2.0 except as noted in the next section.
This means that workspaces and projects created with Eclipse SDK 2.0 can be
successfully opened by Eclipse SDK 2.1 and upgraded to a 2.1 workspace.&nbsp;
This includes both hidden metadata, which is localized to a particular
workspace, as well as metadata files found within a workspace project (e.g., the
.project file), which may propagate between workspaces via file copying or team
repositories. Individual plug-ins developed for Eclipse SDK 2.1 should provide
similar upwards compatibility for their hidden and visible workspace metadata
created by earlier versions; 2.1 plug-in developers are responsible for ensuring
that their plug-ins recognize both 2.1 and 2.0 metadata and process it
appropriately. User interface session state may be discarded when a workspace is
upgraded. Downward workspace compatibility is not supported. A workspace created
(or opened) by Eclipse SDK 2.1 will be unusable with an earlier version of
Eclipse SDK. Visible metadata files created (or overwritten) by Eclipse SDK 2.1
will generally be unusable with earlier versions of Eclipse SDK.&nbsp;
<p><b>Non-compliant usage of API's</b>: All non-API methods and classes, and
certainly everything in a package with &quot;internal&quot; in its name, are
considered implementation details which may vary between operating environment
and are subject to change without notice. Client plug-ins that directly depend
on anything other than what is specified in the Eclipse SDK API are inherently
unsupportable and receive no guarantees about compatibility within a single
release much less with earlier releases. Refer to <i><a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">How
to Use the Eclipse API</a></i> for information about how to write compliant
plug-ins.</p>


<h3>2.1 Incompatibilities between release 2.1 and 2.0</h3>
<p>Eclipse 2.1 breaks compatibility with Eclipse 2.0 in the following areas.</p>
<p>Note: Bug numbers refer to the Eclipse project bug database at <a href="http://dev.eclipse.org/bugs/">http://dev.eclipse.org/bugs/</a></p>
<h3>Platform - Core</h3>
<h4>Linked resources</h4>
<p>Eclipse 2.1 allows a project in the workspace to bring together contents from
several different directories on disk using what are termed linked folders and
files. The presence of linked resources changes a fundamental assumption true
for earlier versions of Eclipse, namely, that all of a project's files are
located under the project's root directory in the local file system.
Furthermore, the target of a linked resource is allowed to overlap that of
another linked resource, or overlap the root directory of any project. This new
potential for overlap means that several distinct files in the workspace might
map to the same file in the local file system. In 2.0, there was no way for
overlap to happen (project root directories are not allowed to overlap).</p>
<p>These changes have several ramifications at the API:</p>
<ul>
  <li><code>IResource.getLocation</code> can return <code>null</code> in more
    cases than before.</li>
  <li><code>IWorkspaceRoot.getContainerForLocation</code> and <code>getFileForLocation</code>
    are no longer sufficient to map from file system path to workspace path in
    the presence of linked resources, as these calls do not account for linked
    files or files under linked folders. Two new methods were added to handle
    the possibility of overlap: <code>IWorkspaceRoot.findContainersForLocation</code>
    and <code>findFilesForLocation</code>.</li>
</ul>
<p>Since linked resources and their children appear in the workspace as normal
files and folders, client code that works exclusively with the workspace
resource tree is not affected. The clients most likely to be impacted are ones
that assume that all of a project's files are located together in the local file
system under the project's root directory. For example, an export utility that
works directly on the local file system might miss some of a project's files if
it only looks within the project's root directory.</p>
<p>This change was made to give certain kinds of users greater flexibility in
laying out their projects on disk. The behavior of existing plug-ins is
unchanged from 2.0 for projects that do not use linked resources. Depending on
the assumptions made, existing plug-ins might misbehave or fail for projects
containing linked resources. A plug-in can prohibit linked resources for a
project via a project nature (<code>IProjectNatureDescriptor.isLinkingAllowed()</code>),
but this should only be done where there is a good reason to deny the user this
additional flexibility in laying out a project. Users can disable linked resources
via the <b>Workbench &gt; Linked
    Resources</b> preference page. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=6664">6664</a>)</p>
<h4>Project build order</h4>
<p>The default order in which projects get built was changed in Eclipse 2.1 to
improve the handling of mutually-dependent projects. The old method <code>IWorkspace.computePrerequisiteOrder</code>
was deprecated and replaced by <code>IWorkspace.computeProjectOrder</code>.
Since there are few potential clients of either method beyond the Eclipse
Platform itself, it's unlikely that clients will be affected. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=10262">10262</a>,
<a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=25952">25952</a>)</p>
<h3>Platform - UI</h3>
<h4>Restructuring of UI plug-ins</h4>
<p>In Eclipse 2.1, the API and code for the <code>org.eclipse.ui</code> plug-in
was partitioned and parceled out to several new plug-ins (<code>org.eclipse.jface</code>,
<code>org.eclipse.text</code>, and <code>org.eclipse.ui.workbench</code>, etc.).
Although this looks on the surface to be a breaking change, it is not. These new
plug-ins are internal and should not be referenced explicitly. As they always
have, plug-ins requiring the Eclipse Platform UI (API found in the <code>org.eclipse.swt.*</code>,
<code>org.eclipse.jface.*</code>, and <code>org.eclipse.ui.*</code> packages)
should continue to state a dependency on the <code>org.eclipse.ui</code>
 plug-in.</p>
<h3>Platform - Help</h3>
<h4>Pluggable app server</h4>
<p>Eclipse 2.0 provided interim support for pluggable app servers via an
undocumented <code>org.eclipse.help.app-server</code> extension point, with
interim APIs in the <code>org.eclipse.help</code> package. For 2.1, this support
has been made internal, along with the former interim API classes. Because this
support was marked as interim for 2.0, this is not considered a breaking API change.
Nevertheless, existing clients using the interim support will be broken. Even
though the mechanism is not officially supported, clients that are adamant about
plugging in a different app server can do so (with all the usual risks of
depending on unsupported Eclipse internals).</p>
<h4>Pluggable web browser</h4>
<p>Eclipse 2.0 provided interim support for pluggable web browsers via the <code>org.eclipse.help.ui.browser</code>
extension point, with API in the <code>org.eclipse.help.ui.browser</code>
package. For 2.1, this support appears in finished form in different location:
the <code>org.eclipse.help.browser</code> extension point, with API in the <code>org.eclipse.help.browser</code>
package. Because this support was marked as interim for 2.0, this is not
considered a breaking API change. Nevertheless, existing clients using the interim support will
need to update the extension point and package names.</p>
<h3>Platform - Team</h3>
<b>
<p>Validate edit/save</p>
</b>
<p>There are some new restrictions that repository providers should be aware of
when implementing <code>validateSave/Edit</code>. The first is that the hook can
be invoked from a non-UI thread. The provider should use <code>Display.syncExec()</code>
if they are affecting any UI components. Also, the hook should not display a
progress monitor because there is a good possibility that there already is one
open for the operation being performed; opening another will cause deadlock.
(bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=33471">33471</a>)</p>
<b>
<p>Linked resources</p>
</b>
<p>The new support for linked folders and files added in Eclipse 2.1 impacts
repository providers because it changes some of the rules about relationships
between files in the workspace and their corresponding locations in the local
file system. All existing repository providers should be updated to handle
linked resources, as described in the 2.1 Team API. If
a project is shared via an older 2.0 repository provider, the user will be
prohibited from creating linked resources in that project. (bug
<a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=26469">26469</a>)</p>
<h3>Platform - SWT</h3>
<h4>Character field in key event</h4>
<p>The specification of the <code>Event.character</code> field now makes it
clear that the character reflects the outcome after any modifier keys are taken
into account (for example, CTRL+A is reduced to the ASCII equivalent character
with integer value 1). Since the treatment of modifier keys was completely
unspecified before, this change affects clients that make assumptions about how
modifiers are handled. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=33592">33592</a>)</p>
<h4>New key modifier: command</h4>
<p>In order to properly support the Mac for Eclipse 2.1, a new <code>SWT.COMMAND
</code>key modifier constant was added to represent the Apple command key. On
the Mac, the command key plays the same role as the control key plays elsewhere,
whereas the control key is used mainly as an additional mouse click modifier.
Clients that merely want to check for the appropriate primary modifier for the
OS should instead use the new bit mask <code>SWT.MOD1</code> in favor of either <code>SWT.CONTROL</code>
or <code>SWT.COMMAND</code>. The advent of the Mac port of Eclipse affects
existing clients that explicitly check for the <code>SWT.CONTROL</code>
modifier. In most cases, they should instead check for <code>SWT.MOD1</code> so
that they work appropriately on both Macs and non-Macs. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=24393">24393</a>)</p>
<h4>OLE variant type exceptions</h4>
<p>An <code>SWTError</code> exception is now thrown when a Java type is
requested from an empty variant type (<code>VT_EMPTY</code>). Since existing
clients should already be handling <code>SWTError</code> exceptions as per the
spec for <code>Variant.getInt()</code>, etc., this change should not affect
existing clients. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=24402">24402</a>)</p>
<h4>Multiple drag and drop adapters</h4>
<p>An <code>SWTError</code> exception is now thrown if you create a second <code>DragSource</code>
(or <code>DropTarget</code>) for a widget. Across various window systems, the
results of creating multiple drag source or drop target objects were at best
indeterminate. The exception makes it clear that this is not supported. Since
existing clients should already be handling <code>SWTError</code> exceptions as
per the spec for the <code>DragSource</code> and <code>DropTarget</code>
constructors, this change should not impact existing clients. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35214">35214</a>)</p>
<h3>Platform - Install/Update</h3>
<p>None.</p>
<h3>Platform - Ant</h3>
<p>None.</p>
<h3>Platform - Debug</h3>
<p>None.</p>
<h3>Platform - Search</h3>
<h4>Inexact matching</h4>
<p>There is a new preference setting that controls whether the search engine
should report inexact matches. The user can set this via the <b>Workbench &gt;
Search </b>preference page. The new API method <code>SearchUI.arePotentialMatchesIgnored</code>
should be used to query the preference setting. Existing clients that contribute
a particular search engine (or search page) should consider whether the notion
of an inexact match is meaningful in their particular context, and honor this
preference if it is. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20663">20663</a>)</p>
<h3>Platform - Text</h3>
<h4>File encoding preserved</h4>
<p><code>FileDocumentProvider</code> now saves a file in the encoding it has
been read rather than in the workbench's default encoding.</p>
<h4>Key binding scopes</h4>
<p>Clients should be aware of key binding scopes, which were introduced in 2.1. <code>TextEditor</code>
sets &quot;org.eclipse.ui.textEditorScope&quot; as its key binding scope.
Subclasses inherit this setting if they do not override &quot;initializeKeybindingScopes&quot;.
<code>AbstractTextEditor</code> does not set any key binding scopes; it leaves
this to its subclasses.</p>
<h4>Action definition ids are mandatory</h4>
<p>All actions registered with an instance of <code>AbstractTextEditor</code>
should have an action definition id. Otherwise they will not be accessible via
accelerators.</p>
<h4>Deprecated API</h4>
<p>The following class, methods, and constants have been deprecated. The Javadoc
indicates what should be used instead.</p>
<ul>
  <li>Package <code>org.eclipse.ui.texteditor</code>
    <ul>
      <li>Field <code>AbstractTextEditor.PREFERENCE_FONT</code>
      </li>
    </ul>
  </li>
  <li>Package <code>org.eclipse.jface.text.source</code>
    <ul>
      <li>Constructor <code>AnnotationBarHoverManager(ISourceViewer,
            IVerticalRuler, IAnnotationHover, IInformationControlCreator)</code>
      </li>
    </ul>
  </li>
  <li>Package <code>org.eclipse.jface.text.rules</code>
    <ul>
      <li>Constructor <code>DefaultDamagerRepairer(ITokenScanner,
            TextAttribute)</code>
      </li>
    </ul>
  </li>
  <li>Package <code>org.eclipse.jface.text.information</code>
    <ul>
      <li>Method <code>IInformationProvider.getInformation(ITextViewer, IRegion)</code>
      </li>
    </ul>
  </li>
  <li>Package <code>org.eclipse.ui.texteditor</code>
    <ul>
      <li>Constructor <code>IncrementalFindAction(ResourceBundle, String,
            IWorkbenchWindow, <b>boolean</b>)</code>
      </li>
      <li>Constructor <code>MarkerRulerAction(ResourceBundle, String,
            IVerticalRuler, ITextEditor, String, <b>boolean</b>)</code>
      </li>
      <li>Method <code>MarkerRulerAction.getVerticalRuler()</code>
      </li>
      <li>Constructor <code>SelectMarkerRulerAction(ResourceBundle, String,
            IVerticalRuler, ITextEditor)</code>
      </li>
    </ul>
  </li>
</ul>
<h3>Platform - Compare</h3>
<p>None.</p>
<h3>JDT - Core</h3>
<h4>Multiple output folders</h4>
<p>In Eclipse 2.0, all generated class files (and copied resource files) for a
Java project get written to the project's single output folder. As of 2.1, the
generated class files (and copied resource files) can be partitioned across
several output folders, with each source build path entry specifying which
output folder its generated files get written to. This change was made to give
certain kinds of users greater flexibility in laying out their Java projects on
disk. Clients used to be able to assume that a Java project's output files were
in the project's output folder (<code>IProject.getOutputLocation()</code>); now
they need to take into account the possibility of other output locations (<code>IClasspathEntry.getOutputLocation()!=null</code>). Existing code appears to work fine until the user exercises the
additional flexibility. This change is most likely to affect client code that
deploys code directly from the project's output folder (e.g., creates a JAR;
launches a Java VM with the output folder on the runtime class path). (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=24123">24123</a>)</p>
<h4>Source folder exclusion patterns</h4>
<p>In Eclipse 2.0, all Java source files under a source folder on a project's
build class path were compiled and included in the Java model. The notion of
exclusion patterns were added in 2.1 to give certain kinds of users greater
flexibility in laying out their Java projects on disk&nbsp; Exclusion patterns
associated with a source entry on the build class path (<code>IClasspathEntry.getExclusionPatterns()</code>)
cause matching files or subdirectories to be ignored for the purposes of
compilation and inclusion in the Java model. Most existing clients traverse the
Java model and will continue to work fine. However, clients that directly
traverse the corresponding source folder in the local file system need to take
into account the possibility that some of the files found there may have been
excluded with this new mechanism. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=22039">22039</a>)</p>
<h4>Code formatter positions</h4>
<p>The specification for <code>ICodeFormatter.format</code> was changed to
specify that the positions array passed in must be in non-decreasing order. The
implementation had always been making this assumption, and there would have been
serious performance consequences to specify the method as working with unordered
positions. Existing clients are unlikely to be affected. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=30417">30417</a>)</p>
<h4>Leading comments on AST Statement nodes</h4>
<p><code>Statement.getLeadingComment</code> and <code>setLeadingComment</code>
have been deprecated because they were not a particularly good way to deal with
the general issue of comments and significant whitespace. Since the
implementations of <code>AST.parseCompilationUnit</code> never set the leading
comment for any AST nodes they create, the change is moot for most clients. (bug
<a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=29176">29176</a>)</p>
<h4>Empty array passed to Java model operation</h4>
<p>In Eclipse 2.0, certain Java model API operations (<code>IJavaModel.delete</code>,
<code>copy</code>, <code>move</code>, and <code>rename</code>) threw an <code>ArrayIndexOutOfBoundsException</code>
if passed an empty array. The behavior in this case was completely unspecified.
For 2.1, the specification and implementation of these operations have been
changed to throw <code>JavaModelException</code> in such cases. Clients need to
be aware that the empty array case does indeed trigger an exception. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=32219">32219</a>)</p>
<h4>Non-Java projects included in Java model&nbsp;</h4>
<p>In Eclipse 2.0, non-Java projects and closed projects were excluded from the
Java model. In 2.1, non-Java projects and closed projects are available from the
Java model via <code>IJavaModel.getNonJavaResources</code>. Their inclusion in
the Java model means that they appear in Java model deltas, under <code>IJavaElementDelta.getResourceDeltas</code>.
This change may affect clients that listen for Java element deltas (via <code>JavaCore.addElementChangedListener</code>)
if they make overly strong assumptions about triggering conditions and contents.
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=29274">29274</a>)</p>
<h4>Java element changed events for full working copy lifecycle</h4>
<p>In Eclipse 2.0, Java element changed events were reported for changes to
shared working copies, but not when they were created or destroyed. In 2.1, Java
element changed events are uniformly issued for the full lifecycle of working
copies and apply equally to non-shared as well as shared working copies. This
change may affect clients that listen for Java element deltas (via <code>JavaCore.addElementChangedListener</code>)
if they make overly strong assumptions about triggering conditions and contents.
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=32981">32981</a>)</p>
<h4>IJavaProject.isOnClasspath</h4>
<p>For Eclipse 2.1, the API predicate <code>IJavaProject.isOnClasspath</code>
(both forms) was changed to do the more standard thing of returning false rather
than throwing <code>JavaModelException</code> in some cases. While this change
is within the original spirit of the original API&nbsp; contract, it breaks
source compatibility because <code>JavaModelException</code> is a checked
exception; code that invokes this method and catches <code>JavaModelException</code>
may need to be rewritten. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=33754">33754</a>)</p>
<h3>JDT - UI</h3>
<p>None.</p>
<h3>PDE</h3>
<p>None.</p>


<h2>3. <a name="Known Issues"></a>  Known Issues</h2>
<blockquote>
  <p><a href="#I-Platform">3.1 Platform</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Core">3.1.1 Core</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Ant">3.1.2 Ant</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Help">3.1.3 Help</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - UI">3.1.4 UI</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Text">3.1.5 Text</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - SWT">3.1.6 SWT</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Team - CVS">3.1.7 Team</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Install/Update">3.1.8
  Install/Update<br>
  </a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Platform - Debug">3.1.9 Debug<br>
  </a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Java Development Tools (JDT)">3.1.10 Compare<br>
  3.2 Java Development Tools (JDT)<br>
  3.3 Plug-in Development Environment (PDE)</a><br>
  <a href="#I-Other - FTP and WebDAV support">3.4 Other<br>
  </a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="#I-Other - FTP and WebDAV support">3.4.1
  FTP and WebDAV support</a></p>
</blockquote>
<p>Note: Bug numbers refer to the Eclipse project bug database at <a href="http://dev.eclipse.org/bugs/">http://dev.eclipse.org/bugs/</a></p>
<h3>3.1 <a name="I-Platform">Platform</a></h3>
<h4>DBCS support on Linux GTK (Linux GTK only)</h4>
<p>The versions of GTK included with RedHat Linux 8.0 and SuSE Linux 8.1 that we
tested support Latin-1 locales but not DCBS. The DCBS support in GTK 2.2 should
be sufficient, and in principle Eclipse should work on any recent Linux with GTK
2.2. We have verified that Eclipse DBCS support works with RedHat Linux 8.0 and
GTK 2.2. However, we were unable to get Eclipse working with SuSE Linux 8.1 and
and GTK 2.2, so this remains an open issue.</p>
<h4>Eclipse process does not exit (HP-UX only)</h4>
<p>On HP-UX, the HP JVM process that runs the Eclipse Workbench does not
terminate upon closing the workbench. The remedy is to always pass the <code>-XdoCloseWithReadPending</code>
to the VM via the Eclipse launcher command line; that is, launch Eclipse with
the command line:</p>
<blockquote>
  <p><code>eclipse -vmargs -XdoCloseWithReadPending</code></p>
</blockquote>
<p>(bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=18321">18321</a>)</p>
<h3>3.1.1 <a name="I-Platform - Core">Platform - Core</a></h3>
<h4>Declaring package name prefixes improves plug-in class loading speed</h4>
<p>A significant (10-15%) speed increase in the time to load a plug-in's classes
can be obtained simply by declaring the package name prefixes found in that
plug-in's runtime library JARs. This is done in the new Package Prefixes section
of the Runtime page in the PDE plug-in manifest editor. (Further information <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core-home/docs/package-prefixes/prefixes.html">here</a>.)</p>
<h4><b>Invalid characters in install directory prevents Eclipse from starting</b></h4>
<p>Eclipse will fail to launch if installed in a directory whose path contains
certain invalid characters, including :%#&lt;&gt;&quot;!. The workaround is to
install Eclipse in a directory whose path does not contain invalid characters.
(bugs <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=3109">3109</a> and <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=17281">17281</a>)</p>
<h4><b>Problems with classloaders in created threads</b></h4>
<p>There is a known issue with trying to load classes from a newly-created
thread using a class loader different from the plug-in class loader. The result
will be a <code>ClassNotFoundException</code>. As a workaround, do the
following:</p>
<ol>
  <li>Create a thread in which to run your code.</li>
  <li>Send yourThread.setContextClassLoader(yourClassLoader); // you can find
    your classloader by grabbing a class it loaded (YourPluginClass.class.getClassLoader())</li>
  <li>Run your code in the newly created thread.</li>
</ol>
<p>If you set the context class loader for the current thread, you are competing
with other users of the thread (all of Eclipse), so the results will be
unpredictable. However, there should be no problem in practice provided you
reset the context class loader back to its original value when your use in the
current thread is&nbsp;complete. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=8907">8907</a>)</p>
<h4>Deadlock creating executable extension in Plugin.startup</h4>
<p>If <code>Plugin.startup</code> code is too complex and performs tasks such as
creating an executable extension, a deadlock situation can be created. Only
simple bookkeeping tasks should be performed in <code>Plugin.startup</code>
code. (bugs <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=12827">12827</a>,
<a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=5875">5875</a>, <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=16141">16141</a>)</p>
<h3>3.1.2 <a name="I-Platform - Ant">Platform - Ant</a></h3>
<h4>Xerces JARs no longer required on runtime Ant classpath</h4>
<p>Explicitly adding the Xerces JARs to the runtime Ant classpath is no longer
required and can cause problems. The Xerces classes are loaded from the <code>org.apache.xerces</code>
plug-in provided with Eclipse. For most Ant
distributions, the Xerces JARs cannot even be in the same physical location as
the <code>ant.jar</code> and <code>optional.jar</code>. This results from the
Ant JARs containing manifest files which contain classpath entries pointing to
the Xerces JARs. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33664">33664</a>,
<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33117">33117</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=34151">34151</a>)</p>
<h4>Custom Ant tasks and Ant types must be separate from plug-in library JARs</h4>
<p>Including the class files for custom Ant tasks or Ant types in the regular
code JAR for your plug-in causes problems. These class files must be provided in
a separate JAR that is contributed to the <code>org.eclipse.ant.core.antTasks</code>
or <code>antTypes</code> extension point (and not declared as a library in the
plug-in's manifest). This ensures that the Ant tasks and types are loaded by the
special Ant class loader and not by a plug-in classloader. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=34466">34466</a>).</p>
<h4>Concurrent Ant builds not supported</h4>
<p>Eclipse runs Ant in the same JVM as the rest of Eclipse. Several aspects of
Ant and its use of global Java resources (such as System.out and System.err),
make it unsafe to run more than one Ant build concurrently. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=24129">24129</a>).</p>
<h4>Running certain Ant tasks cause memory leakage</h4>
<p>Certain Ant tasks are known to leak memory. Please see the bug report for
details, patches, and possible workarounds. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=24448">24448</a>)</p>
<h4>Tasks that require input lock up workspace</h4>
<p>As with using Ant from the command line, prompts for input from the console
is not handled. This is not the same as making use of the &lt;input&gt; task,
which works correctly within Eclipse. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=21748">21748</a>)</p>
<h4>Ant Editor code completion based on Ant 1.5</h4>
<p>Code completion provided by the Ant editor does not respect the
user-specified version of <code>org.eclipse.ant.core</code> plug-in or ANT_HOME.
Code completion proposals are always based on Ant 1.5. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=30886">30886</a>).</p>
<h3>3.1.3 <a name="I-Platform - Help">Platform - Help</a></h3>
<h4>Help documents not displayed in a browser or very slow
document loading (Windows only)</h4>
If your LAN settings are not properly configured for local
host access, your Help browser might open to a blank page or display an HTTP
error instead of a help page, or you may experience long delays when loading
help documents. Your system administrator can configure your LAN settings so
that help documents can be accessed from the local help server.
<blockquote>
  <ol>
    <li>In the Control Panel, open <b>Internet Options</b>,
      select the <b>Connections</b> tab and choose <b>LAN Settings</b>.</li>
    <li>If your host was configured to use DHCP for IP
      assignment, make sure that the &quot;Automatically detect settings&quot;
      check box is cleared.</li>
    <li>If you use a proxy server, ensure that the
      &quot;Bypass proxy server for local addresses&quot; is selected.</li>
    <li>In &quot;Advanced&quot; settings for proxies, add
      &quot;127.0.0.1;localhost&quot; to the &quot;Exceptions&quot; if these
      addresses are not listed.</li>
    <li>If you are using an automatic configuration script
      for proxy settings, and are not sure that the script is correct, clear the
      &quot;Use automatic configuration script&quot; check box.</li>
  </ol>
</blockquote>
<p>If the above steps do not fix your problem, try
changing the port and host properties on the <b>Help &gt; Help Server</b>
preference page. In general, setting <code>host</code> to <code>localhost</code>
or <code>127.0.0.1</code> should work. Also, especially when running a firewall,
you may want to specify port 80 or some other firewall-friendly value. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=7036">7036</a>,
<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=9418">9418</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=11394">11394</a>)</p>
<h4>Working disconnected from the network (Windows only)</h4>
If you are experiencing problems when not connected to the
network, you must install the loopback adapter from the Windows installation CD.
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=831">831</a>)
<h4>Using Internet Explorer in offline mode (Windows only)</h4>
If you have been using Internet Explorer in Offline mode,
when you access the help system you will get a message indicating that the web
page you requested is not available offline or a blank page will display. Click <b>Connect</b>
or deselect &quot;Work Offline&quot; in the Internet Explorer &quot;File&quot;
menu to return the system behavior to normal.
<h4>Using the custom browsers (Unix and Linux only)</h4>
<p>On Unix and Linux, when using the Custom Browser setting on the Help
preference page, ensure that the program you select is not enclosed by double
quotes (&quot;), and that the program path does not contain spaces. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35673">35673</a>)</p>
<h3>3.1.4 <a name="I-Platform - UI">Platform - UI</a></h3>
<h4>Minimum display resolution</h4>
<p>A number of dialogs in Eclipse, such as the Preferences
dialog, require a minimum display resolution of at least 1024 x 768.</p>
<h4>Manual refresh required when files modified outside
Eclipse</h4>
<p>When files within a project are added or removed
outside of Eclipse, or when an external editor is used to modify a file within a
project, a manual refresh must be done in order for the changes to show up in
the Workbench. To do this, select the project in the Navigator view and choose <b>Refresh</b>
from the pop-up menu. This refreshes only the selected project. Alternatively,
activate the Navigator view and press F5, which refreshes all projects.</p>
<h4>Default text file encoding may be detected incorrectly
(Windows XP/2000 only)</h4>
<p>The &quot;Text file encoding&quot; value displayed in
the Preferences dialog under &quot;Editors&quot; may be wrong on platforms
running Windows XP (or 2000) when the user locale and system locale
differ.&nbsp;</p>
<p>Example of the manifestation of the bug: A Japanese
user using Japanese Windows 2000 works in New York, United States. The user has
selected English (United States) as the user locale. The &quot;Text file
encoding&quot; value displayed by Eclipse is incorrect: &quot;Cp1252&quot;
(English). It should display the system locale &quot;MS932&quot; (Japanese).</p>
<p>Workaround: The user can modify the user locale so that
user locale and system locale are identical. In the example above, this means
the user should set Japanese as the user locale. Then restart Eclipse. The
&quot;Text file encoding&quot; value will then be correct: &quot;MS932&quot;
(Japanese).</p>
<p>For Windows XP:</p>
<ul>
  <li>To check the system locale: Open the Control Panel.
    Go to Regional and Language Options. Switch to the Advanced tab. The system
    locale is specified in &quot;Language for non-Unicode programs&quot;.</li>
  <li>To change the user locale: Open the Control Panel.
    Go to Regional and Language Options. The user locale can be modified by
    changing the language in &quot;Standards and formats&quot;.</li>
</ul>
<p>For Windows 2000:</p>
<ul>
  <li>To check the system locale: Open the Control Panel.
    Go to Regional Options. Look up the items in the General tab, inside the
    &quot;Language settings for the system&quot; group. The system locale is the
    item marked as (Default).</li>
  <li>To change the user locale: Open the Control Panel.
    Go to Regional Options. The user locale can be modified by changing the
    location in &quot;Settings for the current user&quot;.</li>
</ul>
<p>(bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=20641">20641</a>)</p>
<h4>External Tools will automatically quote path variables containing spaces</h4>
<p>When an external tool is launched, expanded path variables that contain
spaces will be enclosed in double quotes ( &quot; ). While it is typical for
Windows executables to expect paths containing spaces to be quoted, this is
known to cause problems on platforms such as Linux which do not expect these
quotes. A workaround is to make the external tool a script which strips off the
quotes before launching the executable with those parameters. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=20599">20599</a>)</p>
<h4>KDE takes Ctrl+Fn keys</h4>
<p>When using the KDE desktop on Linux systems, the Ctrl+Fn key sequences are
used for switching between virtual desktops. This means that Eclipse commands
bound to these key sequences do not get activated, including Ctrl+F1 (Help),
Ctrl+F4 (File &gt; Close) and Ctrl+F6 (Next Editor).</p>
<p>These keys can be reassigned in KDE using the Control Center. Choose Look
&amp; Feel &gt; Shortcuts &gt; Shortcut Sequences &gt; Shortcut Sequences &gt;
System &gt; Desktop Switching, and set all items to None or to a different key
sequence such as Ctrl+Alt+Fn. The other alternative is to assign different key
sequences in Eclipse using the <b>Workbench &gt; Keys</b> preference page. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=26361">26361</a>)</p>
<h4>JAWS screen reader does not read Eclipse dialog boxes properly</h4>
<p>There is a known problem with the JAWS screen reader (up to version 4.5)
whereby its &quot;Read Box in Tab Order&quot; command (Ins+B) does not read all
controls in Eclipse dialogs. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=13895">13895</a>)</p>
<h4>Unable to open a fast view if no editors are open (Solaris Motif only)</h4>
<p>On Solaris Motif, attempting to open a fast view when no editors are open
will result in a NullPointerException and can cause some painting problems.
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35244">35244</a>).</p>
<h4>Dirty state not tracked properly for OLE documents
(Windows only)</h4>
<p>The dirty state for an OLE document is not updated
properly. This causes Eclipse to prompt to save the contents of the editor when the document is
closed, even if the contents have already been saved. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=2564">2564</a>)</p>
<h4>OLE document crashes can cause Eclipse to also crash
(Windows only)</h4>
<p>If an OLE document crashes, Eclipse can crash, or the workbench menus can become inconsistent.</p>
<h3>3.1.5 <a name="I-Platform - Text">Platform - Text</a></h3>
<h4>Overwrite mode cannot be disabled for AbstractTextEditor and subclasses</h4>
<p>When removing the key binding for the "Toggle Overwrite Mode" command on the <b>Workbench
&gt; Keys</b> preference page, the mode is still toggled when pressing the "Insert" key. The mode indication in the editor's status line is then out of sync with the actual mode.
(bug <a href="(http:/bugs.eclipse.org/bugs/show_bug.cgi?id=35248)">35248</a>)</p>
<h3>3.1.6 <a name="I-Platform - SWT">Platform - SWT</a></h3>
<h4>Printing and drag and drop not available on Mac (Mac OS X Carbon only)</h4>
<p>The Mac OS X Carbon implementation of SWT does not yet support printing or
drag and drop. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33637">33637</a>,
<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=30104">30104</a>)</p>
<h4>Unable to drag data between applications in simplified Chinese locale (Motif
only)</h4>
<p>When configured for the simplified Chinese locale, it is not possible to drag
data between applications running on the Motif window system. This is a known
limitation of the Open Motif library. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=29777">29777</a>)</p>
<h4>Hang opening font or color dialogs (Mac OS X Carbon only)</h4>
<p>When running with J2SE 1.4.1 for Mac OS X, opening a font or color dialog can
hang Eclipse. This is a bug in Apple's J2SE 1.4.1 involving Cocoa-based dialogs.
Note that J2SE 1.3.1 for Mac OS X does not have this problem. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=30021">30021</a>)</p>
<h4>Crash when attempting to launch file browser (AIX Motif only)</h4>
<p>There is a known AIX graphics bug affecting certain levels of AIX releases.
Ensure that the AIX install includes the necessary service updates as
described in the "Install notes/requirements for Eclipse on AIX" attachment to the Eclipse bug report. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=34524">34524</a>)</p>
<h4>Available colors on 8-bit Linux (Linux only)</h4>
<p>Typically, in Gnome Linux installs running with 8-bit visuals (i.e. 256 color
mode), before the Eclipse application is started there are no
free colors. This may mean that Eclipse is unable to allocate the default widget
background color, causing it to display a white background. The functionality,
however, is otherwise unaffected.</p>
<h4>List and ComboBox on Windows NT (Windows NT only)</h4>
<p>On Windows NT only, you should avoid creating items in a <code>List</code> or
<code>ComboBox</code> with strings longer than 1000 characters. Doing so may
result in a General Protection Fault. This has been fixed in more recent
versions of Windows.</p>
<h4>Excessive CPU consumption&nbsp; (Linux GTK only)</h4>
<p>When using Linux GTK 2.2.1, there are some scenarios where the CPU usage goes
to 100% for no good reason. When this occurs, resizing or closing the dialog
seems to return the CPU usage to normal. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35443">35443</a>)</p>
<h4>
IME-related crash (Linux Motif only)
</h4>
<p>When using Linux Motif and GB18030 IME &quot;chinput&quot;, Eclipse can crash if
the IME client window is left open when the parent window is disposed. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=32045">32045</a>)</p>
<h4>Problems with Japanese IME (Linux Motif only)</h4>
<p>On Linux Motif, the Japanese IME Wnn7 Personal is not working properly with
Eclipse: the pre-edit text does not appear in the text widget, making it
unusable. The IME that we tested - Kinput2 on the client + Canna on the server
side (default IME in RedHat 8.0) - works fine. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=31754">31754</a>)</p>
<h4>BiDi support</h4>
<p>The <code>StyledText</code> widget provides bidirectional language support
for Hebrew and Arabic locales. Currently this support is available only on
Windows and has several known problems.</p>
<h4>Cursor constructor arguments</h4>
<p>In the constructor <code>Cursor(Device device, ImageData source, ImageData
mask, int hotspotX, int hotspotY)</code>, when both a source and mask argument
are specified (that is, the mask is not null), the meaning of the two arguments
is reversed. That is, the &quot;mask&quot; argument should be the source image
and the &quot;source&quot; argument should be the mask image. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=4809">4809</a>)</p>
<h4>Using IBM J9 VM (Photon and AIX)</h4>
<p>On QNX Photon and IBM AIX, the SWT library will not be found when running
with an IBM J9 1.5 VM. This is a bug in the IBM J9 class library in version 1.5.
You can workaround this problem by adding the SWT library directory to your
LD_LIBRARY_PATH environment variable.</p>
<h4>Missing permissions for SWT native libraries in workspace (HP-UX only)</h4>
<p>When retrieving the SWT Motif fragment into an Eclipse workspace, the
permissions of the native libraries are reset. This creates a problem on HP-UX
because shared libraries need to have execute permission. Attempting to
self-host with this fragment throws an UnsatisfiedLinkError...Permission Denied
error. You must manually change the permissions to make these libraries
accessible (assume the workspace is at <code>/workspace</code>):</p>
<blockquote>
  <blockquote>
    <p><code>cd /workspace/org.eclipse.swt.motif/os/hpux/PA_RISC<br>
    chmod 555 *.sl</code></p>
  </blockquote>
</blockquote>
<p>(bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=20305">20305</a>
describes a related problem)</p>
<h4>JAWS requires MSAA for List Views to read checkboxes in Tables (Windows
only)</h4>
<p>In order for JAWS to detect the checkbox information in Tables, MSAA support
for List Views must be activated as follows:</p>
<blockquote>
  <ol>
    <li>Open Eclipse and hit INSERT + F2.</li>
    <li>In the Run JAWS Manager dialog select Configuration Manager.</li>
    <li>In the Jaws Configuration Manager that opens up, select Set Options and
      then select Advanced Options.</li>
    <li>Check &quot;Rely on MSAA for List views&quot;.</li>
    <li>Hit the OK button.</li>
    <li>Choose <b>File &gt; Save</b> from the menu bar.</li>
  </ol>
</blockquote>
<h3>3.1.7 <a name="I-Platform - Team - CVS">Platform - Team - CVS</a></h3>
<p>The following are known problems with the CVS repository provider only, and
do not apply to other repository providers. Additional information on how to use
CVS from Eclipse can be found in the <a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-vcm-home/docs/online/cvs_features2.0/cvs-faq.html">Eclipse
CVS FAQ</a>.</p>
<h4>Cached authorization information lost when workspace is upgraded</h4>
<p>The Platform's internal authorization database file format has changed for
2.1. Because of this, authorization information cached with a workspace created
with an earlier version of Eclipse will be unusable, and the user will need to
reauthenticate. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=32899">32899</a>)</p>
<h4>&quot;extssh&quot; is not a supported command line method</h4>
<p>Since the &quot;extssh&quot; connection method is not a supported command
line method, you cannot use the command line tool when a project uses this
method. Instead, use the Eclipse supported &quot;ext&quot; method and set the
appropriate environment variables so that the command line tool will work. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=7943">7943</a>)</p>
<h4>Connection cannot be found after initially missing</h4>
<p>If a connection initially fails due to a network problem, the connection may
continue to fail even when the network problem is fixed. In order to establish
the connection you must exit and restart Eclipse. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=9295">9295</a>)</p>
<h4>CVS meta-folders appear in some cases</h4>
<p>There are some cases where CVS folders are not hidden from the UI as the user
would expect. For instance, CVS folders will appear if a user imports a CVS
project into Eclipse before the CVS plug-in is loaded. To avoid this, open the
CVS Repositories view (thus loading the CVS plug-in) before importing CVS
projects into Eclipse. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=21128">21128</a>)</p>
<h4>&quot;Received broken pipe signal&quot; error from server</h4>
<p>Eclipse sometimes performs multiple commands within a single connection to the
server. This may cause problems with CVS servers that are running server scripts
in response to certain commands. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=23575">23575</a>
and <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=23581">23581</a>)</p>
<h4>&quot;Terminated with fatal signal 10&quot; error from server</h4>
<p>There is a bug in the CVS server related to some compression levels. If you
get this error, changing the compression level on the CVS preference page may
help. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=15724">15724</a>)</p>
<h4>&quot;Unknown response&quot; error using ext connection method</h4>
<p>There are a few situations that can result in an &quot;Unknown response&quot;
error messages when using the ext connection method. One situation involves
using an external communications client (e.g. rsh or ssh) that adds CRs to the
communications channel (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=21180">21180</a>).
Another involves Eclipse not properly reading the stderr output of the external
communications tool (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=11633">11633</a>).</p>
<h4>No way to update folder excluding subfolders</h4>
<p>There is currently no way in Eclipse to run a non-recursive update on a
folder (i.e., there is nothing equivalent to the cvs -l option). (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33210">33210</a>).</p>
<h3>3.1.8 <a name="I-Platform - Install/Update">Platform - Install/Update</a></h3>
<h4>Update manager claims that a cycle has been detected in a multiple path case</h4>
<p>When a feature includes other features, it is an error to have multiple paths
from the parent to any of its children (there must be exactly one path from the
root to any of the included features). Update manager reports the error but is
not capable of differentiating cycles (when a child includes a parent) and
multiple paths. Consequently, it will claim that there is a cycle in both cases.
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=26808">26808</a>)</p>
<h4>Bundled e-fixes that patch the same feature can clash</h4>
<p>When patches (e-fixes) are created by bundling (including) several patches,
care must be taken that they do not carry different versions of the same
feature. If they do, both features may end up disabled. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=31407">31407</a>)</p>
<h4>Update manager does not support https protocol</h4>
<p>Update manager currently cannot open connections to the remote update sites
if the provided URL has <b>https </b>protocol. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=31979">31979</a>)</p>
<h4>Internal Error in Update Manager while installing/updating when features
include the same plug-in</h4>
<p>If two or more features in the feature tree formed by inclusion have the same
plug-in entry, install or update will fail. This happens because update manager
attempts to install the same plug-in more than once and fails to rename files
since they already exist. To work around this problem, ensure that no two
features in the single feature hierarchy (starting from the root feature)
reference the same plug-in (have a plug-in entry with the same id and version).
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33937">33937</a>)</p>
<h4>Non-responsive sites may use all free threads</h4>
<p>Prior to Eclipse 2.1, if the connection to an
update site did not respond (the site did not exist or was down), the workbench
became non-responsive until the connection request timed out. In 2.1,
connections are made by a separate thread so that the UI stays responsive.
Typically, unresponsive connections eventually time out and these threads
terminate. In rare cases, servers accept the connection but never send a
response, thereby keeping the connection thread live indefinitely. Update
manager limits the number of active connection threads and will refuse to create
more once the limit is reached. To work around the problem, exit and restart
Eclipse. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=18598">18598</a>,
<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19775">19775</a>)</p>
<h4>URL validity checking on input</h4>
<p>URL syntax is currently not completely checked on input. Ensure that the entered
URL uses forward&nbsp; slash ('/') separators and does not
contain invalid characters. (bugs <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19685">19685</a>,
<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20247">20247</a>)
<h4>Running &quot;headless&quot; applications that do not handle restart</h4>
<p>When install changes are detected, the changes are automatically processed
and the workbench restarts. The executable launcher supplied with the
application correctly handles the restart. However, if you have applications
that directly call the platform (eg. by calling the BootLoader APIs) and do not
handle restart, the startup reconciliation processing can be suppressed by
specifying <tt>-noupdate</tt> command line option. In this case, the application
will start with the set of features and plug-ins that were processed and
configured on the previous start. If prior configuration cannot be found, the
application will start with the full set of plug-ins found in the installation
location.
<h4>Link file entry with trailing blanks is invalid</h4>
<p>If a link file used to connect product extensions with products contains an
entry with trailing blank characters, it will be considered invalid. The
workaround is to ensure that the entry ends with an end-of-line character (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=22993">22993</a>).
<h4>Enabling two versions of the same feature</h4>
<p>Care should be taken when enabling and disabling multiple versions of the
same feature. If they include other features and the inclusion is set with a
match attribute that is not &quot;perfect&quot;, disabling old feature version
may have a consequence of disabling new children. To avoid this situation,
disable the new version first, then enable the old one; i.e., never have two
versions of the same feature simultaneously enabled (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=25236">25236</a>).</p>
<h4>Upgrading very old workspaces</h4>
<p>If you upgrade to 2.1 from a pre-2.0 workspace that existed prior to the introduction of
features, the next time you add a feature you will be prompted on startup with a dialog asking which features to install.  If you de-select all features and click OK, then all features are disabled.  This prevents
you from ever using that workspace again (since the Eclipse Platform feature is disabled).  The
solution is to delete the <code>.config</code> subdirectory in the workspace's
metadata area and then restart Eclipse. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35703">35703</a>)</p>
<h3>3.1.9 <a name="I-Platform - Debug">Platform - Debug</a></h3>
<p>None. (Known problems with the Java debugger appear below in the <a href="#I-Java Development Tools (JDT)">JDT</a>
section.)</p>
<h3>3.1.10 <a name="I-Platform - Compare">Platform - Compare</a></h3>
<p>None.</p>
<h3>3.2 <a name="I-Java Development Tools (JDT)">Java Development Tools (JDT)</a></h3>
<h4>Running Java programs with non-Latin-1 characters in
package or class names</h4>
You get a <code>java.lang.NoClassDefFoundError</code> when
running Java programs with non-Latin characters in the package or class names.
The workaround is to package the class files as a JAR file and run the program
out of the JAR and not from the file system directly. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=4181">4181</a>)
<h4>Cannot run or debug class in a project with GB18030 characters in project
name</h4>
<p>Most class libraries do not properly support the creation of a system process
(via <code>java.lang.Runtime.exec(...)</code>) when the specified command line
contains GB18030 characters. This limitation means the debugger cannot launch
applications when the command line it generates contains GB18030 characters.
(bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=32206">32206</a>)</p>
<h4>Unable to debug stack overflows</h4>
<p>If a debug session suspends on a <code>java.lang.StackOverflowError</code>
exception (due to an exception breakpoint), the debugger may not be able to
retrieve any debug information from the target JVM. As well, the debugger may
not be able to reliably interact with the target JVM past this point. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=19217">19217</a>)</p>
<h4>Evaluation limitation</h4>
<p>The debugger uses threads in the target JVM to perform evaluations (both
explicit evaluations that the user requests, and implicit evaluations such as <code>toString()</code>
invocations in the <b>Variables</b> view). The Java Debug Interface (JDI)
requires that the thread in which an evaluation is performed be suspended by a
user event (that is, a breakpoint or step request). Evaluations cannot be
performed on threads suspended by the suspend action. As well, when a breakpoint
is configured to suspend the JVM rather than just the individual thread, the
threads which did not encounter the breakpoint are not in a valid state to
perform an evaluation. When an evaluation is attempted in a thread that is not
in a valid state to perform an evaluation, an error message will appear to the
effect of &quot;Thread must be suspended by step or breakpoint to perform method
invocation&quot;. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=34440">34440</a>)</p>
<h4>Breakpoints outside of the build class path</h4>
<p>Breakpoints can only be created on Java elements that are contained on the
build class path of a project. The Java debugger automatically deletes
breakpoints if their associated Java element is removed from the build path of a
project. However, if the Java debug plug-in is not loaded when a build path is
changed, such breakpoints will remain in the workspace, and can cause errors
when the user attempts to go to the file associated with the breakpoint, from
the Breakpoints view. (bug 34845)</p>
<h4>Missing debug attributes</h4>
The debugger requires that class files be compiled with debug attributes if it
is to be able to display line numbers and local variables. Quite often, class
libraries (for example, &quot;<code>rt.jar</code>&quot;) are compiled without
complete debug attributes, and thus local variables and method arguments for
those classes are not visible in the debugger.
<h4>Setting breakpoints</h4>
In general the debugger will not allow you to place breakpoints on lines of code
that are not executable (comments, blank lines, etc.). However, there are some
cases where the debugger will allow breakpoints on lines of code that are not
executable. For example, the debugger will allow a breakpoint to be placed on a
variable declaration that does not contain an initializer (&quot;int x;&quot;).
Note that enabled breakpoints which are successfully installed on an executable
line in a running (debuggable) VM are displayed with a checkmark. Breakpoints
that are displayed without a checkmark are not installed in a running (debuggable)
VM. (bugs <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=8473">8473</a>, <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=12696">12696</a>)
<h4>Using Hot Code Replace</h4>
Hot code replace is supported on JDK 1.4.x VMs, and IBM J9 VMs. Hot code replace
is limited to changes which do not effect the shape of a class. That is, changes
within existing methods are supported, but the addition or removal of members is
not supported.
<p>Note that hot code replace and stepping on JDK 1.4.0 VMs was unreliable. The
underlying VM problems were fixed in JDK 1.4.1.</p>
<h4>Scrapbook</h4>
Setting a breakpoint inside a scrapbook page is not supported.
<p>When a snippet is run in the scrapbook which directly or indirectly calls <code>System.exit(int)</code>,
the evaluation cannot be completed, and will result in a stack trace for a <code>com.sun.jdi.VMDisconnectedException</code>
being displayed in the scrapbook editor.
<p>Terminating a scrapbook page while it is performing an evaluation results in
a <code>com.sun.jdi.VMDisconnectedException</code> being displayed in the
scrapbook editor.
<h4>Debugging over slow connections</h4>
A global Java debug preference specifies the debugger timeout, which is the
maximum amount of time the debugger waits for a response from the target VM
after making a request of that VM. Slow connections may require that this value
be increased. The timeout value can be edited from the <b>Java &gt; Debug </b>preference
page. Changing the timeout value only effects subsequently launched VM, not VMs
that are already running.
<h4>Updating of inspected values</h4>
When inspecting the result of an evaluated expression in the debugger, it is
important to note that the result displayed is the result of that expression at
the time it was evaluated. For example, when inspecting a simple integer counter
(primitive data type), the value displayed in the Expressions view is the value
when the expression was evaluated. As the counter is changed in the running
program, the inspected result will not change (since the view is not displaying
the value bound to a variable - it is displaying the value of an expression, and
the value of a primitive data type cannot change). However, if an expression
results in an object, fields of that object will be updated in the inspector as
they change in the running program (since the value bound to fields in an object
can change).
<h4>Stepping over native methods that perform I/O</h4>
When the debugger steps over native methods that perform I/O to <code>System.out</code>
or <code>System.err</code>, the output may not appear immediately unless the
native performs a flush on the output buffer.
<h4>VM and process termination running on IBM 1.3 JVM on Linux (Linux only)</h4>
Terminating a launch, debug target, or system process associated with a debug
target running on the IBM 1.3 JVM on the Linux platform does not work when the
associated debug target has a suspended thread. To remove such debug targets
from the debug UI, select <b>Terminate and Remove</b> from the debug view's
pop-up menu (or use the shortcut &quot;delete&quot; key). Associated system
processes in the OS may not be properly cleaned up. If a debug target has no
suspended threads, termination works properly. (bug <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=1631">1631</a>)
<h4>Searching for constant field references</h4>
Search does not find references to constant fields inside
binaries because the Java Language Specification mandates that constant field
values be inlined in the class file's bytecodes, leaving no trace of a field
reference.&nbsp;(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=12044">12044</a>)
<h4>Quick fix and imports from default packages</h4>
<p>Quick fix does not handle imports from default packages. Note that importing from a default package is no longer supported in JDK 1.4 (bug
<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19487">19487</a>)</p>
<h4>Javadoc hover in the Java editor</h4>
<p>The Javadoc hover help shown when hovering over
identifiers in the Java editor does not handle links inside of Javadoc comments
properly. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20644">20644</a>)</p>
<h4>Cut, copy, paste not working for linked resources in views showing Java
elements</h4>
<p>The cut, copy, and paste actions do not work for linked files and folders
appearing in views that show Java elements, including the Package Explorer. The
workaround is to use these actions from the Navigator view instead. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=34568">34568</a>)</p>
<h4>Java working sets not working correctly for elements from JRE system library
container</h4>
<p>Appling a working set consisting entirely of elements from the JRE System
library container as a filter to the packages view might result in an empty
Package Explorer. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35395">35395</a>)</p>
<h4>Problems with files named &quot;java&quot;</h4>
<p>If a Java project contains a file named &quot;java&quot;, it will trigger an
internal error when it is classified (incorrectly) as a Java compilation unit.
There are no problems with the string &quot;java&quot; occurs as a part of the
name (e.g, javaRefs.txt) or as the file extension part of the name (e.g, A.java).
The workaround is to ensure that there are no files named &quot;java&quot;
within a Java project. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35614">35614</a>)</p>
<h4>Cannot generate Javadoc for packages with GB18030 characters in the name</h4>
<p>Most class libraries do not properly support the creation of a system process
(via <code>java.lang.Runtime.exec(...)</code>) when the specified command line
contains GB18030 characters. Since Javadoc is created using the Javadoc
executable provided with the JDK, generating Javadoc fails if the package or
class name contains GB18030 characters. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=32215">32215</a>)</p>
<h4>Linked editing does not work correctly in overwrite mode</h4>
<p>Linked editing is used for renaming elements within a single compilation unit
and for templates with multiple occurrences of the same template variable.
Linked editing does not work correctly in overwrite mode. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35216">35216</a>)</p>
<h4>Catch block code generation template must end with newline if last line is
line comment</h4>
<p>If the last line of the catch block code generation template is a line comment then the line
must be terminated with a newline. Otherwise the closing curly bracket ends up on the comment
line, resulting in a compilation error. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35746">35746</a>)</p>
<h4>Problem opening class file editor</h4>
<p>If the &quot;Use classpath containers" preference has been enabled on the <b>Plug-in
Development &gt; Java Build Path Control</b> preference page, you may not be
able to open a class file editor for a class file contained in a JAR in the "Required plug-in entries" container.
One way to work around the problem is to expand the class file in the Packages
Explorer; this displays the class file's structure just as the editor would. If
a source code zip is available for the JAR, another option is to attach source to the JAR file.</p>
<p>To attach source to a JAR in the &quot;Required plug-in entries&quot;
container, follow these steps:</p>
<ol>
  <li>In the Package Explorer, select the project and open <b>Project &gt;
    Properties</b> from the context menu</li>
  <li>Select the <b>Java Build Path</b> page</li>
  <li>Flip to the <b> Libraries</b> page</li>
  <li>Expand the "Required plug-in entries" item</li>
  <li>Expand the item for the JAR</li>
  <li>Select &quot;Source Attachment&quot; and press <b>Edit</b></li>
  <li>Enter the location of the corresponding source zip</li>
  <li>OK to acknowledge</li>
</ol>
<p>(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35769">35769</a>)</p>
<h3>3.3 <a name="I-Plug-in Development Environment (PDE)">Plug-in Development
Environment (PDE)</a></h3>
<h4>PDE source page colors do not take effect on Apply</h4>
<p>Changes to the colors PDE uses for source pages of its multi-page editors are
not immediately visible in opened editors after pressing the Apply button
on&nbsp; the <b>Plug-in Development &gt; Editors preference</b> page. To work
around this problem, close the editor and and reopen it. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33640">33640</a>)</p>
<h4>Icons folder not included in bin.includes of some PDE templates</h4>
<p>PDE provides a number of templates that can be used to create fully
functioning plug-in projects and/or extensions. When projects are created, the <code>build.properties</code>
file is created with the initial content, which includes the property 'bin.includes'
listing the plug-in manifest and its code JARs. However, it omits mention of
other files created by the template, such as the <code>icons/</code> folder. As
a request, these extra files do not end up in the plug-in when built using Ant
build file or exported using 'Export deployable plug-ins and fragments' wizard.
To work around this problem, add these files and directories manually in
build.properties file. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35554">35554</a>)</p>
<h4>Emacs key bindings do not work in manifest editor fields</h4>
<p>Non-default key bindings currently do not work in fields on non-source pages
of the PDE manifest editors. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19482">19482</a>)</p>
<h4>Comments in source pages of PDE XML editors</h4>
<p>PDE provides a number of multi-page editors that include a raw source page.
Editors that handle XML files (plug-in, fragment and feature manifests) will
preserve comments in most cases. However, comments will not be preserved if
added before the root XML element, or if added after the last child element
contained in the parent element. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=8000">8000</a>)</p>
<h4>Problem while importing fragments</h4>
<p>If a workspace contains binary projects for a plug-in and a fragment that
references that plug-in, fragment libraries are added to the class path of the
referenced plug-in project. When an attempt is made to overwrite the plug-in and
the fragment with versions from another build, deletion of the old fragment may
fail. If that happens, repeat the operation to repair the workspace. Only the
affected plug-in and fragment need to be re-imported. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=16921">16921</a>)</p>
<h4>Plug-in import wizard does not allow plug-ins of different versions to be
imported</h4>
<p>The Eclipse platform allows two plug-ins with the same ID but different
versions to coexist if the only thing they contribute is run-time libraries.
However, PDE cannot handle these plug-ins because it creates project names using
plug-in IDs during binary project import. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=18500">18500</a>)</p>
<h4>PDE nature required for plug-in manifest syntax checking</h4>
<p>PDE will only be able to provide syntax checking and error/warning markers
for plug-in manifests if the plug-in project has the PDE plug-in nature. A
plug-in project automatically gets this nature when created by a PDE wizard.
This situation can only occur if a regular Java project has been used to host a
plug-in. The problem can be fixed by converting it into a PDE project. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19248">19248</a>)</p>
<h4>PDE does not preserve original manifest file layout</h4>
<p>When non-Source page of a PDE manifest editor is used, PDE will convert
changes back into XML by regenerating the file. Although the overall content and
the comments are preserved, the actual file layout is not. This may cause
problems by showing false changes during file compare. If file layout is
important, perform all editing in the Source page. Alternatively, avoid using
Source pages altogether. Since XML files are generated in a way that respects
and preserves the relative order of major elements (extensions, extension points
etc.), changes made in a non-Source page of a PDE manifest editor do not result
in false deltas during file compare. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19251">19251</a>)</p>
<h4>Go To Line in manifest editor causes Outline view to go blank</h4>
<p>When the <b>Source &gt; Go To Line</b> command is invoked in the Source page
of a PDE manifest editor, the Outline view will become gray. Since the Source
page does not have a functional outline, there is no actual loss of function.
(bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19361">19361</a>)</p>
<h3>3.4 <a name="I-Other - FTP and WebDAV support">Other</a></h3>
<h3>3.4.1 F<a name="I-Other - FTP and WebDAV support">TP and WebDAV support</a></h3>
<h4>When mapped to a target, the project folder is ignored</h4>
<p>Ignoring the project folder is by design. Normally with target management you
put/get the contents of the project, not the actual project. The place you pick
in the site explorer is where the project contents will go. This allows your
local project to have a different name than the container in the WebDAV/FTP
server. If you want to map several projects to the same site location, you
create a new folder for each one. This is why &quot;New Folder&quot; is in the
mapping page. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=17657">17657</a>)</p>
<h4>FTP messages cause an exception</h4>
<p>With some servers, the FTP client may receive messages that it did not
anticipate. These will cause an exception. Trying the operation again usually
works. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=18108">18108</a>)</p>
<h4>FTP problems with spaces in resource names</h4>
<p>FTP does not work properly when file or folder name contains spaces. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20220">20220</a>)</p>
<h4>FTP problems retrieving remote timestamps with NT server</h4>
<p>Problems have occurred with some servers (NT server Serv-U FTP-Server v2.5k )
when trying to obtain the timestamp of a newly uploaded file. This causes a
&quot;file does not exist&quot; error. The workaround is to <b>Synchronize</b>
again and continue. (bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19715">19715</a>)</p>
<h2>4. <a name="Running Eclipse">Running Eclipse</a></h2>
<p>After installing the Eclipse SDK in a directory, you can start the Workbench by running the Eclipse executable
included with the release (you also need a JRE, included with the Eclipse SDK). On Windows, the executable file is called <samp>eclipse.exe</samp>,
and is located in
the <code>eclipse</code> subdirectory of the install. If installed at <code>c:\eclipse-SDK-2.1-win32</code>,
the executable is <code>c:\eclipse-SDK-2.1-win32\eclipse\eclipse.exe</code>. <b>Note:</b> Set-up on
other operating environments is
analogous.</p>
<p>If you do not specify otherwise, Eclipse creates a default workspace in a
subdirectory as a sibling of the executable (that is, at, <code>c:\eclipse-SDK-2.1-win32\eclipse\workspace</code>).
This workspace directory is used as the default content area for your projects
as well as for holding any required metadata. For shared or multi-workspace
installs you must explicitly specify the location for your workspace using the
&quot;<code>-data</code>&quot; command line
argument; for example,&nbsp;</p>
<blockquote>
  <p><code>eclipse -data c:\myworkspace -vm c:\jdk1.4.1_01\jre\bin\javaw</code></p>
</blockquote>
<p><i>Tip:</i> It's generally a good idea to explicitly specify which Java VM to
use when running Eclipse.  This is achieved with the &quot;<code>-vm</code>&quot; command line
argument as illustrated above.  If you don't use &quot;<code>-vm</code>&quot;, Eclipse will look
on the O/S path.  When you install other Java-based products, they may change your
path and could result
in a different Java VM being used when you next launch Eclipse.
</p>
<p>To create a Windows shortcut to an installed Eclipse and a particular
workspace (e.g., <code>c:\myworkspace</code>):</p>
<ol>
  <li>Navigate to <code> eclipse.exe</code> in Windows Explorer and use Create
    Shortcut on the content menu.
  <li>Select the shortcut and edit its Properties. In the Target: field append
    the <code>-data</code> option followed by the location of the workspace
    (e.g., &quot;<code>-data c:\myworkspace</code>&quot;).
</ol>
<p>Opening this shortcut launches Eclipse on the specified workspace. (You can
drag the shortcut to the Windows Desktop if you want to keep it in easy reach.)</p>

<h2>5. <a name="Upgrading"></a>Upgrading Workspace from a Previous Release</h2>
<p>
If you are upgrading to a newer release of Eclipse from an older release, there are
simple steps to follow to migrate your workspace to the new release.  Your workspace
is the directory on disk that contains all of your project files, as well as
metadata such
as preferences you may have customized.  The steps to follow for upgrading depend on
whether or not you used the &quot;<code>-data</code>&quot; command line argument when starting 
Eclipse.  The &quot;<code>-data</code>&quot; argument is recommended because it clearly specifies the 
location of your workspace.  If this argument is not used, Eclipse will place the workspace
in the current working directory at the time Eclipse was launched.
</p>
<p>Note that if you installed additional features and plug-ins into your older Eclipse, you
should re-install them in the new Eclipse prior to upgrading workspaces.
<p><i>Tip:</i> It doesn't hurt to make a backup copy of your workspace before
upgrading.  After you've upgraded your workspace, you won't be able to use it
again with an older version of Eclipse.  If you ever want to go &quot;back in time&quot;
to an earlier release, you'll need that backup!
</p>
<h3>Users who don't use &quot;-data&quot;</h3>
<p>
If you weren't previously using &quot;-data&quot; to specify your workspace, follow
these steps to upgrade:
<ol>
<li>Find the workspace directory used by your old version of Eclipse.  Typically this
is located inside the directory in which Eclipse was installed in a subdirectory called &quot;<code>workspace</code>&quot;.
If you are using a shortcut or script to launch Eclipse, then it will be under the current
working directory of that shortcut or script in a subdirectory called &quot;workspace&quot;.
  For Windows users, this is specified by the Start in: argument in your shortcut properties.</li>
<li>Copy this workspace directory to a new, empty location outside of any Eclipse
install directory.</li>
<li>Install the new version of Eclipse in a new location, separate from any old version
of Eclipse.</li>
<li>Start this new version of Eclipse, using the &quot;<code>-data</code>&quot; command line argument to 
point to the workspace location.</li>
</ol>
<h3>Users who do use &quot;-data&quot;</h3>
<p>
If you were previously using the &quot;<code>-data</code>&quot; argument to start Eclipse, your 
upgrade path is much easier:
<ol>
<li>Install the new version of Eclipse in a new location, separate from any old versions
of Eclipse.</li>
<li>Start this new version of Eclipse, using the &quot;<code>-data</code>&quot; command line argument to 
point to your old workspace location.</li>
</ol>
<h2>6. <a name="Interoperability with Previous Releases">Interoperability with
Previous Releases</a></h2>
<h3>6.1 Interoperability of Release 2.1 and 2.0</h3>
<h4>Sharing projects between heterogeneous Eclipse 2.0 and 2.1</h4>
<p>Special care is required when a project in a team repository is being loaded
and operated on by developers using Eclipse-based products based on different
feature or plug-in versions. The general problem is that the existence,
contents, and interpretation of metadata files in the workspaces may be specific
to a particular feature or plug-in version, and differ between versions. The
workspace compatibility guarantees only cover cases where all developers upgrade
their Eclipse workspaces in lock step. In those cases there should be no problem
with shared metadata. However, when some developers are working in Eclipse 2.1
while others are working in Eclipse 2.0, there are no such guarantees. This
section provides advice for what to do and to not do. It addresses the specific
issues with the Eclipse SDK.</p>
<p>The typical failure mode is noticed by the 2.1 user. 2.1 metadata is lost
when a 2.0 user saves changes and then commits the updated metadata files to the
repository. Here's how things typically go awry:</p>
<ul>
  <li>A user working in Eclipse 2.1 creates or modifies a project in a way that
    results in changes to a shared metadata file that rely on 2.1-specific
    information. The user then commits the updated project files, including the
    shared metadata file, to the shared repository.</li>
  <li>Another user working in Eclipse 2.0 shares this project from the same
    repository. The 2.1-specific information in the shared metadata file is not
    understood by Eclipse 2.0, and is generally discarded or ignored without
    warning. The user modifies the project in a way that results in changes to
    the shared metadata file, causing the shared metadata file to be rewritten
    without any of the 2.1-specific information. The user commits the updated
    project files, including the shared metadata file, to the shared repository.
    The user is generally unaware that shared information has just been lost as
    a result of their actions.</li>
  <li>A user working in Eclipse 2.1 picks up the changes to a project from the
    shared repository, including the updated shared metadata file. The user may
    be unaware that they have just taken a retrograde step until later when
    things start to malfunction.</li>
</ul>
<p>Here are a list of things to watch out for when the project is to be shared
between users of Eclipses 2.1 and 2.0:</p>
<ul>
  <li><b>Linked folders and files<br>
    </b>This support was added in 2.1. Information about linked resources is
    recorded in the project's <code>.project</code> file. Recommendation: do not
    use. Better still, disable linked resources via the <b>Workbench &gt; Linked
    Resources</b> preference page.</li>
  <li><b>External tool (Ant) builders</b><br>
    Information about external tool builder is recorded in the project's <code>.project</code>
    file. The format of the information changed between 2.0 and 2.1. Builders
    created or changed in 2.1 use the new format, which is not understood by a
    2.0 workspace. Builders created in 2.0 use the old format and continue to
    work in 2.1. Recommendation: Always create or edit external tools builders
    from a 2.0 workspace.</li>
  <li><b>Optional exclusion patterns on Java source entries on the build class
    path</b><br>
    This support was added in 2.1. This information is recorded in the project's
    <code>.classpath</code> file. Recommendation: do not specify exclusion
    patterns.&nbsp; Better still, disable exclusion patterns via the<b> Java
    &gt; Compiler &gt; Build Path</b>&nbsp; preference page.</li>
  <li><b>Output folders associated with Java source entries on the build class
    path</b><br>
    This support was added in 2.1. This information is recorded in the project's
    <code>.classpath</code> file. Recommendation: do not specify anything other
    than the default (project-wide) output folder.&nbsp; Better still, disable
    multiple output locations via the<b> Java &gt; Compiler &gt; Build Path</b>&nbsp;
    preference page.</li>
  <li><b>Source attachment root path associated with Java library entries on the
    build class path</b><br>
    When attaching a source ZIP to a library JAR on the Java build path, the
    source root path prefix is inferred automatically. This has changed from
    2.0, where it could be explicitly set via the UI and explicitly recorded in
    the project's <code>.classpath</code> file. Consequently, a Java project
    created in a 2.1 workspace might not find the attached source.
    Recommendation: Use 2.0 to specify the source attachment root path. There is
    additional source attachment flexibility provided in 2.1: you can provide a
    folder instead of a JAR or zip as a source attachment, and you can attach
    source to a class file folder; this functionality is not available in 2.0
    (where the 2.1 information is ignored).&nbsp; Recommendation: Use 2.0 to
    specify the source attachment.</li>
  <li><b>PDE classpath containers for dependent plug-ins</b><br>
    PDE's use of classpath containers was added in 2.1. Classpath containers are
    recorded in the project's <code>.classpath</code> file. If PDE classpath
    containers are used, then a 2.0 workspace will have unresolved classpath
    entries and therefore most Java capabilities (including compilation, search,
    run, debug) will not produce the expected results. Recommendation: Ensure
    that the setting on the <b>Plug-in Development &gt; Java Build Path Control </b>preference
    page for using classpath containers is disabled before creating any new plug-in
    (or fragment) projects.</li>
</ul>
<h4>Using Eclipse 2.1 to develop plug-ins that work in Eclipse 2.0</h4>
<p>It is also possible (and reasonable) to use Eclipse 2.1 to develop a plug-in
intended to work in Eclipse 2.0. Use the <b>Plug-in Development &gt; Target
Platform </b>preference page to locate non-workspace plug-ins in an 2.0 Eclipse
install. This ensures that the code for your plug-in is being compiled and
tested against Eclipse 2.0 APIs, extension points, and plug-ins. (The above list
of concerns do not apply since they affect the layout and interpretation of
files in the plug-in <i>project</i> but none affect the actual deployed form of
the plug-in.)</p>
<hr>
<p>Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc.
in the United States, other countries, or both.</p>
<p>IBM is a trademark of International Business Machines Corporation in the
United States, other countries, or both.</p>
<p>Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.</p>
<p>Apple and Mac OS are trademarks of Apple Computer, Inc., registered in the
U.S. and other countries.</p>
<p>QNX, Neutrino, and Photon are trademarks or registered trademarks of QNX
Software Systems Ltd.</p>
<p>Other company, product, and service names may be trademarks or service marks
of others.</p>
<p>(c) Copyright IBM Corp. and others 2003</p>

</body>

</html>