Community
Participate
Working Groups
As discussed we need methods to bridge between the Java Model and ASTs. IJavaElement[] JavaCore#create(IBinding[]) IBinding[] AST.create(IJavaElement[]) ASTNode AST.create(IJavaElement[])
Dirk, can you please make sure that all assumptions are correct, and answer the questions below ? 1. IJavaElement[] JavaCore#create(Binding[]) - all Bindings come from the same compilation unit - they were built using an ICompilationUnit element (i.e. ASTParser#setCompilationUnit(...) was used) 2. IBinding[] AST#create(IJavaElement[]) - all Java elements come from the same compilation unit - their project's options are used - the default working copy owner is used - the API level cannot be specified here. Could we put this API on ASTParser instead ? - this API should take an IProgressMonitor as well 3. ASTNode[] AST#create(IJavaElement[]) - you meant returning an array of ASTNodes, right ? - all Java elements come from the same compilation unit - no resolution is needed - same as above: this API would make more sense on ASTParser. Do you agree ?
1. IJavaElement[] JavaCore#create(Binding[]) - we have bindings from arbitrary compilation units we want to convert to Java elements (an example is the ripple method finder were we have to convert the leaf types into bindings). - currently I think 99% of the ASTs were built from an ICompilationUnit. What will happen if the call this method for a binding created from a char array given that a corresponding Java element exists. 2. IBinding[] AST#create(IJavaElement[]) - we have Java elements from arbitrary compilation units we want to convert into bindings. - if we move the API to ASTParser can't we get more control of compiler options and working copy owners ? - agree on the IProgressMonitor 3. ASTNode[] AST#create(IJavaElement[]) - you meant returning an array of ASTNodes, right ? YES - I think this can be limited to one compilation unit since creating to many ASTs via this method might be a big memory problem. - what do you mean with no resolution is needed ?
1. IJavaElement[] JavaCore#create(Binding[]) > we have bindings from arbitrary compilation units we want to convert to > Java elements (an example is the ripple method finder were we have to convert > the leaf types into bindings). OK. I'll make sure that the code doesn't assume that all bindings come from the same CU. > currently I think 99% of the ASTs were built from an ICompilationUnit. What > will happen if the call this method for a binding created from a char array > given that a corresponding Java element exists. If an AST was built using ASTParser.setSource(char[]), we cannot know where this source come from, and we cannot create an IJavaElement (we would not know the parent IPackageFragmentRoot of this IJavaElement) So in this case null would be returned. 2. IBinding[] AST#create(IJavaElement[]) > we have Java elements from arbitrary compilation units we want to convert > into bindings. OK. I'll make sure that the code doesn't assume that all Java elements come from the same CU. > if we move the API to ASTParser can't we get more control of > compiler options and working copy owners ? Yes, you could use ASTParser#setCompilerOptions(...) and setWorkingCopyOwner (...) 3. ASTNode[] AST#create(IJavaElement[]) > I think this can be limited to one compilation unit since creating to many > ASTs via this method might be a big memory problem. OK. I'll keep the assumption that all Java elements come from the same CU. > what do you mean with no resolution is needed ? I meant that you're not going to ask for the bindings of the created ASTNodes, right ?
>If an AST was built using ASTParser.setSource(char[]), we cannot know where >this source come from, and we cannot create an IJavaElement (we would not >know the parent IPackageFragmentRoot of this IJavaElement) >So in this case null would be returned. Returning null in this case is fine with me. We should spec in the API that if the binding was created from a compilation unit the value will not be null. >> what do you mean with no resolution is needed ? >I meant that you're not going to ask for the bindings of the created >ASTNodes, right ? We would like to ask for bindings. Can't this be controlled via the flag resolve bindings we pass to ASTParser
> We would like to ask for bindings. Can't this be controlled via the flag > resolve bindings we pass to ASTParser OK, I'll make sure to honnor this flag.
Dirk, for the first bridge (creating Java elements from bindings), do you mind if we move the functionality to IBinding ? It would be something like IBinding#getJavaElement() and it would return null if no Java element can be created.
Does this have a performance impact if I convert more than one binding into a JavaElement? If not then I am fine with only having this method on IBinding.
No this won't have any performance impact.
Added IBinding#getJavaElement()
Tests in ASTModelBridgeTests
Dicussed with Philippe and we agree on that for consistency JDT/Core should offer a method that converts IJavaElements to Bindings. However, JDT/Cores implementation will be based on the compiler pipeline. To decouple work, JDT/UI will implement its own helper method using the compiler pipeline which down the road can be replace with the JDT/Core method.
Regarding my last comment: this isn't true since using the AST parser requires that we have source. However there can be Java model elements for which we need binding even if we don't have the source for them. Creating a fake CU which references the element is a workaround but becomes complicated with methods, generics, ... Can we consider an API that converts IJavaElements into bindings for M5 ?
Added API ASTParser#createBindings(IJavaElement[],IProgressMonitor) to create the DOM bindings for the given Java elements. Corresponding tests are in ASTModelBridgeTests#testCreateBindings*
Dirk, do you still need to create ASTNodes from IJavaElements ?
We are using the API on ASTParser know. For me this API is sufficient. What does the rest of the JDT/UI team think ?
It seems sufficient for me as well. Ast nodes are only required for ast rewrite in which case the API on AstParser can be used.
The step ISourceReference -> AST node is still a bit cumbersome. We have a class NodeFinder that finds a node by range, but it is internal. Clients have to copy this class. I think it would be a good idea to make the NodeFinder API.
Nothing more planned on this front for 3.1. Please open sepate feature requests if you need more.
Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD.
