Community
Participate
Working Groups
With the regular JDT AST support, you can call setResolveBindings(true) on the AST parser in order to be able to get more information about the types encountered, e.g.: org.eclipse.jdt.core.dom.ASTParser parser = org.eclipse.jdt.core.dom.ASTParser.newParser(AST.JLS3); parser.setResolveBindings(true); parser.setSource(ajcu); org.eclipse.jdt.core.dom.CompilationUnit cu = (org.eclipse.jdt.core.dom.CompilationUnit) parser.createAST(null); cu.accept(new org.eclipse.jdt.core.dom.ASTVisitor() { public boolean visit(org.eclipse.jdt.core.dom.SimpleName node) { System.out.println("simplename id: "+node.getIdentifier()); final org.eclipse.jdt.core.dom.ITypeBinding binding= node.resolveTypeBinding(); System.out.println("binding: "+binding); return true; } }); See the javadoc for setResolveBindings for more info. You can only do this when the source code comes from a CompilationUnit or in the context on an IJavaProject. But neither option is possible with the org.aspectj version of the parser, because you cannot obtain org.aspectj versions of ICompilationUnit or IJavaProject.
check what happens in this area when we move to the new compiler with the Ast moved around.
In AspectJ1.6.0 the Ast stuff has moved around a bit due to upgrading the compiler, but I doubt this works yet...
I've had a quick read of the javadoc Matt points to - I think this will be hard to implement as per the JDT model. But there may be a compromise we can do - however I need to see more real use cases and examples before I can decide if the compromise is reasonable and I don't have any clue how to write one :) Contributions please.
For my own project, I have a tool that analyzes Java code. By using the Eclipse compiler, I can leverage many of it's features and save myself a lot of hassle. I would like my tool to work on AspectJ, but that's just not going to be a reality if it can't resolve types. As far as compromises go, if there's some way I can resolve the type of the expression, but maybe it's a different AspectJ-specific type description, then that's OK. (That is, it doesn't need to by the same as ITypeBinding, but naturally that would be the most helpful.) Without support for such a basic requirement as parsing a file and resolving types, I don't see how anyone could build on top of AspectJ. In other words, there are hundreds of examples of where this could really help!
I'm working on a tool refactoring support in an aspect oriented context. For some refactorings, resolving types are indispensable. I know people that have done some work on this, but all of them have workaround this problem implementing a poor support to solve the bindings issue for a specific case. It will simplify our lives if we have a good support for parsing a file and resolving its types independently of it be an aspect or a java class.
nice to have all the votes and comments.... but does anyone have any testcases they want to see working? I have no idea how to programmatically use the AST in this way, and I don't see the value in me 'making up' the use cases. > In other words, there are hundreds of examples of where this could really help! can i have a link?
Hi Andy, Sorry the delay, I was busy with my job. I think we can start with a similar support we already have for Java platform adding, in binding resolver, support to resolve Aspect bindings, including inter-type declarations, advices, etc. I'm pretty new in eclipse base code, so as soon as I get confident with this stuff I will try to help you testing and improving this support for resolving type bindings. Please, let me know everything you are doing on this. Thanks, Fernando
i'm still waiting on a test program before I take a cursory look at what can be done here. I am concerned it will be very complex, but without an example of what users want to do with the the type information they will have access to, I don't want to assume anything.
Mostly, I use it to look at expressions declared in the program and see if the type matches some other type given (e.g., given by the user). Here's some code samples taken from my uses of it: <pre> IBinding binding = name.resolveBinding(); if (binding.getKind() == IBinding.VARIABLE) { IVariableBinding var = (IVariableBinding)binding; if (var.isField()) { target = extractTarget(name, var); declaringClass = var.getDeclaringClass(); fieldName = var.getName(); } else return false; } TypeDeclaration declaration = (TypeDeclaration)node; ITypeBinding binding = declaration.resolveBinding(); String qualifiedName = binding.getQualifiedName(); table.put(qualifiedName, node); Type type = (Type)node; ITypeBinding binding = type.resolveBinding(); return binding.isClass(); ITypeBinding binding = type.resolveBinding(); return binding.isInterface(); public static ITypeBinding declaredClassOf(FieldDeclaration field) { TypeDeclaration fieldOwner = (TypeDeclaration)field.getParent(); return fieldOwner.resolveBinding(); } IVariableBinding binding = var.resolveBinding(); if (binding == null) return null; ITypeBinding type = binding.getType(); return type; </pre> The interfaces IBinding and ITypeBinding have a lot of methods, but I imagine the AspectJ compiler would have to know all of them anyway. If an AJDTBinding.isEqualTo method needs to be called to resolve what is (likely?) the hardest case, due to integration with Eclipse, then that would be fine for my needs.
what are the current status of this enhancement. Are you guys planning to do this for milestone 1.6.3? or it will keep migrating the target milestone. Thanks in advance, Fernando
currently it is not likely to make 1.6.3. If a bug or enhancement has a milestone it means it is a candidate for work to be done in that release. if the target is blank it means I currently have no plans at all to look into it. I did look into this again recently and again it proved non-trivial - and since then other work has taken priority.
unsetting the target field which is currently set for something already released
