Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 415655 - JavaProject.findType doesn't work for anonymous inner classes
Summary: JavaProject.findType doesn't work for anonymous inner classes
Status: CLOSED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.3   Edit
Hardware: PC Mac OS X
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Jay Arthanareeswaran CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-22 04:51 EDT by Martin Lippert CLA
Modified: 2020-01-14 17:43 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Lippert CLA 2013-08-22 04:51:21 EDT
I try to find IType objects for anonymous inner classes, but that doesn't work when using JavaProject.findType(..).

Interestingly anonymous inner classes are being found on binary types when submitting the class name with "$1" and the end instead of ".1" (as documented in the javadoc and what is working for non-anonymous inner classes).

Is there a possible workaround for this? I looked at IType.getTypes() but it doesn't contain anonymous inner classes either (when invoked on a containing class). The only way I found it walking through all the child elements recursively, there is an IType object present for anonymous inner classes, but that seems to be vague and expensive. Any idea?
Comment 1 Srikanth Sankaran CLA 2013-08-22 05:08:18 EDT
Is org.eclipse.jdt.core.IMember.getType(String, int) useful ? This is
documented to return an IType corresponding to anonymous types.
Comment 2 Martin Lippert CLA 2013-08-22 05:20:22 EDT
Ok, that looks promising, thanks for that. So in case I don't know anything about the class to look for (just getting a name like "ClassA$1") I would need to find out whether the parent class is a binary type or not. In case of a binary type, I could pass "ClassA.1" to findType and get the right result. In case of a source type, I would have to parse the inner class name to see if that is a number or not. In case its a number, I would call "getType("", parsedNumber)" on the source type object, otherwise I could go on with findType.

Does that sound reasonable? And is there anything related already implemented somewhere? Just trying to not re-invent the wheel... :-)
Comment 3 Martin Lippert CLA 2013-08-22 06:18:53 EDT
Hmmm... I tried this with IMember.getType("", 1) (for example) and it returns an IType object. But calling "exists()" on that returns false.

If I walk down the hierarchy of the children objects until I find the anonymous inner class IType object, that one returns true for exists().

Any idea why?
Comment 4 Srikanth Sankaran CLA 2013-08-22 21:07:58 EDT
Jay, please take a look and suggest any workarounds - Martin, it would help
if you attach a small snippet that shows what exactly you are doing.
Comment 5 Martin Lippert CLA 2013-08-23 06:57:27 EDT
Here is what I am trying to do. I have this test class:

public class SourceLevelType {
	
	public static class SourceLevelInnerType {
	}
	
	public void foo() {
		new Observer() {
			@Override
			public void update(Observable o, Object arg) {
				new Observer() {
					@Override
					public void update(Observable o, Object arg) {
					}
				};
			}
			
			class NamedInnerClassOfAnonymousInnerClass {
				public void bar() {
					new Observer() {
						@Override
						public void update(Observable o, Object arg) {
						}
					};
				}
			}
		};
	}

}

That produces these class files:

SourceLevelType.class
SourceLevelType$1.class
SourceLevelType$1$1.class
SourceLevelType$1$NamedInnerClassOfAnonymousInnerClass.class
SourceLevelType$1$NamedInnerClassOfAnonymousInnerClass$1.class
SourceLevelType$SourceLevelInnerType.class

That looks good so far. And here is what I get from calling findType(..) for the various cases:

SourceLevelType -> returns IType and exists is true

SourceLevelType$SourceLevelInnerType -> returns IType and exists is true
SourceLevelType.SourceLevelInnerType -> returns IType and exists is true

SourceLevelType$1 returns IType, but exists is false
SourceLevelType.1 returns null

SourceLevelType$1$1 returns IType, but exists is false
SourceLevelType.1.1 returns null

SourceLevelType$1$NamedInnerClassOfAnonymousInnerClass returns IType, but exists is false
SourceLevelType.1.NamedInnerClassOfAnonymousInnerClass returns null

SourceLevelType$1$NamedInnerClassOfAnonymousInnerClass$1 returns IType, but exists is false
SourceLevelType.1.NamedInnerClassOfAnonymousInnerClass.1 returns null


I did the same for binary types (coming from a JAR file):

SourceLevelType returns IType, exists is true
SourceLevelType$SourceLevelInnerType returns IType, exists is true
SourceLevelType.SourceLevelInnerType returns IType, exists is true

SourceLevelType$1 returns IType, exists is true
SourceLevelType.1 returns null

SourceLevelType$1$1 returns IType, exists is true
SourceLevelType.1.1 returns null

SourceLevelType$1$NamedInnerClassOfAnonymousInnerClass returns IType, exists is true
SourceLevelType.1.NamedInnerClassOfAnonymousInnerClass returns null

SourceLevelType$1$NamedInnerClassOfAnonymousInnerClass$1 returns IType, exists is true
SourceLevelType.1.NamedInnerClassOfAnonymousInnerClass.1 returns null


Using IMember.getType("", 1) for the anonymous inner classes works (returns an IType object for all the cases, but exists is always false)
Hope this helps to reproduce the cases.

Let me know if you need more details.
Comment 6 Jay Arthanareeswaran CLA 2013-09-10 05:25:37 EDT
I can reproduce the reported behavior. But not sure what the expected behavior should be. Need a closer look but can't promise one any time soon as the team is focusing on the Java 8 work. However, if anyone can take a look at the problem and come up with a fix, that would be nice.
Comment 7 Eclipse Genie CLA 2020-01-14 17:43:45 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.