The new type of extension is identical to the original 'view' except for relaxing the requirement that the 'class' implement IViewPart.

For those that are unaware of the e4 way of coding, here's what the implementation of an e4 view looks like:

import javax.annotation.PostConstruct;
import org.eclipse.e4.ui.di.Focus;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Label;

public class RealE4View {
	Label label;

	@PostConstruct
	void createView(Composite parent) {
		label = new Label(parent, SWT.BORDER);	
		label.setText("Testing");
	}

	@Focus
	void setFocus() {
		label.setFocus();
	}
}
      

Note how it's a simple Java object (POJO) and how few dependencies it has; this has already proven itself as a far more convenient way to write the code and has great advantages in testing (because of its few dependencies).

• Accessing legacy platform Color and Font definitions from within a CSS style sheet:

  

• Overriding Color and Font definitions in a CSS style sheet:

  

• Adding new style definitions within your CSS that will be surfaced for user customization on the Color and Font preference page:

  

• The legacy color theme definitions overridden or added in the CSS style sheet are merged with the current theme.
• When switching themes, overridden values are re-merged with the new theme.
• The new definitions added with the CSS file (the last use case) are available in the CSS theme that provides it.

• The org.eclipse.core.resources.WorkspaceLock class.
• The method org.eclipse.core.resources.IWorkspace#setWorkspaceLock

• The method org.eclipse.core.resources.IncrementalProjectBuilder#getRule()

1. Update the Locale in the application context.
2. Inform all model elements of an application that implement MLocalization about the change.
3. Post an event via event broker.

1. Via event broker by listening to the topic org/eclipse/e4/core/NLS/LOCALE_CHANGE
2. Via dependency injection by getting the value for TranslationService.LOCALE injected (e.g. via method injection)
3. Via attaching to the model events listening to the newly introduced LOCALIZED-Features

As part of this work, the previously internal package org.eclipse.e4.core.services.translation has been released as API.

• DOS/Windows filesystems,
• POSIX compliant filesystems, and
• filesystems that are neither DOS/Windows nor POSIX compliant.

• Introduction of Service Scopes to the OSGi Service Registry (RFC 195)
• Improvements of Weaving Hooks (RFC 191)
• Clarification of hooks on the system bundle (RFC 198)
• Native environment namespace (RFC 188)
• Data Transfer Objects (RFC 185)
• Extension Bundle Activators (RFC 204)
• Addition of FrameworkWiring.findProviders - no RFC

For most consumers and developers this change should not be noticed. But, as documented in the wiki, there are four main areas of concern that the community should be aware of:

• The Framework no longer uses the old Equinox resolver API org.eclipse.osgi.service.resolver internally to resolve bundles.
• All Equinox Framework specific hook implementations are broken and will need to migrate.
• Removal of old style plug-in support. A compatibility fragment is available to add the support back.
• Removal of PlatformAdmin Service Implementation. A compatibility fragment is available to add support back.

The Equinox Regions has added a new namespace for sharing bundle lifecycle operations between regions. In previous versions of Equinox regions the only way to share bundle lifecycle operations across different regions was to share complete bundles which also shared all capabilities provided by the bundle. Now it is possible to use the org.eclipse.equinox.allow.bundle.lifecycle namespace to share only the bundle lifecycle operations between different regions. (see bug 418224)

debug/bundleTime

Prints out timing information for bundle activation

debug/cachedmanifest

Debug the caching of bundle headers

debug/location

Prints out location service debug information

debug/startlevel

Prints out start level service debug information

monitor/activation

Monitor persistent bundle activation

resolver/providers

Prints out information about matching capabilities returned to the resolver and why any were filtered out

resolver/hooks

Prints out information about capabilities or resources that were filtered by resolver hooks

resolver/uses

Prints out information about uses constraint violations

resolver/wiring

Prints out wiring information after the resolve process completes

resolver/report

Prints out the resolution report information

resolver

enables all resolver trace options

Snippet332 shows how to accomplish RTL override in a Combo.

JFace clients can use BidiUtils#applyBidiProcessing(...) to set pre-defined text types.

		Display.setAppName("APP_NAME"); // APP_NAME will used as AppUserModelID
		Display display = new Display();