Eclipse issue w/Java imports, doc comment links, and type parameters

Discussion in 'Java' started by Twisted, Dec 4, 2006.

  1. Twisted

    Twisted Guest

    This is unexpected behavior and a problem:

    I have a sourcefile where one of the doc comments contains:

    {@link ETF#getIteratorInstance(Options, Parameters)
    ETF.getIteratorInstance}

    It's impossible to "organize imports" in Eclipse when editing this file
    now. It highlights Parameters in this doc comment and wants me to pick
    either java.security.Policy.Parameters or
    javax.security.auth.login.Configuration.Parameters, and does not
    provide the option to skip doing so but still import whatever else
    (e.g. HashSet) has been referenced and needs importing.

    The code itself does not actually reference Options or Parameters,
    which are actually type parameters to the class ETF. It is only this
    one @link doc tag that references them as part of the signature of the
    linked-to method. Neither of the Parameters classes suggested as
    imports are at all useful or relevant here.

    This is a significant wart, though not a showstopper. Organize imports
    should, it seems to me, limit itself to what's actually used by the
    Java code, and if javadoc needs this to find them, types actually
    linked to in comments (in this case ETF but not Options or Parameters).

    This looks likely to be a result of the relatively recent introduction
    of generics. Let's hope this sort of thing is smoothed out in the next
    version of Eclipse (and, if partially responsible, javac and/or
    javadoc)...
     
    Twisted, Dec 4, 2006
    #1
    1. Advertising

  2. Twisted

    Twisted Guest

    Twisted wrote:
    [snip]

    P.S. it seems that Java's generics, though less complex or
    well-developed than C++ templates owing to the need for backward
    class-file compatibility, are nonetheless sufficient in capability to
    enable type-parameter spaghetti. :) Perhaps even more so than
    templates, since javac is much smarter about resolving backward
    references and coping with the circular referencing of types without
    having to declare everything once and then define everything
    once...OTOH, *nothing* compares to the #include spaghetti that any
    substantial circularly-referenced group of C++ classes forces on the
    poor benighted coder who has to write the header files!
     
    Twisted, Dec 4, 2006
    #2
    1. Advertising

  3. Twisted

    Twisted Guest

    Twisted wrote:
    > This is unexpected behavior and a problem:
    >
    > I have a sourcefile where one of the doc comments contains:
    >
    > {@link ETF#getIteratorInstance(Options, Parameters)
    > ETF.getIteratorInstance}


    I've got some more information now. It's actually the *autocomplete* in
    Eclipse that is stuffing this up. It should really be filling this in
    with ETF#getIteratorInstance(Object, Object) with these type
    parameters, and more generally, with whatever the type parameter
    extends, rather than
    the name of the type parameter itself. Manually changing
    type-parametrized @link and @see references to replace type parameter
    names with the erased types is needed to make the links work in the
    compiled javadocs too.
     
    Twisted, Dec 4, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt
    Replies:
    3
    Views:
    555
    Tor Iver Wilhelmsen
    Sep 17, 2004
  2. Alec S.
    Replies:
    10
    Views:
    10,329
    Alec S.
    Apr 16, 2005
  3. Albert
    Replies:
    4
    Views:
    11,039
    Albert
    Jul 10, 2008
  4. zildjohn01
    Replies:
    0
    Views:
    694
    zildjohn01
    Feb 22, 2011
  5. Victor Hooi
    Replies:
    1
    Views:
    130
    Devin Jeanpierre
    Nov 25, 2013
Loading...

Share This Page