Target Operating Environments

In order to remain current, each Eclipse Project release targets reasonably current operating environments.

Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions are
targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.1, J2SE 1.4, Java
5, etc).

In general, the 4.9 release of the Eclipse Project is developed on Java SE 8 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs.

Appendix 1 contains a table that indicates the class library level required for each bundle.

There are many different implementations of the Java Platform running atop a variety of operating systems. We focus our testing on a handful of popular combinations of operating system and Java
Platform; these are our reference platforms. Eclipse undoubtedly runs fine in many operating environments beyond the reference platforms we test. However, since we do not systematically
test them we cannot vouch for them. Problems encountered when running Eclipse on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than
problems with running Eclipse on a reference platform.

As stated above, we expect that Eclipse works fine on other current Java VM and OS versions but we cannot flag these as reference platforms without significant community support for testing
them.

The Eclipse SDK 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.

Latin-1, DBCS, and BiDi locales are supported by the Eclipse SDK on all reference platforms.

Binary (plug-in) Compatibility: Eclipse SDK 4.9 is upwards binary-compatible with Eclipse SDK 4.8 except in those areas noted in the Eclipse 4.9 Plug-in Migration Guide. Downward plug-in compatibility is not supported.
Plug-ins for Eclipse SDK 4.9 will not be usable in Eclipse SDK 4.8. Refer to Evolving Java-based APIs for a discussion of
the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 4.9 is upwards source-compatible with Eclipse SDK 4.8 except in the areas noted in the Eclipse 4.9 Plug-in Migration Guide. This means that source files written to use Eclipse
SDK 4.9 APIs might successfully compile and run against Eclipse SDK 4.9 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK
APIs, they will not be usable with an earlier version of the Eclipse SDK.

Workspace Compatibility: Eclipse SDK 4.9 is upwards workspace-compatible with earlier 3.x and 4.x versions of the Eclipse SDK unless noted. This means that workspaces and projects
created with Eclipse SDK 4.8, 4.7, 4.6, 4.5, 4.4, 4.3, 4.2, ... 3.0 can be successfully opened by Eclipse SDK 4.9 and upgraded to a 4.9 workspace. 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 4.9 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 4.9 plug-in developers are
responsible for ensuring that their plug-ins recognize metadata from earlier versions 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 a product based on Eclipse 4.9 will be unusable with a product based on an earlier version of Eclipse. Visible
metadata files created (or overwritten) by Eclipse 4.9 will generally be unusable with earlier versions of Eclipse.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name or x-internal in the bundle manifest entry, 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 How to Use the Eclipse API for information about how to write compliant plug-ins.

Running Eclipse with Java SE 9 and above may require additional configuration. Please refer to this page for more details.

As shown above, Eclipse 4.8 requires at least a Java SE 8. Perhaps an older version of the VM is being found in your path. To
explicitly specify which VM to run with, use the Eclipse -vm command-line argument. (See also the Running Eclipse section below.)

Running Eclipse on Gentoo Linux may result in the following error message:

* run-java-tool is not available for sun-jdk-1.6 on i686 * IMPORTANT: some Java tools are not available on some VMs on some architectures

If this occurs, start Eclipse by specifying a -vm argument, either specify the path to a java vm or use: eclipse -vm `java-config --java` (bug 176021)

Eclipse must be installed to a clean directory and not installed over top of a previous installation. If you have done this then please re-install to a new directory. If your workspace is
in a child directory of your old installation directory, then see the instructions below on "Upgrading Workspace from a Previous Release".

Java sometimes has difficulty detecting whether a file system is writable. In particular, the method java.io.File.canWrite() appears to return true in unexpected cases (e.g., using
Windows drive sharing where the share is a read-only Samba drive). The Eclipse runtime generally needs a writable configuration area and as a result of this problem, may erroneously detect the
current configuration location as writable. The net result is that Eclipse will fail to start and depending on the circumstances, may fail to write a log file with any details. To work around
this, we suggest users experiencing this problem set their configuration area explicitly using the -configuration command line argument. (bug 67719)

It is imperative that 64-bit builds are downloaded and used if a 64-bit Java runtime environment has been installed. Below are two sample tarball names of version 4.9 of the Eclipse SDK packaged
for 32-bit and 64-bit processors.eclipse-SDK-4.9-linux-gtk.tar.gz (32-bit)eclipse-SDK-4.9-linux-gtk-x86_64.tar.gz (64-bit)

To run Eclipse with an alternate Java runtime environment, the path to the Java virtual machine's binary must be identified. With an Eclipse installation from the distribution, altering the $PATH
variable to include the path to the alternate Java runtime environment is often not enough as the Eclipse that Linux distributions package often performs a scan internally to pick up GCJ by itself
whilst ignoring what's on the $PATH. An example of the terminal's output is shown below:
searching for compatible vm... testing /usr/lib/jvm/java-gcj...found

Once the path to the virtual machine's binary has been identified, try running Eclipse with the following command:./eclipse -vm /path/to/jre/bin/java

If this seems to solve the problem, it is likely that the problem really was related to the use of GCJ as the Java runtime for running Eclipse. The eclipse.ini file located within Eclipse's folder
can be altered to automatically pass this argument to Eclipse at startup. An example of its content is presented below:
-showsplash org.eclipse.platform -vm /opt/sun-jdk-1.6.0.02/bin/java -vmargs -Xms40m -Xmx512m

If problems persists after downloading an installation of Eclipse from eclipse.org and using a supported Java runtime environment (a list of which may be found above), you can seek further assistance through the forums, the IRC channel, and/or bugzilla.

The proper plug-in class loader is used by FindClass in JNI functions which are passed the JNIEnv pointer, but not when you have to use AttachCurrentThread to get the JNIEnv pointer. In this
case the application classloader is used.

For example, the following will fail because AttachCurrentThread is used to get the JNIEnv pointer:

Java 5 annotation processors are supported in the IDE only. Java 5 processors can be executed while editing, as well as during a build. Slow annotation processors can cause a slowdown of the
editing experience. If this occurs, you may wish to turn off Enable processing in editor on the Java Compiler > Annotation Processing properties page of your Java project.

If you need to launch Eclipse from the command line, you can create a symbolic link such as "eclipse". It should point to the eclipse executable inside the application bundle and takes the
same arguments as "eclipse.exe" on other platforms.

On Mac OS X 10.4 and later, you may notice a slow down when working with significant numbers of resources if you allow Spotlight to index your workspace. To prevent this, start System
Preferences, select the Spotlight icon, then the Privacy tab, then click the Add button ("+") and find your workspace directory in the dialog that appears.

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 4.9 while others are working in Eclipse 3.x, there are no such guarantees. This section provides advice for what to do and not to do. It addresses the
specific issues with the Eclipse SDK.

The typical failure mode is noticed by the 4.9 user. 4.9 metadata is lost when a 4.8 user saves changes and then commits the updated metadata files to the repository. Here's how things
typically go awry:

A user working in Eclipse 4.9 creates or modifies a project in a way that results in changes to a shared metadata file that rely on 4.9-specific information. The user then commits the
updated project files, including the shared metadata file, to the shared repository.