Consider removing httpfilesystem at all and
directly parse the URL returned by
JavadocForBinaryQuery in case it cannot be
converted to a FileObject. httpfilesystem is not
real http filesystem anyway - it just parses
Any progress on this?
No, the refactoring stuff has higher priority now.
Should be considered a candidate for E, I think.
The httpfilesystem code is still present but not used any more in nb
4.0. AFAIK, Tomas already has FO -> URL rewrite in his schedule.
*** Issue 51605 has been marked as a duplicate of this issue. ***
*** Issue 45321 has been marked as a duplicate of this issue. ***
Any plans to do this?
Yes, it would be nice to have it. But probably not for 4.2
*** Issue 71773 has been marked as a duplicate of this issue. ***
*** Issue 71148 has been marked as a duplicate of this issue. ***
Updating this RFE for the current version. I changed priority from P1 to P3
because it's not absolutely essential, but it would be very nice to have.
Original reported version was 4.0 so Version field should stay there. "Current"
is not used in standard modules at all.
P3 is too low for something with four duplicates IMHO.
What is the current outlook for this issue? Has anything changed with Retouche?
BTW, I must say the subject/description of this issue is rather cryptic - the
real issue is that I can not specify a URL in library manager/Java platform
manager etc., right? A number of issues with a better description are marked as
a duplicate of this issue. Can someone please explain what exactly is needed and
why, beyond the actual UI change in the library manager? Why is it necessary to
parse index.html? Thanks.
As I understand it, supporting remote (HTTP) URLs for Javadoc in the Library
Manager means rewriting how Javadoc is displayed. Currently the javadoc module
tries to use FileObject's to index and display Javadoc HTML pages. This only
works for local (folder or ZIP) Javadoc. Displaying remote content is pretty
straightforward, but indexing it is a little trickier because you cannot ask
conventional HTTP servers for a list of files in a URL folder; you need to parse
some HTML files with well-known locations to see what URLs can be expected to
exist. This is in contrast to the current FileObject-based impl which would just
look for children of a folder.
*** Issue 103200 has been marked as a duplicate of this issue. ***
*** Issue 103859 has been marked as a duplicate of this issue. ***
> indexing it is a little trickier
Is it really necessary to index remote Javadocs? I understand that some features may depend on the indexing, but the
most important aspect of this issue is to simply display the Javadoc; I think users would be happy even if we could just
*display* the remote Javadoc in the completion doc window, without any other features - these would only work on local
True, indexing is a secondary priority, though I think it could be implemented without much extra effort - and in a way
that would work uniformly for both local and remote Javadoc, so not bloating the code.
*** Issue 172341 has been marked as a duplicate of this issue. ***
*** Bug 134538 has been marked as a duplicate of this bug. ***
I'm looking at a patch for this.
Created attachment 97825 [details]
Patch being tested
I think I have it working, including indexing and code completion popup. Review especially from tzezula would be appreciated. I think it's too late for 6.9 (new feature, technically), but could be committed whenever the trunk is released for the next version.
Integrated into 'main-golden', will be available in build *201004220200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: Removing dead code that would anyway be rewritten for #41443.
The patch seems fine, thanks Jesse. The only possible problem may be a performance degradation caused by network IO (url.openStream().close()) in the SourceUtil.getJavadoc() used by code completion, navigator, etc. When the classpath contains a http url attached to jar in the beginning of classpath it's always checked. Maybe I should add some kind of caching into SourceUtil.getJavadoc(), in the navigator case the same page is looked up several times. Also for normal zip files isn't fo.getInputStream faster then url.openStream()? I am not sure about this and it probably does not matter.
(In reply to comment #25)
> The only possible problem may be a performance degradation
I thought of this. I did not notice any problem in interactive testing, though I did not measure it. Obviously the code completion Javadoc popup takes longer to appear for e.g. http://java.sun.com/whatever/api/ but I still found it quite fast enough to be usable; results may be less satisfactory on slower sites such as dev.java.net.
> network IO (url.openStream().close()) in SourceUtil.getJavadoc()
I did think of returning InputStream rather than URL so callers just wanting the stream could use it immediately. But some callers really just want the URL, or (for reasons of character encoding) sometimes reopen the stream.
Might be feasible to return a pair of <URL,InputStream> where the caller is obliged to close the IS but could reopen it. Either would be an incompatible API change, I am afraid, unless a new variant method were introduced and the former @Deprecated.
> Maybe I should add some kind of caching into
> SourceUtil.getJavadoc(), in the navigator case the same page is looked up
> several times.
Might be useful. I did not check the Navigator because I don't know what that has to do with Javadoc. I checked the popup in code completion, and the Javadoc window.
> for normal zip files isn't fo.getInputStream faster than url.openStream()?
I'm not sure. The NB module system does install its own handler for 'jar' protocol, though for now this only performs special handling for NB module JARs or their Class-Path extensions. It could probably be extended to delegate to ArchiveURLMapper's cache, providing a transparent speedup for any code using this URL protocol on user JARs.
Or the URLUtil methods could check for 'jar' URLs and treat them specially (URLMapper.findFileObject(url).getInputStream() plus null check); most of the calls to openStream should already occur there, and the others from the javadoc module could probably be factored out there. Would not help in java.source which would need to copy that logic.
OK, anyway if there will be some performance problems they will be reported soon after the integration :-)
I am for integrating this patch and if needed we can do caching and special handling of jars if needed. The thing I was afraid is long network timeout when network is unreachable. The Javadoc is calculated in RequestProcessor (at least I hope so) but the throughput is 1. This may cause that the feature will not work during the timeout. Again if it will be problem we can try to interrupt the thread and catch the InterruptedIOException, but I hope this will not be needed.
I have done various sorts of caching to minimize unnecessary HTTP transactions; use the platform cache for jar protocol; and automatically set the official Javadoc location for newly created (or default) Java platforms between 1.3 and 1.7. I'm sure there are various bugs to be shaken out, and ElementJavadoc could perhaps be refactored to never even ask for remote Javadoc if it has sources available, but everything seems to basically work. core-main #e17b99277530
Integrated into 'main-golden', will be available in build *201006180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <firstname.lastname@example.org>
Log: Issue #41443: support HTTP URLs for Javadoc.
Integrated into 'main-golden', will be available in build *201006220001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: Follow-up to #41443: look up official online Javadoc for 6.x NB platforms automatically.
> OK, anyway if there will be some performance problems they will be reported
> soon after the integration :-)
Ok, here they are: bug 187919.
*** Bug 185273 has been marked as a duplicate of this bug. ***