Community
Participate
Working Groups
When I am performing content assistance for @link and @see tags in javadoc, and the class isn't referenced elsewhere in the source, I'd prefer that the class name be fully qualified in the javadoc rather than by creating the import statement. I realize this has farther reaching impact than the content assistant, it also impacts 'Organize Imports', but I think that would be great -- if a class is only referred to by javadoc, I'd like a configuration that removes it from the imports.
You can decide whether the compiler should process Javadoc or not (Java > Compiler > Javadoc). If you decide to do so it will be treated like code and we won't add special preferences for Javadoc. You can disable the processing of Javadoc and then neither code assist nor organize import will generate an import for types referenced in Javadoc types.
Daniel, I can't think how one can argue that javadoc can be treated as "any other piece of code". It is neither code not text. It's... well, it's javadoc. In this specific case, Eclipse is really not helpful. In fact, it is a pain, because introducing compile-time "imports" is just absurd. The most trivial example that comes up all the time for me is when you want to, say, release a library with just interfaces, and another one with your real implementations (and maybe one with mocks). You have an interface "Foo", implemented by a "RealFoo" (and a "FooStub"). It's quite reasonable to document: /** * [...] * * In production, this is implemented by {@link com.mycompany.myproject.mylibrary.RealFoo} */ public interface Foo { } If Eclipse imports RealFoo, though, compilation of my "interface-only jar" breaks, for it does not know about RealFoo. Another real problem in my code is when {@link Bar#bar()}, and Bar.bar() is not public. Eclipse will underline the link with a yellow warning. Three things: 1) This is completely legit documentation 2) There is no way to make that warning go away (contrary to real code, there is no @SuppressWarnings on javadoc) 3) Note that, like all other problems Eclipse finds withing @links, it's a warning, not a compilation error. So, in fact, javadoc in Eclipse is already *not* "treated like code"
Seems like a valid enhancement request to me. And, that's not to say it could be done ... or that you'd have to do it Dani :) but, I know it'd make a lot of people happy if fully qualified names were always used in JavaDoc, but not in other parts of the code. Perhaps "valid", "future", "helpwanted" would be a better disposition?
OK. *** This bug has been marked as a duplicate of bug 128661 ***
Daniel, should I file the "warning" problem on javadocs to private methods as a separate bug/request, or just add a comment to bug 128661? Thanks, Z
Separate bug please.
Thanks. For reference, I filed bug 202292
