JDK-8268422 : Find a better way to select releases in "New API" page
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-06-08
  • Updated: 2022-05-30
  • Resolved: 2022-05-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19 masterFixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
With JDK 18+, by default the range of releases for "new" goes from 11 and includes every release since then. The current way to display and select release information does not really scale to so many releases. We should find a new way to show and select release information in the "New API" and "Deprecated API" pages.
Comments
Changeset: 777f813e Author: Hannes Wallnöfer <hannesw@openjdk.org> Date: 2022-05-27 11:09:26 +0000 URL: https://git.openjdk.java.net/jdk/commit/777f813e9b2688034d77523b4142dd67e1d9f38b
27-05-2022

A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8657 Date: 2022-05-11 16:42:14 +0000
11-05-2022

We found that a single row of checkboxes at the top of the page to select releases to display works best (easy to use and very little visual clutter). I'm changing the title of the issue to reflect our solution for the problem.
11-05-2022

Another idea for how to reduce the space required for release tabs proposed by [~jjg]: - Keep the left-most top, named "New <items>" - Replace all the "Added in <release>" tabs with a single magic multi-choice tab, "Added in <R1> ☒ <R2> ☒ <R3> ☒" etc i.e. a single tab with a labelled collection of checkboxes
20-01-2022

Maybe "[Added|Deprecated] between 12 and 17"?
11-01-2022

Expanding on the semantic problems mentioned in my previous comment, more precisely the problem how to label this information: In the current implementation of the feature we settled on "Added in X" and "Deprecated in Y" because using the word "since" turned out to be too ambiguous: "Since X" could mean something was added or deprecated *in* release X, or it could mean it was added/deprecated *after* release X. Adding support for release ranges would make the problem worse, as in addition to above problem we have to think about how label a range. One relatively simple way would be to extend our current scheme to "[Added|Deprecated] in 12-17" using the first and last release of a range.
11-01-2022

Grouping releases along LTS lines will pose some new semantic problems, as implementation of the original feature has shown (i.e. do tabs show new APIs since that release, in that release, up until that release). There's not enough time left to do this for 18. On the other hand, changing the first tracked release to something later than 11 is probably too early for 18. Retargeting this issue to 19 in the hope that we can come up with a good solution.
24-11-2021

I suspect the feature may need to be updated to "merge" info for specific releases. I think 18 is too soon to drop all info before 17, and 11 in particular. For 18, I think the desirable list might be 11: (baseline) 17: (all new stuff since 11, meaning 12, 13, 14, 15, 16, 17) 18: (new since 17) Then for 19, add one extra tab 19: (new since 18) etc. Since there is no spec for the form of a @since tag, and because it is only a convention that JDK uses sequential integer values, we might need to update the command-line option to support "hidden" releases, such as --since 11,[12],[13],[14],[15],[16],17,18 or how about this, suggesting "groups" for releases: --since 11,(12,13,14,15,16,17),18
08-06-2021