Community
Participate
Working Groups
Build Identifier: M20110909-1335 I'm writing a plugin that uses the AST parser from org.eclipse.jdt.core.dom, resolving my types to ITypeBinding. When using ITypeBinding.getDeclaredMethods and friends, there's no way to specify that I also want the synthetic ones (for example those generated when inheriting and implementing a generic interface). I looked at IMethodBinding which explicitly skips synthetics and always returns false so either I have to use the full internal compiler (which the docs advice against) or guess the synthetics myself (which seems silly since they are actually there, but hidden by TypeBinding. I also noticed that the IType returned by an ITypeBinding includes synthetic methods (but using it would be awkward at best in my case). Reproducible: Always Steps to Reproduce: 1. Parse a class with ASTParser 2. Find a TypeDeclaration node 3. Browse methods with getDeclaredMethods()
Deepak, isn't there already a way which jdt/ui uses to get the synthetic methods (viz. for outline views, etc.)?
Hmm, looks like we don't show synthetic methods anywhere. Jay, can you check if returning the synthetic methods has side effects or is it safe? Code snippet: public interface LockEx<T> extends java.util.concurrent.locks.Lock { //extended lock method void lockEx(T t); } final class LockExImpl<T> extends java.util.concurrent.locks.ReentrantLock implements LockEx<LockExImpl> { public void lockEx(LockExImpl mutex) { throw new UnsupportedOperationException("Not supported yet."); } } Synthetic method should be void LockExImpl#lock(Object o) {}
Olivier, do you have an opinion/recommendation for us or for Jacek on this topic ?
One place where synthetic methods can be seen is when looking at class without source code. If I open java.lang.String.class, it's compareTo(Object) synthetic method is seen in the outline and the bytecode. This request is not limited to synthetic methods though, but also other compiler trickery, such as that for inner classes (fake this$0) and local classes (closures capturing method local final variables). The docs unhelpfully state that "Synthetic fields may or may not be included." and the same for methods etc. The IBinding class is prepared for it though with an isSynthetic method, which in the case of TypeBinding always returns false. In my particular case, I need every method and field to be able to analyse which exact method is called and which method overrides which, and without the synthetics that becomes impossible (short of generating them myself). I would be perfectly fine with an option to ASTParser much like you have to ask for bindings to be resolved, but it would arguably be more clean to include them from the start, specially since IBinding already supports the notion (why have it there at all otherwise - it's only confusing, I lost a lot of time trying to find a way to get the synthetics because the presence of the method suggested there would be some way of making use of it).
Looking at the documentation (the "may or may not be included" part), I would like to believe that the clients of these APIs should be prepared for the synthetic methods/fields in the list. And IBinding#isSynthetic() can be used and in fact _is_ used by some of the JDT/UI clients I looked at. So, I can't imagine this having any side-effects and even in case of any such effects, we should address them, given the documentation does say that the client should expect the synthetic methods.
