Eclipse 3.5 - New and Noteworthy

You can now create new instances of the Properties view from an existing one. The existing one will be pinned to the contents it is currently displaying and the new view will be set to follow the workbench's selection.

• The Go to Line action added to the context menu allows for rapid navigation
• The current text selection will be used to populate the filter field of the Open Type and Open Resource dialogs
• The current line is now highlighted in each viewer
• Background and foreground color preferences are now honored
• The Set Encoding... action has been added to the context menu. This allows you to change the encoding of each side of the comparison

You can also switch between content-specific merge viewers; for example when an alternative Java compare viewer is available, you can use it instead of the default one.

For example, you can now check for software updates in one step using Help > Check for Updates. This menu command will check for updates (in the foreground or background depending on your General > Always run in background preference), and launch the software updates wizard if updates are available.

Some of the most common workflow and usability complaints have also been addressed:

• The wizard will now open immediately without waiting to connect to any update sites. This makes the view itself much more responsive once the wizard is opened.
• A description field has been added to the page to show more information about the selected item.
• You can now change many selections at once without computing the install results on each change. Once you've selected the items to install, the Next button will take you to the review page. If there is an error or you otherwise want to change your selections, you can now go back and change the selections in the first page, and the resulting changes won't be computed until you move forward again.

Only the content for a newly added site will be shown, making it simpler to find what you want to install. You can also use the combo to change the filtering of the available software by any site. The wizard has also been streamlined by placing the links to other views closer to the relevant information in the wizard.

A new checkbox at the bottom of the page lets you control whether all sites will be used when searching for the new software's requirements, or whether only the site selected will be consulted. Previously, all sites were always used when gathering the requirements.

The update wizard has also been reorganized so that you can change your update selections in a separate selection page. When available updates are shown, the wizard will open directly on the details page.

From this page, use the wizard < Back button to see all of the possible update proposals and change the selections.

This preference page also allows you to define your own name for available software sites. Names can be defined when adding a new site, or edited from the available sites preference page. If you don't provide a name, the name defined by the site itself will be used.

These changes apply to all textual editors in the SDK.

To enable it either use Alt+Shift+A or activate the 'Editor Presentation' action set to get a tool bar button for toggling the block selection mode.

Each element in the breadcrumb can be selected and actions can be invoked through a context menu or keyboard short cuts.

Finally, a drop-down menu allows navigating to a new element and changing the active debug context.

If the class is not already imported (as shown in the example above), then the corresponding import will also be added.

You can configure the modifier for this hyperlink on the General > Editors > Text Editors > Hyperlinking preference page.

For example, the wrapped lines of the return statement in following test case:

will be preserved by the formatter when the Never join lines preference is used and now produces the following result:

This preference can be configured on the Java > Code Style > Formatter preference page. See the Never join lines option on the Line Wrapping and Comments tab.

You can configure this setting in the Potential programming problems section on the Java > Compiler > Errors/Warnings preference page, or by clicking the Configure Problem Severity button in the problem hover toolbar.

You can either use the quick fix to override the hashCode() method or the quick fix to regenerate both methods.

This problem is not reported by default. You can enable it on Preferences > Java > Compiler > Errors/Warnings in the Potential programming problems section.

For instance, if (false) foo(); is not reported as truly unreachable code by the Java Language Specification. When this diagnostic is enabled, the invocation of foo() is signaled as dead code:

This problem is reported as a warning by default. You can configure the problem severity on Preferences > Java > Compiler > Errors/Warnings in the Potential programming problems section

Note that dead code following an if (constant variable) statement, e.g. if (DEBUG), is not reported.

For example, 'nested.jar' is a referenced library although it was not explicitly specified in the project build path but through the manifest of 'lib.jar':

For example, two user libraries used in the project build path referring to the same JAR file are tolerated:

Note that as of 3.5, an execution environment is the first choice when creating a new Java project or a launch configuration.

This action replaces the normal children of the method with

• the constructors of the method's declaring class
• a node that contains the direct callers of the method.

Some methods (e.g. java.lang.Runnable#run()) are expanded with constructors by default. The defaults can be configured in the view menu.

Moreover, the message for deprecated elements now shows up on top, and relative links are supported (for example, to embed images from the "doc-files" directory or to link to {@docRoot}).

The Open JAR Packager... action in the context menu is gone.

If the files are not inside your workspace, you can still open them from the JUnit view via the Test Run History... drop-down menu. And the Import... and Export... actions now always start at the most recently used location.

The advantage of the second and third options is that the required libraries will just be copied and don't need be repackaged.

For backwards compatibility reasons, existing subclasses of FilteredTree will not get the new look automatically. Clients of the FilteredTree are encouraged to switch to the new look as recommended in the porting guide.

The example below shows this checkbox added to the What's New page.

Pushing this button will launch a dialog that shows all of the installation pages contributed by plug-ins in a single Installation Details dialog. Plug-ins may contribute installation pages and define buttons that operate on the information in the installation page.

The new extension point is org.eclipse.platform.ui.installationPages. Example implementations can be found by browsing the hierarchy of org.eclipse.ui.about.InstallationPage.

• Each link has a label.
• The images are transparent and will display well if a background is added using an extension.
• The page displays well at high screen resolutions.

Non root pages also have a label for each link.

The Service Hooks Specification is targeted at bundles which need to observe and react to selected service layer operations. In general these will be highly specialized bundles written by systems programmers. The is not intended to be used by so-called "normal" application bundles. For more information see the OSGi Release 4 Version 4.2 specification.

• The Java-SE Service Provider Configuration model.
• Get it from some configuration and use Class.forName.
• Hardcode the factory name.

This Release 4, Version 4.2 specification also defines standard configuration properties which all framework implementations must recognize. This allows for a generic framework launcher to be implemented that can launch any framework implementation. For more information see the OSGi Release 4 Version 4.2 specification.

• The definition of the Service-Component header now uses the definition of a header from the module layer. It also allows wild-cards to be used in the last component of the path of a header entry.
• The DS runtime now follows the recommendations of Property Propagation and does not propagate properties whose names start with '.' to service properties.
• The component description now allows for a configuration policy to control whether component configurations are activated when configuration objects are present or not.
• The component description now allows the names of the activate and deactivate methods to be specified. The signatures of the activate and deactivate methods are also modified.
• Additional signatures of the bind and unbind methods have been added.
• The definition of accessible methods for activate, deactivate, bind and unbind methods is expanded to include any method accessible from the component implementation class. This allows private and package private method declared in the component implementation class to be used.
• The XML schema and name space have been updated to v1.1.0. It now allows for wild-carded attributes and elements for extensibility. The name attribute of the component element is now optional and the default value of this attribute is the value of the class attribute of the nested implementation element. The name attribute of the reference element is now optional and the default value of this attribute is the value of the interface attribute of the reference element. The Char type for the property element has been renamed Character to match the Java type name. The attributes configuration-policy, activate and deactivate have been added to the component element.
• When logging error messages, SCR now uses a LogService obtained using the component's bundle context so that the resulting log entry is associated with the component's bundle.
• Target properties are now component properties that can be set wherever component properties can be set, including configurations.

For more information see the OSGi Release 4 Version 4.2 specification.

org.osgi.framework.Bundle#getVersion()

Returns the Version of a bundle.

org.osgi.framework.Bundle#getSignerCertificates()

Returns the signers of a bundle.

org.osgi.framework.BundleException#getType()

Returns the error type for a BundleException. For example, a resolver error.

org.osgi.framework.BundleReference

Interface which must be implemented by bundle classloaders. This gives clients the ability to determine what bundle a ClassLoader is for.

org.osgi.framework.Constants

A number of new constants have been added to define standard launching configuration properties.

org.osgi.framework.FrameworkEvent

A number of new FrameworkEvent types have been added give launchers standard notification when a framework is stopped or restarted.

org.osgi.framework.FrameworkUtil#getBundle(Class)

Utility to get a Bundle object for a given class. A static method equivalent to the PackageAdmin#getBundle(Class) method.

org.osgi.framework.FrameworkUtil#matchDistinguishedNameChain(String, List)

Utility to match a certificate chain against a pattern. This is used for permission and condition checks against signed bundles.

org.osgi.framework.ServiceEvent

A new ServiceEvent type has been added to indicate the properties of a registered service have been modified and the new properties no longer match a listener's filter.

org.osgi.framework.ServiceException

A new ServiceException type has been added to indicate that a service problem occurred.

org.osgi.util.tracker.BundleTracker

The BundleTracker class simplifies tracking bundles much like the ServiceTracker simplifies tracking services.

Conceptually a composite bundle is composed of a set of bundles which are contained in another (nested) framework instance. New API is introduced in the org.osgi.service.framework package to manage composite bundles. The CompositeBundleFactory service interface is used to install composite bundles. The CompositeBundle interface is used to manage the bundles which compose a composite bundle.

For more information see the OSGi Release 4 Version 4.2 specification.

Note: The API introduced in the org.osgi.service.framework package is a proposed OSGi API. This API is considered provisional in Equinox and may change drastically or be dropped altogether in a future release of Equinox. We encourage use of the API and any feedback on the specification, but consumers must be aware that breaking changes may occur in a future release.

The OSGi Declarative Services (DS) tooling has been enhanced to support the latest version of the DS specification. Specifically, a new modified attribute has been added to the component element.

A new template based on a simple dictionary service has been added to showcase Declarative Services tooling.

The standard properties file editor is now used for .options files in the workspace.

You can now initialize product definitions from OSGi launch configurations.

A new wizard (PDE Tools -& Internationalize...) supports the generation of NL fragments for plug-ins in the workspace. A project is generated for each selected plug-in containing skeleton properties files for each selected locale. The generated properties files contain the keys from each of the associated plug-in's properties files.

View information about menus by invoking Plug-in Spy in menu introspection mode (Alt+Shift+F2) and selecting a menu item.

The Plug-in Registry view now includes fragments. Simply expand a plug-in, and expand the Fragments element in the tree to see all available fragments of that plug-in.

It's simple to run and test your latest code by exporting and install plug-ins and features directly into the running workbench. Choose Install into host when exporting and specify a path in the local file system where exported artifacts can be stored (repository). You will be prompted to restart your workspace after export and install is complete.

Patched plug-ins will appear in the installed software list and can also be uninstalled.

Export options have been enhanced:

• Generate source bundles. Select the Export source option and choose Generate source bundles from the drop down menu. A source bundle will be exported for each plug-in being exported.
• Export features, plug-ins, and products with binary cycles. Binary cycles are cycles that exist in your target platform, not your workspace. This option is on by default.
• Export existing class files from the workspace. When this option is checked, PDE will re-use existing class files in the workspace rather than compiling class files from source during export.

The new Category Definition editor can be used to assign categories to features when exporting. The category names and descriptions will then appear in software selection dialogs. First, create a category definition file via File > New > Other... and select Plug-in Development > Category Definition. Define categories with symbolic identifiers, names, and descriptions, and then add features to each category.

When exporting your feature, specify the category file to apply when exporting via the Options tab.

The categories can then be seen when browsing the repository from the Install Software dialog.

The JAR signing support in PDE has been expanded to include support for keypasses.

API compatibility options have been reorganized and descriptions have been improved. The number of options has been reduced by combining related problems. For example, problems related to type parameters are now in their own group rather than being listed separately in the settings for classes, interfaces, and methods.

As well, you can be alerted to breaking API changes even if you have incremented the major version of your plug-in. The first time you change a plug-in's API in an incompatible way, problems inform you to increment the major version of your plug-in. Once you increment the major version of your plug-in, API tooling allows additional breaking API changes without warning. Use the new preference Report API breakage even if authorized by major version increment to enable this feature (on the Plug-in Development > API Errors/Warnings preference page, on the API Compatibility tab). When this preference is enabled you must use API problem filters to selectively permit incompatible API changes.

API tooling now supports two restrictions on interfaces: @noimplement and @noextend. This allows an interface to be extended when it is not intended to be implemented directly. For example, a client may be permitted to subclass an existing implementation of a @noimplement interface and extend the base interface with extra function.

Component owners should decide where to add @noextend tags on existing interfaces, as this was previously implicit. To maintain the API contracts specified in 3.4, @noextend tags can be added to all interfaces specified as @noimplement. In some cases the @noextend restriction can be omitted, as clients that extend and implement a @noimplement interface will still be flagged with errors. However, if you would like to reserve the right to add constants to an API interface in the future, you must add the @noextend tag. This is because adding a field to an interface is binary incompatible if clients can extend or implement an interface (see Evolving API Interfaces).

The API Use tab of the API Errors/Warnings preference page displays installed execution environments. Use the "install them now" hyperlink to install additional environments via the software updates dialog.

API tooling creates warnings for problem filters that are no longer needed. API problem filters often become stale because they are used to filter known incompatibilities between two specific releases. A quick fix is available to remove stale filters.

Ant tasks to perform API analysis and generate simple HTML reports are now available. These are the same Ant tasks used in the Eclipse SDK build. Documentation for each task is available in the Reference section of the Plug-in Development Environment Guide.

You can now view API changes relative to an API baseline. Select a project or package in the Package Explorer and choose Compare With > API Baseline. Specify the API baseline you wish to compare against and press OK. The API Tooling view will summarize the API changes.

PDE/Build determines compilation order by sorting plug-ins according to their dependencies. Previously, this sorting was only done within a single feature and features were compiled depth first in the order they were included.

flattenDependencies=true

If plug-ins are sorted across feature boundaries (see above), PDE/Build can also group plug-ins allowing for parallel compilation.

parallelCompilation=true

           p2.gathering = true
     

Setting this property will use the p2 publisher to gather up your bundle and publish it into a build specific repository.

For product builds, this will automatically perform a director install to create the final product archives. If you also set the p2.metadata.repo and p2.artifact.repo properties then build will mirror the resulting product metadata into those repositories.

For Feature builds, this will create a p2 repository for the final archive. This also has the effect of setting groupConfigurations=true and outputUpdateJars=true.

When building products using p2.gathering=true, PDE/Build will now replace the ".qualifier" on the version specified in a .product file used in a product build. Set the property p2.product.qualifier to be the qualifier you wish to use.

If no value is specified, the default will be either the value of forceContextQualifier or the default timestamp.

The map file entry needs to include the id and version of the installable unit (IU), and the URI of the repository where the IU can be found. The metadata and artifact repositories are assumed to be co-located. An example (needs to be on one line) is:

plugin@my.bundle.id,1.0.0=p2IU,id=my.bundle.id,version=    1.0.0,repository=http://example.com/repo

You can now specify a location that contains local p2 repositories in nested folders or zip files. The build will automatically transform the repositories into a form that PDE/Build can compile against.

There is a new processRepos phase in the main build script with corresponding pre and post targets in the customTargets.xml file.

You must set these properties in the build.properties for your builder. The repoBaseLocation is the location of the folder containing the local p2 repositories. The transformedRepoLocation is the location where the transformed artifacts will be placed after being processed.

repoBaseLocation=${base}/repos
transformedRepoLocation=${base}/transformedRepos

The target platform preference page (Preferences > Plug-in Development > Target Platform) has been redesigned. The page allows the user to select the active target platform from all target definitions in the workspace. Target definitions can be created and edited from this page using a wizard or with the target definition editor. You can quickly switch between targets using the checkboxes. Targets can be composed of plug-ins originating from installations, directories, features, and software sites. See target definition concepts for more details on crafting targets.

To support new features, the underlying target file format has been enhanced. The new editor continues to read old target files, but only writes files in the new format.

The new Target Platform State view displays all the bundles used to build, run and debug plug-ins with. The state is built from the active target definition.