Lowering priority.
The bug is caused by removal of first start and moving to AutoMount
support. Now, you can mount javadoc by xml layer in your module, or,
jdk javadoc as *.zip, you can edit root offset in Expert sheet without
need of unpacking Javadoc to /doc folder.
Now, adding back this functionality has negative performance effect.
It will be probably back with JDK registry (planned for4.0).

Petr,

Hi!  Could you please explain more about the negative performance effect?  Is it
just slower startup time, or is the actual operation of the IDE degraded?  I ran
into this bug myself very recently, and found it to be a problem.  It wasn't
obvious what the Java documentation mount point was supposed to be; my first
guess was that it was <jdk_home>/docs/api, but that turned out to be wrong.  I'm
very worried about three things: 1) that we're supposed to be the IDE that
showcases Java functionality, 2) that we're supposed to be giving our users easy
access to JDK information, and 3) we're not even providing any kind of support
for users to get the information.  They just have to figure it out for
themselves.

If the performance hit of automounting the JDK docs is really bad, is there
something else that we could do?  Could we put a "JDK Documentation" menu item
under Help?  When called, that menu item would automount the JDK docs if they
are there.  If the JDK docs aren't there, then the user gets a message telling
her to please install the docs.  This isn't a perfect solution, since the user
still doesn't see the JDK docs mounted under the Javadoc node.  But it's better
than nothing.

Thanks!

Dirk

The mounting in module install had really negative startup time impact.
I try to find and discuss some other way, how to resolve this problem.
Mouting by Automount support carries some problems when user switches
JDK's, mounted FS under one JDK, but no change made on FS setting
leads to situation, that FS is lost after switching JDK and vice versa
(2 JDK javadoc mounted at same time if user made changes ). FS mounted
by layer has persistent path given by the layer, it is setting are not
stored until first change, and Automount does not expect, that FS can
be simply moved to another location.

I would like to drop the feature, until there's a strong notion of JDK
or target platform in the IDE. Then we can locate/automount docs for
the selected platform reliably.

I'd like to reopen this issue at least as Enhancement. Because this
feature could be highly desirable for users. By default it should
mount javadoc for that JDK which is IDE running on. Othervise any
user-mounted JDK javadoc would remain mounted regardless used JDK.

Should be implemented in 3.4 IMO.

Oops...I said 3.4? I meant 4.0 :-)

"FS mounted by layer has persistent path given by the layer, it is 
setting are not stored until first change, and Automount does not
expect, that FS can be simply moved to another location." - sorry, did
not understand this sentence at all.

I understand that it can be difficult to find the JDK docs
automatically - impossible in general because they cannot be
guaranteed to be in any particular location - but they are often in a
predictable place ($jdkhome/docs/ I think). Anyway, if you can (at
least sometimes) find them on disk, I don't see what the problem is.
You use

<filesystem>
  <folder name="Mount">
    <file name="org-nb-mod-javadoc-jdkdocs.instance">
      <attr name="instanceOf"
            stringvalue="org.openide.filesystems.FileSystem[]"/>
      <!-- (or whatever the array syntax is, forget) -->
      <attr name="instanceCreate"
            methodvalue="org.nb.mod.javadoc.Util.mountJDKDocs"/>
    </file>
  </folder>
</filesystem>

public class Util {
  public static FileSystem[] mountJDKDocs() {
    File docs = findJDKDocs();
    if (docs != null) {
      // make LocalFS, set caps, set r/o, set hidden
      // return new FS[] {localFS}
    } else {
      return new FS[0];
    }
  }
}

Right?

I'm now responsible for JavaDoc module.

Such information should be fetched from JavaPlatform API. Still in
question if the platform API should expose:

  - just a URL (FileSet, FileObject) or
  - full-featured javadoc service

I prefer the raw URL approach. Javadoc search service does not make
much sence on platform only. Developer typically needs to search all
imported resources in project. 

Besides once configured project target platform, are platform
resources somehow queriable using standard project APIs (descriptors)?

As described in
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss
the current work on projects prototype has been stopped, but this RFE
is still valid (removing PROJECTS keyword).

[batch] Giving up javadoc issues exclusive ownership.

It works on a different base in 4.0

*** Issue 38587 has been marked as a duplicate of this issue. ***