Javadoc's invocation and extension (Doclet) mechanisms are rather inelegant. You invoke it programmatically by passing a list of command-line args, exactly like a main().  You use this to pass it -doclet, -classpath and -docletpath.  Javadoc creates a classloader from the paths you pass it, and uses that to load the named doclet class.  It sets this classloader as the context  classloader when invoking methods on the doclet, such as languageVersion().  (Annoyingly, it also fails to restore the context classloader, which has caused another 
bug already).  

 

The upshot of this seems to be that if tools.jar is not in the system classpath, javadoc and the doclet will load classes (such as LanguageVersion) from it using different

classloaders.  When javadoc goes to do its dynamic invocation on the doclet methods, it complains when its instanceof tests fail.  So, the LanguageVersion that it is complaining about really is a LanguageVersion, but it's just one from a different classloader.

The attached test case is a simple test case which demonstrates the problem using a dummy 
Doclet. It also shows that you *can* get things to work if you can just pass -classpath to the java command that is invoked.  This is exactly what the WLS ant script does, and is why thing work in the 'devenv' environment but not with out-of-the-box ant.
###@###.### 10/11/04 16:31 GMT