On Thu, 26 Nov 2020 20:04:17 GMT, Jonathan Gibbons <j...@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/ > > There is a certain amount of "two steps forward, one step back" here. > > Yes, this is a good fix to the regression, so approved, and maybe it was an > embarrassing convenience that the search test was disabled for the > IndexBuilder work, but it is retrograde in that we're going back to a world > with different sort orders for the static index pages, and interactive search. > > FWIW, I like the conciseness of the change, which also helps highlight when > comparators would be different ... i.e. for type elements with the same > simple name. With that in mind, I came up with the "test case" for when the > comparators are different: the `ToolProvider` class, which is in both > `java.util.spi` and `java.tools`, and these two instances sort differently in > the two presentations. > > Bottom line: this is a good fix, and a step in the right direction, but we > should follow up with another fix to have the static index pages sort the > same as the index pages. I'm guessing that may mean reverting part of this > change and improving `mainComparator`. I thought I saw a different order in the type declarations. I'll check again. -- Jon On 11/26/20 12:38 PM, mlbridge[bot] wrote: > > /Mailing list message from Pavel Rappo <mailto:pavel.ra...@oracle.com> > on javadoc-dev <mailto:javadoc-dev@openjdk.java.net>:/ > > When I punch in `ToolProvider` I see 3 results in JDK 15 and 2 results > on this change's sample page. Advantages are unclear. > > [JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/index.html): > > Types > java.util.spi.ToolProvider > javax.tools.ToolProvider > Members > javax.tools.ToolProvider.ToolProvider() > > [This change's sample > page](http://cr.openjdk.java.net/~hannesw/8244535/api.01/): > > Types > java.util.spi.ToolProvider > javax.tools.ToolProvider > > Do you see a different picture? > > On 26 Nov 2020, at 20:09, Jonathan Gibbons <jonathan.gibbons at > oracle.com> wrote: > > Pavel, > > The way I read the code changes, you need to find examples of > classes with the same name but in different packages. The example > that came to mind for me is `ToolProvider`. > > -- Jon > > On 11/26/20 8:51 AM, Pavel Rappo wrote: > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/1354*issuecomment-734470787__;Iw!!GqivPVa7Brio!NZiTPiztuUcJlW_RGorpMF-3_FE5nRw8l_rFvinNmubWt1i6AJlWS5xe1yd0a6qWFT_Vxg$>, > > or unsubscribe > <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRTJZZKGTW2R6HTMV5LSR24DZANCNFSM4T44FCTQ__;!!GqivPVa7Brio!NZiTPiztuUcJlW_RGorpMF-3_FE5nRw8l_rFvinNmubWt1i6AJlWS5xe1yd0a6qyPHyKyw$>. > ------------- PR: https://git.openjdk.java.net/jdk/pull/1354
