Bug 396991

Comment 1 Jay Arthanareeswaran 2012-12-20 07:30:27 EST

Can you elaborate this please? It would be nice if you can share a simple test case.

Comment 2 Sven Efftinge 2012-12-20 07:35:16 EST

Compile the following enum:

public enum TestEnum {

	FirstValue("Zonk"),
	SecondValue("Bla");
	
	String string;
	
	TestEnum(String string) {
		this.string = string;
	}
}

Obtain a MethodBinding for the constructor using the compiled class file and call getJavaElement() on it. It will not be openable. It's like in the other case a problem with additional synthetic arguments.

Comment 3 Jay Arthanareeswaran 2012-12-20 09:57:28 EST

I can't reproduce this one either. The method getJavaElement() returns the following, which I believe is alright:

TestEnum(java.lang.String) (not open) [in TestEnum [in TestEnum.class ...

Comment 4 Sebastian Zarnekow 2012-12-20 15:08:23 EST

Main problem is probably that you can do the following:

IMethodBinding binding = ..
IJavaElement element = binding.getJavaElement();
// this assertion will fail
assertTrue(element.exists());
String identifier = element.getHandleIdentifier();
// identifier is something like this:
// TestEnum.class[TestEnum~TestEnum~Ljava.lang.String;

If you do the following instead:

IMethodBinding binding = ..
IJavaElement method = binding.getJavaElement();
IType type = (IType)method.getParent();
IMethod methodFromParent = type.getMethods()[1];
// following assertion succeeds
assertTrue(methodFromParent.exists());
String identifier = methodFromParent.getHandleIdentifier();
// the identifier looks like this:
// TestEnum.class[TestEnum~TestEnum~Ljava.lang.String;~I~Ljava.lang.String;

Note the included synthetic parameters at index 0 and 1
The latter identifier allows to obtain the IMethod via JavaCore.create() whereas the identifier that is returned by method.getHandleIdentifier() fails to find a method. Does that help?

Comment 5 Sebastian Zarnekow 2012-12-20 15:12:55 EST

If I understand the purpose of the handle identifier correctly, it should actually not include the synthetic parameters since #getParameterCount et al will use the encoded notation. So the handle identifier is actually correct the processing of the identifier when checking for the existence of the constructor is possibly bogus (as well as the identifier of the constructor that is returned by getParent().getMethods())

Comment 6 Stephan Herrmann 2012-12-20 17:26:36 EST

Last time I investigated an issue regarding these synthetic arguments the picture was quite confusing, see bug 354603 comment 3.

Comment 7 Eclipse Genie 2020-05-20 11:58:52 EDT

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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.

Comment 8 Stephan Herrmann 2020-05-20 13:01:50 EDT

.

Comment 9 Eclipse Genie 2022-05-14 15:22:38 EDT

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.

Comment 10 Eclipse Genie 2024-05-05 17:09:50 EDT

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.