Eclipse Project Oxygen (4.7) M6 - New and Noteworthy

Update: On macOS, a bug was found when running with a non-Retina display as main screen and a Retina display as secondary screen. If you're affected, please update the Eclipse SDK to a recent I-build (such as I20170318-2000) from
http://download.eclipse.org/eclipse/updates/4.7-I-builds/

The common reason behind this problem is the fact that not all methods of those collection types make use of generics in the way one might expect. As a result it is possible to create a Set<Short>, whose add(Short) method will only accept arguments of type Short, yet method remove(Object) will happily accept literally any argument, because the method's parameter has type Object.

Here is a code snippet that seems to add and remove the same element from the set, but at a closer look the remove call has no effect. What is difficult to see for the naked eye is now flagged by a new warning:

In a simple world, this would be all there is to say, but over time people have developed various code patterns that rely on these overly general signatures. Consider the following use of subtyping:

Depending on your coding style this may or may not be accepted as a legitimate short hand for:
if (n instanceof Short) set.remove((Short) n);
To reduce the churn caused by the new analysis, we developed some heuristics that filter out cases where types are "sufficiently similar", so the above goes unwarned.

As with any heuristic, there is no clear line. This implies that the compiler may show "unwanted" warnings, or filter out invocations that are in fact bugs. For the former case, @SuppressWarnings("unlikely-arg-type") will document the exception both for the user and for the compiler. For the latter case, we provide an option to tighten the rules, namely to apply strict type compatibility checks instead of said heuristics. For this extra scrutiny you may enable the sub-option Perform strict analysis against the expected type in Preferences > Java > Compiler > Errors/Warnings > Potential programming problems.

You can change this setting in the Comments section, under the Line width group:

PDE now supports the enhanced annotations and new usage options. It generates component properties from any Component Property Types that you may use in your component lifecycle methods. It also creates reference entries from @Reference annotations specified directly in @Component as well as annotated member fields. New reference event method signatures are also supported.

To enable this feature, go to Preferences or Project Properties > Plug-in Development > DS Annotations and check Generate descriptors from annotated sources.

Clients that use DecorationOverlayIcon will get HiDPI support for free. Subclasses of CompositeImageDescriptor will have to update their implementation of #drawCompositeImage(int, int) to use the new #drawImage(ImageDataProvider, int, int) method to draw the elements of the composite image.

protected void drawCompositeImage(int width, int height) {
	// draw overlay in top-right corner:
	ImageData imageData = myImageDescriptor.getImageData();
	drawImage(imageData, width - imageData.width, 0);
}
      

protected void drawCompositeImage(int width, int height) {
	// draw overlay in top-right corner:
	CachedImageDataProvider provider =
		createCachedImageDataProvider(myImageDescriptor);
	drawImage(provider, width - provider.getWidth(), 0);
}
      

Hint: Use CompositeImageDescriptor­#createCachedImageDataProvider(­Image­/ImageDescriptor) to create an ImageDataProvider. To calculate the width and height of the image that is about to be drawn, you can use CachedImageDataProvider­#getWidth()/­getHeight(). These methods already return values in SWT points, so that your code doesn't have to deal with device-dependent pixel coordinates.

APIs for Table header foreground color:
Table#getHeaderForeground()
Table#setHeaderForeground(Color)

APIs for Table header background color:
Table#getHeaderBackground()
Table#setHeaderBackground(Color)

For plug-in based products this means that the new org.eclipse.e4.core.di.extensions.supplier bundle needs to be added the list of included plug-ins. Feature based products should not notice the split.

Note: As part of the re-organization, org.eclipse.e4.core.di.extensions.EventUtils (only intended to be used for internal testing), was moved to org.eclipse.e4.core.di.internal.extensions.util.EventUtils in the new bundle.

public class MyPart {
		   
    // highest ranked service
	
    @Inject
    @Service
    MyOsgiService service;
			
}

public class MyPart {

    // all services sorted by ranking

    @Inject
    @Service
    List<MyOsgiService> service; 
		
}

public class MyPart {
		    
    // get the highest ranked service that has
    // the component property connection=online set		
	
    @Inject
    @Service(filterExpression="(connection=online)") 
    MyOsgiService service;
			
}

public class TestExpression {
   @Evaluate
   public boolean isVisible(EPartService partService,
          @Optional @Named("myValueToBeChecked") String myValueToBeChecked) {

      return "expectedValue".equals(myValueToBeChecked) &&
         !partService.getDirtyParts().isEmpty();
   }
}