Re: RFR: JDK-8259806: Clean up terminology on the "All Classes" page
Up until recently, we used Types (now Classes and Interfaces) Annotation Type (now Annotation Interface) Enum (now Enum Class) Record (now Record Class) The general decision has been to use the older terms consistent with the usage throughout the documentation for the older releases. I guess you have a corner case here, where you are fixing "Classes" (IIRC) and I guess it is "weird" to be retroactively changing it to deprecated terminology like "Types" even if it would be more consistent, especially when the new term is more accurate even for older releases. -- Jon On 6/4/21 11:57 PM, Hannes Wallnöfer wrote: On Thu, 3 Jun 2021 17:09:21 GMT, Jonathan Gibbons wrote: Maybe I'm fighting a losing battle on this one, but the current policy is to generate the correct new terminology for recent releases and the older terminology for older releases, to try and stay consist within the release. The mapping is handled semi-automatically in `HtmlDoclet.getResourceKeyMapper`, line 130. As a general rule, if you're changing terminology, you should at least be updating the mapping as well. Is "Classes and Interfaces" part of the "new terminology"? I thought "classes and interfaces" would be the correct term for anything living in a .class file, regardless of release. - PR: https://git.openjdk.java.net/jdk/pull/4270
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v13]
On Fri, 4 Jun 2021 20:20:26 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for >> switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common >> superinterface for expressions and patterns, `CaseLabelTree`, which >> expressions and patterns implement, and a list of case labels is returned >> from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` >> that represents it (`DefaultCaseLabelTree`). It is used also to represent >> the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be >> disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary >> (boxed-primitive, String, enum) switches. This is a bit tricky for boxed >> primitives, as there is no value that is not part of the input domain so >> that could be used to represent `case null`. Requires a bit shuffling with >> values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It >> produces code that delegates to a new bootstrap method, that will classify >> the input value to the switch and return the case number, to which the >> switch then jumps. To support guards, the switches (and the bootstrap >> method) are restartable. The bootstrap method as such is written very simply >> so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String >> s`/`case null: case String s:`/`case String s: case null:`, handling of >> these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with two additional > commits since the last revision: > > - Applying review feedback. > - Tweaking javadoc. Dynamic constants are needed when de-structuring classes that are not record at top-level, to make the type that will carry the bindings, from invokedynamic to where they are accessed, opaque. So dynamic constants are not needed yet ! - PR: https://git.openjdk.java.net/jdk/pull/3863
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12]
On Fri, 4 Jun 2021 20:17:43 GMT, Jan Lahoda wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixing typo. > > Thanks a lot for all the feedback. I've tried to do the requested changes in > the recent commits. @lahodaj I also noticed that https://bugs.openjdk.java.net/browse/JDK-8213076 as well as https://openjdk.java.net/jeps/406 state > The implementation will likely make use of dynamic constants (JEP 309). and wondering if this should be changed on > The implementation will likely make use of invokedynamic. or maybe even removed? - PR: https://git.openjdk.java.net/jdk/pull/3863
Withdrawn: JDK-8267394: Do not rely on object identity for empty valid Content instance
On Thu, 20 May 2021 14:31:33 GMT, Hannes Wallnöfer wrote: > This is a simple cleanup to replace the sentinel `HtmlTree.EMPTY` text > constant with an instance that achieves the same by overriding `isValid()`. I > think this is the nicer solution, and it allows us to remove the special case > identity check in `HtmlTree.add(Content)`. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4130
Re: RFR: JDK-8259806: Clean up terminology on the "All Classes" page
On Thu, 3 Jun 2021 17:09:21 GMT, Jonathan Gibbons wrote: > Maybe I'm fighting a losing battle on this one, but the current policy is to > generate the correct new terminology for recent releases and the older > terminology for older releases, to try and stay consist within the release. > > The mapping is handled semi-automatically in > `HtmlDoclet.getResourceKeyMapper`, line 130. As a general rule, if you're > changing terminology, you should at least be updating the mapping as well. Is "Classes and Interfaces" part of the "new terminology"? I thought "classes and interfaces" would be the correct term for anything living in a .class file, regardless of release. - PR: https://git.openjdk.java.net/jdk/pull/4270
