Community
Participate
Working Groups
Similar to bug #396986 but this time it's about constructors in enums.
Can you elaborate this please? It would be nice if you can share a simple test case.
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.
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 ...
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?
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())
Last time I investigated an issue regarding these synthetic arguments the picture was quite confusing, see bug 354603 comment 3.
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.
.
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.
