Community
Participate
Working Groups
4.3 M6. IJavaElement.getAttachedJavadoc(IProgressMonitor) should throw exception if base URL is wrong. See bug 403036 comment 1 for details. A point to consider is a potential performance impact.
Interestingly I just noticed that some websites prefer to throw a FileNotFoundException (404 in case of browser access) - e.g. the oracle's Javadoc pages. That makes relying on the FileNotFoundException trickier than I thought :(
(In reply to comment #1) > Interestingly I just noticed that some websites prefer to throw a > FileNotFoundException (404 in case of browser access) - e.g. the oracle's > Javadoc pages. That makes relying on the FileNotFoundException trickier than > I thought :( If that wasn't clear, try something like this: http://docs.oracle.com/javase/6/docs/api/java/util/ And you get a 404 or a FNFE depending on how you access it.
(In reply to comment #1) > Interestingly I just noticed that some websites prefer to throw a > FileNotFoundException (404 in case of browser access) - e.g. the oracle's > Javadoc pages. That makes relying on the FileNotFoundException trickier than > I thought :( And, depending on the OS, you might also get a SocketException.
We can keep the cost down by checking the base URL only when FileNotFoundException is thrown for the resource. But we need to define "base URL is wrong" clearly.
I don't see a way out of this. Looks like we are at the mercy of the javadoc host if we want to be able to differentiate a folder path being present vs not being preset. I recommend we treat all cases in the same way (report a file not found) and live with what we have today.
No solution yet in M7. For the time being still keeping the target as 4.3. Dani, if the UI has a way to handle things in this scenario, we can probably move to 4.4.
(In reply to comment #2) > (In reply to comment #1) > > Interestingly I just noticed that some websites prefer to throw a > > FileNotFoundException (404 in case of browser access) - e.g. the oracle's > > Javadoc pages. That makes relying on the FileNotFoundException trickier than > > I thought :( > > If that wasn't clear, try something like this: > > http://docs.oracle.com/javase/6/docs/api/java/util/ > > And you get a 404 or a FNFE depending on how you access it. And that would be expected, because that's a wrong base URL. However, the correct base URL won't throw an exception: http://docs.oracle.com/javase/6/docs/api Or do you see otherwise? > But we need to define "base URL is wrong" clearly. I'd define "wrong" if one can't open a stream on the (base) URL without getting an exception.
Created attachment 241771 [details] Proposed fix This fix validates the base Javadoc location when necessary and throws JME as applicable. Here's few words about the fix: 1. The validation of base URL is done late - it's done only when the Javadoc fetch results in a FileNotFoundException. 2. Two caches are maintained, one each for valid and invalid locations. Both caches are initialized lazily, but not persisted and will be recreated for every eclipse session. 3. Validation is done by calling URLConnection#getInputStream(). In certain file systems, like windows, the connect() call results in an exception when the folder is not present. So, we will bail very early without attempting to open a stream. But in certain cases like HTTP connection, connect() doesn't fail even for invalid URL, so it takes a bit more to validate the URL. But that's all internal to the URLConnection implementation. 4. Perhaps we can eagerly update the validURLs cache for every successful javadoc read, but that will be the most common scenario we don't want to be impacted, not even with a contains() check.
With minor changes to the previous patch, released in master: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=d43bd70d5c6c4fa98b6c25564f2818572a108eac
(In reply to Jayaprakash Arthanareeswaran from comment #8) > 2. Two caches are maintained, one each for valid and invalid locations. Both > caches are initialized lazily, but not persisted and will be recreated for > every eclipse session. That sounds very dangerous. Are you sure this can never occur if the URL is just temporarily unreachable? E.g. when the network is down? Can't this also happen locally if there's a local Javadoc location on the project, but Javadoc has not been generated yet or has been cleared by a build? If you block a URL for an entire Eclipse session, you at least have to write this to the log, so that a user can have a clue why JDT doesn't even try to find Javadoc any more.
(In reply to Markus Keller from comment #10) > That sounds very dangerous. Are you sure this can never occur if the URL is > just temporarily unreachable? E.g. when the network is down? Can't this also > happen locally if there's a local Javadoc location on the project, but > Javadoc has not been generated yet or has been cleared by a build? The caches and base URL validation come into picture only when a FileNotFoundException is thrown while fetching Javadoc for an element. This is what happens: 1. Request made for Javadoc for a java element. 2. FileNotFoundException thrown. 3. We check the caches (or the URL if first time) for validity of base URL, if valid, return null as Javadoc, if invalid throw JME. When a request is made for the same element, it goes through the same steps all over again. If FNE is not thrown in (2), the Javadoc is returned - the caches or base URL is never checked. As you can see, we use the caches only to chose between returning a null Javadoc and throwing a JME. A very scope indeed.
Verified for Eclipse Luna 4.4 M7 Build id: I20140429-2000.
