9

I've been searching for an answer for several months and I have tried multiple things, including unzipping the Compressed folder src.zip and using it as a parameter for Javadoc (for example: javadoc -sourcepath src com.example.test)

This is the default Javadoc that comes with the JDK 6 Update 24.

Let's say that I'm working on a new map that implements the java.util.Map interface. By default the methods that I override from the Map interface should inherit the documentation from the interface, if I'm not mistaken. However, javadoc never does it.

The only thing that has worked this problem out so far, has been actually javadoc-ing the classes written by Java (for example: javadoc com.example.text java.util). I don't want to do this because it makes it seem like I rewrote the Java classes, but is this the only way to do it? If it is I suppose I could just live with it, but it was my understanding that there was another way to do this.

Thank you =) I'm sorry if this is a little messy. This is my first time using Stack Overflow. I'm also sorry if this question has been asked already. I have read many similar questions by they don't cover everything that I wanted to ask and I've found them very confusing because they involve writing your own implementation of Javadoc. Anyway, thank you in advanced =)

Edit: May 25 at 4:44

All right =) If I understand correctly, you would like to see an example. This is a simpler example that I tried to see if it was because I was trying something that shouldn't work.

package com.example;

/**
 * A simple class that returns an upper-case string representation.
 */
public class UpperCaseObject {

    @Override public int hashCode() {
        return super.hashcode();
    }

    /**
     * {@inheritDoc}
     *
     * <P>The {@code toString} method for class {@code UpperCaseObject} returns
     * converted to uppercase.</P>
     *
     * @see String#toUpperCase()
     */
    @Override public String toString() {
        return super.toString().toUpperCase();
    }

}

I moved this example (file name is UpperCaseObject.java) into a directory javadoc-test/com/example and I also made another directory javadoc-test/java/lang, placing Object.java (from src.zip) in it.

The call to javadoc that I made was javadoc -link http://download.oracle.com/javase/6/docs/api/ com.example from the directory javadoc-test. I have the jdk6 bin directory in my path parameter.

The two things that I expected was for UpperCaseObject.hashCode to inherit all of the documentation, and UpperCaseObject.toString everything before the extra paragraph from java.lang.Object. However, unfortunately, I didn't get any of the documentation.

Edit:

Well, what I had to do was the following. It is just a simple workaround.

  1. I copied all the source files from source.zip like you would normally do so.
  2. I also made package files for each package. They contain the very first paragraph (the one with the summary) and a second paragraph that says "See the Package Summary in the Java™ Platform, Standard Edition 6 API Specification for more information."
  3. The source files were essentially the super classes, their super classes (and interfaces), and any exceptions that they threw that were also in the same package. The only exception was java.lang where I only needed to get Object. The exceptions were also needed because except for java.lang, the other packages did not link if an exception was in the same package as the throwing class.
  4. I javadoc'd all the packages that I was using/subclassing/exception-throwing from.
  5. I'll make sure to include some information about the standard packages and my own package in he overview file.

Unfortunately, I can only do a work around for now, but I'm convinced that it may be a problem with my version of Java. It sounds like other people have had a similar problem and came up with their own workarounds. This is just my own =)

I'll still be taking answers, but this is the most convenient option in the meanwhile. Thank you very much!

user766413
  • 121
  • 1
  • 6
  • Normally it should work if the inherited classes are in the sourcepath but not in the list of packages being documented directly, like Ted wrote. If it doesn't work this way, you'll have to show an example call of your javascript, together with a sketch of your directory structure. (You can edit your question to add this.) – Paŭlo Ebermann May 23 '11 at 21:27

2 Answers2

4

The source file for the inherited method needs to be on the -sourcepath of the javadoc tool when it runs. You don't need to pass the inherited class on the command line.

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • [More details on how to do this in my answer to a similar question](http://stackoverflow.com/questions/4922124/inherit-javadoc-without-generating-docs-for-inherited-source/4923682#4923682). – Paŭlo Ebermann May 23 '11 at 22:07
  • Thank you for the advice =) Actually though, this is one of the first things that I tried. It sounds like it should work, (and I'm fairly certain that it has at one point,) but it isn't working for me. I'm thinking that it could be a problem with my version of Java, but I don't want to jump to conclusions just yet. – user766413 May 25 '11 at 04:56
  • I seem to remember reading somewhere that if the compiled classes are on the classpath for javadoc, then it sometimes stops when it finds the compiled versions and won't look on sourcepath for the sources; the result is that the comments end up not inherited. I forgot whether there was a work-around for this or whether it was Java-version specific. I'll hunt around and if I come up with anything I'll post another comment. – Ted Hopp May 25 '11 at 05:07
  • Thank you very much, Ted Hopp. That wouldn't apply to the simpler example (UpperCaseObject) that I posted, because I made sure not to compile it first. But it would be very handy to know that. – user766413 May 25 '11 at 16:13
1

One thing you can do is link to the official Javadoc for those classes, using the -link option:

javadoc -sourcepath src -link http://download.oracle.com/javase/6/docs/api com.example.test

This will allow Javadoc to treat the classes of the SDK as "external referenced classes". From the Javadoc documentation:

The referenced classes whose documentation is not being generated during a javadoc run. In other words, these classes are not passed into the Javadoc tool on the command line. Links in the generated documentation to those classes are said to be external references or external links. For example, if you run the Javadoc tool on only the java.awt package, then any class in java.lang, such as Object, is an external referenced class. External referenced classes can be linked to using the -link and -linkoffline options. An important property of an external referenced class is that its source comments are normally not available to the Javadoc run. In this case, these comments cannot be inherited.

Note that the Javadoc for these class will still not be inherited. However, you can now link to it, like so:

public class MyMap implements java.util.Map {
    ...
    /**
     * @see java.util.Map#isEmpty()
     */
    @Override
    public boolean isEmpty() {
        ...
    }
}

[EDIT]

The @see tag is there for illustration. Javadoc should automatically generate a "Specified By" link, so you could omit the Javadoc comment altogether.

Nathan Ryan
  • 12,893
  • 4
  • 26
  • 37
  • Adding the link is a good idea anyways, but it does not solve the "inherit the documentation" problem, as you wrote. – Paŭlo Ebermann May 23 '11 at 21:28
  • @Paŭlo: True, but without including the SDK source, the documentation cannot be inherited, since that is the mechanism by which Javadoc obtains inherited documentation. Arguably, documentation should be referenced rather than replicated, anyway (though I agree in the value of replicating at a low level). – Nathan Ryan May 23 '11 at 21:59
  • As Ted wrote ([and I answered some moths ago for another similar question](http://stackoverflow.com/questions/4922124/inherit-javadoc-without-generating-docs-for-inherited-source/4923682#4923682)), this is doable without generating new documentation for the JDK sources. – Paŭlo Ebermann May 23 '11 at 22:06
  • I never meant to imply that the Javadoc for the SDK classes needed to be generated, only that the source needs to be available. – Nathan Ryan May 23 '11 at 22:10
  • Ah, I see the confusion. By "referenced rather than replicated", I mean that using a mechanism like `{@inheritDoc}` or otherwise inheriting documentation duplicates the *text* of the documentation. – Nathan Ryan May 23 '11 at 22:14
  • This sounds like a good idea to me, but only if I want to emphasise that this subclass's method inherits important information from its superclass's method (of the same name). Otherwise, it seems a little redundant to me. I would prefer to inherit from Java's classes, like I can with classes of the same package. – user766413 May 25 '11 at 04:59