In package foo, an {@link bar.Bar} to a class in package bar results in an 
unqualified reference to Bar (which is correct), but an {@link bar.Bar#bar} to a 
method in Bar or an {@link bar.Bar#FOUR} to a field in Bar result in references 
in which Bar is fully qualified by its package, which seems wrong. Moreover, 
-noqualifier bar appears to have no effect on these references, they remain 
fully qualified.

In package foo, {@link}s to an external class java.lang.Integer, or to a method 
or field of Integer, result in fully qualified references to java.lang.Integer 
(which is correct), but -noqualifier java.lang appears to have no effect on 
these references, they remain fully qualified.

Example sources:

package foo;

/**
 * Foo class.
 * Here are links to {@link foo.Foo#THREE}, {@link bar.Bar#FOUR} and
 * {@link java.lang.Integer#MAX_VALUE} constants.
 * Here are links to {@link foo.Foo#foo}, {@link bar.Bar#bar} and
 * {@link java.lang.Integer#intValue} methods.
 * Here are links to {@link foo.Foo}, {@link bar.Bar} and
 * {@link java.lang.Integer} classes.
*/
public class Foo {
    public static final int THREE = 3;
    public void foo() {}
}

package bar;

/**
 * Bar class.
 * Here are links to {@link foo.Foo#THREE}, {@link bar.Bar#FOUR} and
 * {@link java.lang.Integer#MAX_VALUE} constants.
 * Here are links to {@link foo.Foo#foo}, {@link bar.Bar#bar} and
 * {@link java.lang.Integer#intValue} methods.
 * Here are links to {@link foo.Foo}, {@link bar.Bar} and
 * {@link java.lang.Integer} classes.
 */
public class Bar {
    public static final int FOUR = 4;
    public void bar() {}
}

DOUG's RESULT:

Class Foo

Foo class. Here are links to THREE, bar.Bar.FOUR  and 
java.lang.Integer.MAX_VALUE constants. Here are links to foo(), 
bar.Bar.bar() and java.lang.Integer.intValue()  methods. Here are 
links to Foo, Bar and java.lang.Integer  classes.
              ^^^
    Doug says should be bar.Bar

Class Bar

Bar class. Here are links to foo.Foo.THREE, FOUR and 
java.lang.Integer.MAX_VALUE constants. Here are links to 
foo.Foo.foo(), bar() and java.lang.Integer.intValue()  
methods. Here are links to Foo, Bar and java.lang.Integer classes.
                           ^^^
       Doug say should be foo.Foo

N/A

The test is at 
mif/dkramer/work/linkqualifiers-4647370/

Both the MIF and standard HTML doclets were designed as follows:

http://webwork.sfbay.sun.com/j2se/1.4/docs/tooldocs/solaris/javadoc.html#shortened

If the label is omitted, then package.class.member will appear -- in
general, it will be suitably shortened relative to the current class
and package. By "shortened", we mean the Javadoc tool will display
only the minimum name necessary. For example, if the
String.toUpperCase() method contains references to a member of the
same class and to a member of a different class, the class name will
be displayed only in the latter case (as shown in the following table).

source: 
http://java.sun.com/j2se/1.4/docs/tooldocs/solaris/javadoc.html#shortened

According to this, your premise that in package foo, bar.Bar should
appear as "Bar" is incorrect.  So we would plan to make it display,
but you could suppress it with -noqualifier.

Why does it seem wrong that a link to a method or field in another package (bar) 
be fully qualified by its package?  Would you prefer to see Bar.bar to
bar.Bar.bar and  Bar.FOUR to bar.Bar.FOUR?  Perhaps we can give greater
control to the user by adding a new option?

-noqualifier seems to be broken for suppressing the package name.
I've opened a separate bug 4673565 for that.

  xxxxx@xxxxx   2002-04-23


This bug is very much related to:

4673565  -noqualifier with {@link} should suppress package names

I recently fixed 4673565 but it is only a temporary solution.  The label that the MIF doclet outputs for links only shows up properly in .mif files.  When the .mif file is converted to .fm or .pdf, the labels get converted to what ever text the link references.  I hope this makes sense.  Doug could give a better explaination of the problem.  In summary, we have to modify the MIF doclet to output hypertext links instead of XRef links.  Hypertext links give us more control over the label that show up for links.  {@link} and @see should behave the same as they do for the standard doclet.

We will fix this bug for 1.2beta3 but the fix for bug 4673565 will show up in 1.2beta2.
  xxxxx@xxxxx   2002-05-05

=====================================

This bug has been fixed.  For now on, we only use XRefs for page numbering.  All links are now implemented as hypertext links.
  xxxxx@xxxxx   2002-05-12