Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Plug-in Developer Guide
Previous Page Home Next Page

Eclipse Platform
Naming Conventions

Last revised June 6, 2007

Naming conventions and guidelines for the Eclipse Platform:

Java Packages

The Eclipse Platform consists of a collection of Java packages. The package namespace is managed in conformance with Sun's package naming guidelines; subpackages should not be created without prior approval from the owner of the package sub-tree. The packages for the Eclipse platform are all subpackages org.eclipse . The first package name component after org.eclipse is called the major package name. The following major packages of org.eclipse are assigned in the Eclipse 3.3 release:
org.eclipse.ant[.*] - Ant support
org.eclipse.compare[.*] - Compare support
org.eclipse.core[.*] - Platform core
org.eclipse.debug[.*] - Debug
org.eclipse.equinox[.*] - Equinox sub-project
org.eclipse.help[.*] - Help support
org.eclipse.jdi[.*] - Eclipse implementation of Java Debug Interface (JDI)
org.eclipse.jdt[.*] - Java development tools
org.eclipse.jface[.*] - JFace
org.eclipse.jsch[.*] - Jsch SSH library support
org.eclipse.ltk[.*] - Generic language tool infrastructure
org.eclipse.osgi[.*] - Eclipse API for interacting with OSGi
org.eclipse.pde[.*] - Plug-in Development Environment
org.eclipse.search[.*] - Search support
org.eclipse.swt[.*] - Standard Widget Toolkit
org.eclipse.team[.*] - Team support and Version and Configuration Management
org.eclipse.text[.*] - Text editor framework
org.eclipse.tomcat[.*] - Apache tomcat support
org.eclipse.ui[.*] - Workbench
org.eclipse.update[.*] - Update/install
org.eclipse.webdav[.*] - WebDAV support
The following package name segments are reserved:
internal - indicates an internal implementation package that contains no API
tests - indicates a non-API package that contains only test suites
examples - indicates a non-API package that contains only examples
These name are used as qualifiers, and must only appear following the major package name. For example,
org.eclipse.core.internal.resources - Correct usage
org.eclipse.internal.core.resources - Incorrect. internal precedes major package name.
org.eclipse.core.resources.internal - Incorrect. internal does not immediately follow major package name.

Aside on how the Eclipse Platform is structured: The Eclipse Platform is divided up into Core and UI. Anything classified as Core is independent of the window system; applications and plug-ins that depend on the Core and not on the UI can run headless. The distinction between Core and UI does not align with the distinction between API and non-API; both Core and UI contain API. The UI portion of the Eclipse Platform is known as the Workbench. The Workbench is a high-level UI framework for building products with sophisticated UIs built from pluggable components. The Workbench is built atop JFace, SWT, and the Platform Core. SWT (Standard Widget Toolkit) is a low-level, OS-platform-independent means of talking to the native window system. JFace is a mid-level UI framework useful for building complex UI pieces such as property viewers. SWT and JFace are UI by definition. The Java tooling is a Java IDE built atop the workbench. End aside.

API Packages  API packages are ones that contain classes and interfaces that must be made available to ISVs. The names of API packages need to make sense to the ISV. The number of different packages that the ISV needs to remember should be small, since a profusion of API packages can make it difficult for ISVs to know which packages they need to import. Within an API package, all public classes and interfaces are considered API. The names of API packages should not contain internal , tests , or examples to avoid confusion with the scheme for naming non-API packages.

Internal Implementation Packages  All packages that are part of the platform implementation but contain no API that should be exposed to ISVs are considered internal implementation packages. All implementation packages should be flagged as internal , with the tag occurring just after the major package name. ISVs will be told that all packages marked internal are out of bounds. (A simple text search for ".internal." detects suspicious reference in source files; likewise, "/internal/" is suspicious in .class files).

Test Suite Packages  All packages containing test suites should be flagged as tests , with the tag occurring just after the major package name. Fully automated tests are the norm; so, for example, org.eclipse.core.tests.resources would contain automated tests for API in org.eclipse.core.resources. Interactive tests (ones requiring a hands-on tester) should be flagged with interactive as the last package name segment; so, for example, org.eclipse.core.tests.resources.interactive would contain the corresponding interactive tests.

Examples Packages  All packages containing examples that ship to ISVs should be flagged as examples , with the tag occurring just after the major package name. For example, org.eclipse.swt.examples would contain examples for how to use the SWT API.

Additional rules:

  • Package names should contain only lowercase ASCII alphanumerics, and avoid underscore _ or dollar sign $ characters.

Classes and Interfaces

Sun's naming guidelines states

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words - avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
 
Examples:
    class Raster;
    class ImageSprite;
 
Interface names should be capitalized like class names.

For interface names, we follow the "I"-for-interface convention: all interface names are prefixed with an "I". For example, "IWorkspace" or "IIndex". This convention aids code readability by making interface names more readily recognizable. (Microsoft COM interfaces subscribe to this convention).

Additional rules:

  • The names of exception classes (subclasses of Exception) should follow the common practice of ending in "Exception".

Methods

Sun's naming guidelines states

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
 
Examples:
    run();
    runFast();
    getBackground();
Additional rules:
  • The named of methods should follow common practice for naming getters (getX()), setters (setX()), and predicates (isX(), hasX()).

Variables

Sun's naming guidelines states

Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.
 
Variable names should be short yet meaningful. The choice of a variable name should be mnemonic - that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.
 
Examples:
    int i;
    char c;
    float myWidth;

(Note: we are no longer following the convention that prefixes non-constant field names with "f", such as "fWidget".)

Constants

Sun's naming guidelines states

The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_").
 
Examples:
    static final int MIN_WIDTH = 4;
    static final int MAX_WIDTH = 999;
    static final int GET_THE_CPU = 1;

Plug-ins and Extension Points

All plug-ins, including the ones that are part of the Eclipse Platform, like the Resources and Workbench plug-ins, must have unique identifiers following the same naming pattern as Java packages. For example, workbench plug-ins are named org.eclipse.ui[.*] .

The plug-in namespace is managed hierarchically; do not create plug-in without prior approval from the owner of the enclosing namespace.

Extension points that expect multiple extensions should have plural names. For example, "builders" rather than "builder".


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire