RFR: 8176453: Javadoc search: there are issues with generics in parameters
Jonathan Gibbons
jonathan.gibbons at oracle.com
Mon Aug 13 23:43:14 UTC 2018
Hannes,
This looks like a good start.
It would be better if you did not always download/install Selenium. It
should be possible to run the tests with the Ant file configured to
point to a local already-installed version of Selenium. If nothing
else, this helps avoid problems related to proxies. Yes, I know that
you set skipexisting="true" but you'll still download Selenium each time
in a fresh repo or after "make clean" etc.
Without looking at it in great depth, it looks like the test might write
files in the main test/ directory (or some subdirectory thereof). That
is generally bad practice. Think of the src/ and test/ dirs in the repo
as read-only. You should be able to configure where any files will be
written.
How easy/practical will it be to update the test code (that you run
through javadoc) to have many modules/packages/classes so that Javadoc
Search has lots to work on? i.e. lots of test cases within it.
-- Jon
On 8/9/18 9:14 AM, Hannes Wallnöfer wrote:
> Sundar, Jon: thanks for the reviews, and sorry for the late reply (I was on vacation last week).
>
> As suggested I went ahead and wrote some Selenium tests for this and the previous search bug I fixed, along with a simple Ant build file to run them. I included this in the webrev in test/langtools/jdk/javadoc/doclet/seleniumTests - not sure if this a proper location. It includes its own test sources for generating API docs.
>
> http://cr.openjdk.java.net/~hannesw/8176453/webrev.01/
>
> Instructions for running the tests are included as comment in the main test class (JavaDocSearchTest.java). Unfortunately browser drivers still require manual configuration as these are highly platform specific.
>
> Some additional comments:
>
> - I’m pretty sure that ‚&‘ will not occur in search results as type parameters are not displayed and wildcards cannot have multiple bounds. We could still escape it to be sure, but I thought it was more important to keep the overhead to a minimum and so kept it at just ‚<‚ and ‚>'.
>
> - The ant task to download the Selenium jar file uses the HTTP URL instead of secure HTTPS. This is because HTTPS fails for me, probably because I did not include closed sources.
>
> Let me know if you think this is the way to go.
>
> Hannes
>
>
>
>> Am 31.07.2018 um 00:39 schrieb Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>>
>> While parameterized types typically just contain < and >, the bounds may sometimes include &, so I tend to agree with Sundar that if you need to escape < > you probably need to escape & as well.
>>
>> Even if we can't automate tests (yet?) I think it would be good for you to set up test cases for manual tests that allow us to check the behavior on the OS and browser of our choice. Simply asking us to test this is not enough.
>>
>> If you can find test cases that leverage the latest JDK API, then you could point at that. Otherwise you could construct test cases and post them near the webrev on your account as cr.ojn. Sometimes I will just build the latest JDK API and post that on cr.ojn.
>>
>> -- Jon
>>
>>
>> On 07/30/2018 07:19 AM, Sundararajan Athijegannathan wrote:
>>> Don't you also need ".replace(/&/g,'&')"?
>>>
>>> PS. Isn't there a standard way to escape HTML in JS?
>>>
>>>
>>> -Sundar
>>>
>>> On 27/07/18, 7:51 PM, Hannes Wallnöfer wrote:
>>>> Please review and test this patch to escape < and > characters in search results to HTML < and > entities.
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8176453
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~hannesw/8176453/webrev.00/
>>>>
>>>>
>>>> This fixes rendering of search results for search terms containing generics such as „map<str“.
>>>>
>>>> Thanks,
>>>> Hannes
>>>>
>>>>
More information about the javadoc-dev
mailing list