Community
Participate
Working Groups
I20060704-0800 JLS3 §8.9 defines the implicit methods values() and valueOf(String) declared on any enum type. The declarations contain useful Javadocs. Eclipse should show that Javadoc in content assist and when the user hovers over an invocation. /** * Returns an array containing the constants of this enum * type, in the order they’re declared. This method may be * used to iterate over the constants as follows: * * for(E c : E.values()) * System.out.println(c); * * @return an array containing the constants of this enum * type, in the order they’re declared */ public static E[] values(); /** * Returns the enum constant of this type with the specified * name. * The string must match exactly an identifier used to declare * an enum constant in this type. (Extraneous whitespace * characters are not permitted.) * * @return the enum constant with the specified name * @throws IllegalArgumentException if this enum type has no * constant with the specified name */ public static E valueOf(String name);
codeSelect fails on those.
This could be fixed by adding the methods as synthetic members of enum types. Source and Javadoc range of the elements would have to be null, but getAttachedJavadoc() could return the doc.
*** Bug 157983 has been marked as a duplicate of this bug. ***
related to bug 83206
Markus - Where do you find these Javadocs ? There is no attached source that contain them. Do you suggest that these Javadocs should be hardcoded in jdtcore plugin ?
> Where do you find these Javadocs? See comment 0: They are declared in the Java Language Specification v3, §8.9. > There is no attached source that contain them. True, but they do show up in the generated javadoc, e.g. here: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/annotation/ElementType.html#valueOf(java.lang.String) > Do you suggest that these Javadocs should be hardcoded in jdtcore plugin ? Yes, since they come from the spec, I think they should be available from jdt.core. I guess their templates should be stored in the core plug-in as a user message, such that translators would have a chance to localize them, e.g. to Japanese: http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/annotation/ElementType.html#valueOf(java.lang.String) (I wrote "templates", because the type parameter "E" must be substituted by the enum type name.) I don't see a better way to implement this other than comment 2.
For legal issues, we cannot simply take the comments from the JLS. We would need to come up with our own wording.
(In reply to comment #7) I don't think copying two comments is much different from implementing the rest of the spec, but you could file a CQ for this. > We would need to come up with our own wording. No, then we better leave it out until legal issues are cleared. We shouldn't deviate from the spec.
Just stumbled upon this bug again. Here's an example that shows why we really need these methods on enum types: package xy; import java.lang.Thread.State; public class Try { public static enum MyEnum { FOO, BAR } public static void main(String[] args) { State state= Thread.State.valueOf("NEW"); MyEnum myEnum= MyEnum.valueOf("FOO"); } } => For State.valueOf(..), the IMethod exists, but you don't see the Javadoc if you have source attached. => For MyEnum.valueOf(..), the IMethod doesn't exist, so there's not even a hover. The IMethods on enums from source should not be synthetic (see VM spec and compare to the methods in the class file), and their source ranges should not be available. For the hovers to work, we have to tweak JavadocContentAccess2#getHTMLContentFromSource(IMember) anyway, so if you don't want to add the Javadocs to IJavaElement#getAttachedJavadoc(IProgressMonitor), then we can just as well have the templates in the UI.
This is a really frustrating bug and to think that it has not been fixed 11 years after it was reported. Any reason why no one worked on this? Was it the legal reasons of copying the spec?
(In reply to Julius Hager from comment #10) > This is a really frustrating bug and to think that it has not been fixed 11 > years after it was reported. > > Any reason why no one worked on this? Was it the legal reasons of copying > the spec? Know what? You are the very first user ever who requests this feature :) (all other participants of the discussion here are/were members of the team). Tentatively setting a target, time permitting.
Bulk move out of 4.9
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.
