On Fri, 20 Nov 2020 15:00:56 GMT, Hannes Wallnöfer <hann...@openjdk.org> wrote:
> This PR softens the case-sensitivity rules in Javadoc searches by including > results of case-insensitive search if a case-sensitive yields no or very few > results. > > Changes also include some restructuring of the search.js code along with > minor changes that improve compliance with the specification (Segments > separated by `_` are ranked the same way as segments of CamelCase > identifiers, and matches on such segments are ranked lower than matches for > whole identifiers, which wasn't always the case previously) > > The `TestSearchScript.java` test, which has been disabled with the removal of > Nashorn, has been updated to run without failure. In the process, I noticed > that the recent IndexBuilder|Writer|Item refactoring, comparators have been > unified to the point that the same item order is used in HTML index pages and > the search index JSON files. However, there used to be slight differences in > the sorting between the two. This change restores the original order by > adding two simple search index comparators to `IndexBuilder.java`. > > API documentation generated with this PR applied can be viewed and tested > here: > http://cr.openjdk.java.net/~hannesw/8244535/api.01/ > @hns, could you recommend (at least several different) example searches that > would clearly show the advantages of this proposal over [JDK > 15](https://docs.oracle.com/en/java/javase/15/docs/api/index.html)? Although > the are examples in tests, they are contrived (naturally). It would be nice > to see how this improves search on a real codebase, such as the JDK codebase. For case insensitivity, you can search for "HTTPC" to find `HttpClient` (or any other name where you get capitalization wrong). For the tweaks and fixes in result ranking, you can search for "get". Previously you got several variables with longer names containing "GET" ranked at the top of the result, now it's GET and get() at the top. I have a few searches I routinely do to detect and understand changes in search behaviour, but honestly I think there is nothing special about these searches. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1354
