Bugzilla – Full Text Bug Listing
| Summary: | Adopt J2SE 5.0 in Query Component | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF Services | Reporter: | Christian Damus <give.a.damus> | ||||
| Component: | Query | Assignee: | Christian Damus <give.a.damus> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | Ed.Merks | ||||
| Version: | unspecified | Keywords: | api, plan | ||||
| Target Milestone: | --- | Flags: | Ed.Merks:
review+
|
||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Christian Damus
Created attachment 80842 [details]
First pass at adopting J2SE 5.0-isms
Attached a patch implementing a first pass at adopting J2SE 5.0 language features and APIs. This patch deals with generic types.
Hi, Ed, when you get a chance, could you review the attached patch? I had briefly considered add an <E extends EObject> type parameter to the EObjectCondition class indicating the type of object matched by the condition, and propagating that through the WHERE clause into the SELECT statement, so that clients would be able to declare the result type of a query (e.g., SELECT<Book> would return an IQueryResult<Book> providing an Iterator<Book> to get the results). That idea didn't last long, as I quickly realized that most queries would want to be able to handle dynamic EMF, as well, which doesn't have the convenient type system of statically generated APIs, so clients would have to declare everything as <EObject> anyway. Any other ideas for types/operations that should be generic would be most welcome. I only looked at that org.eclipse.emf.query plugin. It looks good to me. My only very minor concern is that the code assumes that all generated APIs explicitly extend EObject in their API. E.g., if I have a List<Library> and Library doesn't extend EObject, I can't pass it to List<? extends EObject> without casting; but I think that's okay; after all, EMF has many EObject methods and you'd have to cast to EObject to call them. I just want to be sure it's an explicit decision on your part. Thanks, Ed. There wasn't any other plug-in to look at ... the rest is really just noise :-) Yes, it did actually occur to me that APIs generated without the EObject interface would require lots of unchecked casts in client code. However, the whole point of the generic declarations is to promote type safety, so it's essential that the API only accept inputs that actually are EObjects, because it needs the services provided by EObject. I think that in a J2SE 5.0+ world of generics, users of EMF would best be advised to explicitly extend EObject for this reason. Otherwise, they will never have code that the compiler can assure them is type safe! Committed the changes to CVS HEAD (1.2 branch). Fixed in the EMF QUERY 1.2.0 I200711141410 build. Move to verified as per bug 206558. |