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

Bug 340859

Summary: Injection of generics using type matching
Product: [Eclipse Project] Platform Reporter: Oleg Besedin <ob1.eclipse>
Component: RuntimeAssignee: Oleg Besedin <ob1.eclipse>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: ob1.eclipse, remy.suen
Version: 4.1   
Target Milestone: 4.2 M1   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Sample JUnit
none
Sample JUnit 2
none
Patch for key from descriptor - untested
none
Patch none

Description Oleg Besedin CLA 2011-03-24 10:11:24 EDT
Created attachment 191824 [details]
Sample JUnit

In order to inject a value from a context using class type matching, the types must match exactly. We won't inject a subtype.

This gets somewhat problematic for generics. While "@Named" works well, injection using type matching will require exact match between the type description in the context and type being injected.

Attached is a sample JUnit that demonstrates the issue.

I am not sure if it is possible to provide such matching without incurring significant performance overhead. I am opening this bug both to have the record is this issue and in case anybody has an idea on how such matching can be implemented in a reasonably efficient form.
Comment 1 Remy Suen CLA 2011-03-28 09:12:06 EDT
Created attachment 191999 [details]
Sample JUnit 2

This is the problem I was seeing. I don't think it is the same problem as the one you have in your attachment 191824 [details], Oleg.
Comment 2 Oleg Besedin CLA 2011-03-28 13:58:04 EDT
(In reply to comment #1)
> This is the problem I was seeing. I don't think it is the same problem as the
> one you have in your attachment 191824 [details], Oleg.

Thanks for the sample!

At the core, it is the same issue. Injection of generics using type matching is not implemented. It might be possible to force it work for a specific example (and it might seem to work for some examples thanks to our auto-create functionality) but basically, it is not supported at he moment.
Comment 3 Oleg Besedin CLA 2011-03-28 14:04:50 EDT
Created attachment 192031 [details]
Patch for key from descriptor - untested

An untested patch that creates String description based on a parameterized type (generics).

This patch is not meant to be applied "as is", this is just a note for future use.

Note that the "other" side - the IEclipseContext#set() methods - would have to changed as passing "Class<>" won't work.

Another approach could be to add something like type erasure making "ClassABC<Type XYZ>" treated like "ClassABC". That is doable, but feels unsafe.
Comment 4 Oleg Besedin CLA 2011-06-17 14:52:35 EDT
Created attachment 198206 [details]
Patch

After some reflection on the subject - yes, let's use type erasures.

Just like Java does, the "Feeder<Bird>" will be treated as "Feeder" when looking up unnamed matches in the context.

Matching by type is inherently not safe, adding type erasures will only marginally influence that.

And having type erasures mimics Java behavior eliminating the need to introduce some custom rules.

(The JUnits are rolled into this patch.)
Comment 5 Oleg Besedin CLA 2011-06-24 09:35:51 EDT
Patch applied to CVS Head.