Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 379573

Summary: [Compatibility] Global selection in evaluation context is no longer a java.util.Collection
Product: [Eclipse Project] Platform Reporter: Zeb Ford-Reitz <zeb.ford-reitz>
Component: UIAssignee: Paul Webster <pwebster>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ob1.eclipse
Version: 4.2Flags: ob1.eclipse: review+
Target Milestone: 4.2 RC1   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Bug Depends on:    
Bug Blocks: 378478, 379122    

Description Zeb Ford-Reitz CLA 2012-05-15 11:54:06 EDT
From http://wiki.eclipse.org/Command_Core_Expressions:
----------------------------------------------------
The IEvaluationContext provides a default variable for evaluations, and a number of named variables. In the command framework, we provide the global selection as a java.util.Collection as the default variable. It can either be empty, have one entry (if the ISelection was something like an ITextSelection), or have the contents of an IStructuredSelection.
----------------------------------------------------

Our product has based some property testers and expressions on the stated fact that the global selection provided by the evaluation context is an instance of java.util.Collection (the property tester's "type" attribute is java.util.Collection). This seems to have changed in 4.2, as I am currently seeing an instance of org.eclipse.jface.viewers.TreeSelection instead. As a result, our expressions are not being evaluated. This raises a few questions:
 * Is this considered API? I could only find mention of it at the above-listed wiki page, where it was mentioned only in passing. Perhaps this was simply a hint about an implementation detail.
 * Is there a way to change the type and evaluation of our property testers such that they will be able to work regardless of whether the evaluation context provides a Collection or a TreeSelection (the contained objects as a whole are interesting for the evaluation, not the type of the container). Perhaps we can use "adapt" in our expressions?
Comment 1 Paul Webster CLA 2012-05-15 13:35:27 EDT
You are correct, this is an oversight.

While <adapt type="org.eclipse.core.expressions.IIterable"><test property.../></adapt> would be a workaround that's valid in 3.x and 4.x, adapting to that would allow your property tester to get a java.util.Iterator as opposed to a list or array.  I wouldn't recommend this.

PW
Comment 2 Paul Webster CLA 2012-05-15 14:18:06 EDT
Oleg, can I get you to review my change.  It's on pwebster/bug379573 or http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=pwebster/bug379573

PW