Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 327293 - Event Admin should support Collection<String> type for property event.topics.
Summary: Event Admin should support Collection<String> type for property event.topics.
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Compendium (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.7 M3   Edit
Assignee: equinox.compendium-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-07 23:01 EDT by John Ross CLA
Modified: 2010-10-13 15:56 EDT (History)
1 user (show)

See Also:


Attachments
Patch 1 (3.09 KB, patch)
2010-10-07 23:05 EDT, John Ross CLA
tjwatson: iplog+
Details | Diff
Updated patch which creates proper sized array argument (3.08 KB, patch)
2010-10-11 23:02 EDT, BJ Hargrave CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Ross CLA 2010-10-07 23:01:01 EDT
Build Identifier: 

The EventHandlerWrapper currently recognizes types String and String[] for the event.topics property. It should also recognize type Collection<String> per 4.3.

Reproducible: Always
Comment 1 John Ross CLA 2010-10-07 23:05:28 EDT
Created attachment 180468 [details]
Patch 1

Tests for instanceof Collection. Attempts to convert to String[]. Catches ArrayStoreException and logs issue.
Comment 2 BJ Hargrave CLA 2010-10-11 23:02:10 EDT
Created attachment 180630 [details]
Updated patch which creates proper sized array argument 

I updated the patch to create the argument to toArray of the proper size. This avoids creating a throw away empty array and requiring toArray to create the proper sized array with Array.newInstance.
Comment 3 John Ross CLA 2010-10-12 11:28:54 EDT
I agree with this approach. 

I did it that way initially because this way left a warning (which you suppressed), and the code was in a section unlikely to present a noticeable performance hit despite the extra array creation. I wasn't comfortable with simply suppressing the warning before receiving some input. It was a close call whether or not to do it your way initially and leave the warning or the way I did it without the warning.

This is actually a good reinforcement of the role of generics and the impact of erasure. When I first looked at the updated patch, I immediately wanted to wail that we needed to catch a ClassCastException instead of an ArrayStoreException before settling down.

I'm going to obsolete Patch 1.
Comment 4 John Ross CLA 2010-10-12 11:29:32 EDT
Comment on attachment 180468 [details]
Patch 1

Obsolete in favor of the updated patch.
Comment 5 Thomas Watson CLA 2010-10-13 15:56:02 EDT
I released the updated patch from BJ (after updating copyright dates).  Thanks for the contribution John, I marked your original patch for the iplog.