Bug 40096 - [plan][DCR] possibility to create ITypeBinding on demand
Summary: [plan][DCR] possibility to create ITypeBinding on demand
Status: RESOLVED DUPLICATE of bug 150657
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.3   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-15 07:46 EDT by Martin Aeschlimann CLA
Modified: 2007-02-01 11:48 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2003-07-15 07:46:58 EDT 
M2

As we use the AST infrastructure more and more we come to its limitations. Lot
of code that was previously done using IJavaElements is moved to use the AST due
to 100% precisness. That means more and more utility functions change to ues
ITypeBindings as input and output.

A problematic limitation is that I can't create a ITypeBinding on demand. I have
methods that return ITypeBinding as result and currently can not do that as
there type is not in the AST:
e.g. ITypeBinding[] getAssignableTypes(ITypeBinding binding)
what's possible:
   binding == ArrayList: result is List, Collection...
what's not:
   binding == ArrayList[]: result would be List[], Collection[]... 

So to solve this I have either have to switch to String[] or IType[] as result
and loose all the precisness. 
All transformations from IJavaElement to ASTNodes have to be minimized  as they
are expensive and introduce errors (e.g. because there are no local types in the
JavaModel)

Other problem: No way to get the subtypes: Of course I don't expect to get the
subtypes directly from the type binding, but I would pass in a progress monitor
for the creation.
Comment 1 Philipe Mulet CLA 2003-07-16 07:53:12 EDT 
The reason these functionalities aren't available is that they have a huge 
memory footprint. In order to compute more bindings lazily, we have to retain 
all our bindings cache in memory, in case you decide to bind one more type...

Similarily, computing a subtype hierarchy is always doable using the model APIs.

Nothing is free on this side.
Comment 2 Martin Aeschlimann CLA 2003-07-16 08:04:26 EDT 
It doesn't has to be cheap. I'd be ok it bindings cache has to be rebuild.
That's still better than having nothing.

Using the model API is, if you are already in IBinding world, loss of
precission. No local, no anonymous types. Tricky code to get a IType from a
ITypeBinding and back.
Comment 3 Philipe Mulet CLA 2003-07-22 07:25:48 EDT 
> It doesn't have to be cheap.
Until later on you log a defect about the fact that during profile, 80% time is 
spent in this area <g>
Comment 4 Philipe Mulet CLA 2004-03-25 05:58:23 EST 
Not for 3.0
Comment 5 Markus Keller CLA 2004-10-01 13:49:50 EDT 
Could this PR please be reconsidered for 3.1? IMO, it would be sufficient if
clients could just 'compose' existing bindings to form new ones, e.g.:

Integer --> Integer[]
List --> List<?>
List, Number --> List<Number>
List, Number --> List<? extends Number>
List, Number --> List<? super Number>
Comment 6 Dirk Baeumer CLA 2004-10-28 06:33:33 EDT 
Philippe, can we do something here ?
Comment 7 Jerome Lanneluc CLA 2005-10-04 06:00:10 EDT 
Considering for 3.2
Comment 8 Olivier Thomann CLA 2006-06-06 11:30:21 EDT 
Considering for 3.3.
Comment 9 Olivier Thomann CLA 2007-02-01 11:48:11 EST 
This request is now part of bug 150657.

*** This bug has been marked as a duplicate of bug 150657 ***