` element that also contains the page header, and the stylesheet used the `.header ul` selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to. > > I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `

`. > > There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. > > Demo output for the new preview page as well as other pages is available here: > http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html Mostly excellent. There are some minor comments inline. There are more "English phrases" (recognized as "strings with words separated by spaces") than I expected, at least some of which will end up in generated docs. But that being said, I guess this is a JDK-only feature, and we don't translate the source going into our API docs. src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 91: > 89: /** JEP number */ > 90: int number() default 0; > 91: /** JEP title */ suggest noting the format (i.e. plain text, not HTML, not a resource key) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 164: > 162: protected void addIndexLink(HtmlId id, String headingKey, Content content) { > 163: var li = HtmlTree.LI(links.createLink(id, > 164: contents.getContent(headingKey))).setId(HtmlId.of("contents-" + id.name())); Suggest adding a comment that `"contents-" + id` appears in the JavaScript code as well. You presumably can't change one without the other (and can't use a common function across the language barrier.) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 125: > 123: doclet.Preview_API=Preview API > 124: doclet.Preview_API_Checkbox_Label=Show preview API for: > 125: doclet.Preview_JEP_URL=https://openjdk.java.net/jeps/{0} Use `openjdk.org` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 243: > 241: } > 242: ul.contents-list li { > 243: font-size: 13px; Do these values have to be normalized into `.em` units, to align with new themes? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 1346: > 1344: * @return the map of PreviewFeature.JEP annotation element values, or an empty map > 1345: */ > 1346: public Map getJepInfo(String feature) { This method should borderline be in `Workarounds.java` because you are accessing javac internal features, even if only reflectively. ------------- PR: https://git.openjdk.org/jdk/pull/9336 From jjg at openjdk.org Thu Aug 18 22:02:46 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 18 Aug 2022 22:02:46 GMT Subject: Integrated: JDK-8236048: Cleanup use of Utils.normalizeNewlines In-Reply-To: References: Message-ID: On Sat, 30 Jul 2022 00:36:06 GMT, Jonathan Gibbons wrote: > Please review a medium-size cleanup related to handling newlines in `Content`/`HtmlTree`/`Text[Builder]` trees. > This is the 3rd and last in the recent series of cleanup tasks in the code to generate HTML. > > Until recently, the `Text`/`TextBuilder` objects were "ready-for-writing", meaning that characters like `<`, `&`, etc were encoded as entities, and newlines were represented by the platform line separator. This caused difficulties when counting the size of generated text, since these characters had to be detected and accounted for. A recent change addressed entities, but stayed clear of the newline issue, which is now addressed here. > > A related performance problem is that the method `Utils.normalizeNewlines` always created new strings, even when it was not necessary. > > With this change, newlines in `Text`, `TextBuilder` and other subtypes of `Content` containing text are always represented by `\n`, and are converted to the platform line separator as needed. > > I note the following assumptions: > > * the input may contain any flavor of newlines in the user-provided documentation comments > * the output should aways use the platform line separator (`\n` on Linux and macOS, `\r\n` on Windows etc.) > > Together, these imply that some amount of the input will need to be scanned to normalize newlines at some point in the process. While it would be nice to not have to normalize newlines, it's a case or "pay now, or pay later". > > Notable parts of this change: > > * `Utils.normalizeNewlines` is moved to be a static method in `Text` and rewritten to not create new strings unless needed. This allows a number of questionable imports of `toolkit.utils.DocletConstants` to be removed from the `html.markup` package. While it would be possible to call this method automatically on all strings passed to `Text`, `TextBuilder` etc, in many cases it is not necessary: put another way, it only needs to be called on strings that have come from the user, either in documentation comments or in command-line options. > * `Content.write`, and the implementations thereof, are given a new parameter which gives the newline sequence to use. This is set to `\n` for `toString` and the platform separator when writing to a file. > * `DocletConstants.NL` goes away and is superseded by: > * `Text.NL`: always `\n`, to be used when adding text to a `Content` tree (this replaces most uses of `DocletConstants.NL`) > * `DocFile.PLATFORM_LINE_SEPARATOR`: the platform line separator, to be used when writing to files > * The various `charCount` methods no longer have to worry about use of the platform line separator > * Assertions are used to verify that there are no `\r` characters added into `Text`/`TextBuilder`/`RawHtml`/`Content` > > Other cleanup: > * `DocletConstants.DEFAULT_TAB_STOP_LENGTH` is moved to `BaseOptions` which is the only class that uses it. This leaves just two remaining constants in `DocletConstants` which should probably be moved elsewhere as well, and the `DocletConstants` class deleted. That is a step too far for the work here. > * Minor IDE-suggestions, for lambdas, enhanced switch, adding braces, etc > > One test was affected by the `DocletConstants.NL` change, but apart from that, this is a pure-cleanup change, with no (intentional) externally visible effect. This pull request has now been integrated. Changeset: 1b756bfa Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/1b756bfa3a1be2004af3ea12e86199ca0604c841 Stats: 246 lines in 26 files changed: 77 ins; 76 del; 93 mod 8236048: Cleanup use of Utils.normalizeNewlines Reviewed-by: hannesw ------------- PR: https://git.openjdk.org/jdk/pull/9691 From duke at openjdk.org Fri Aug 19 06:56:38 2022 From: duke at openjdk.org (Joe) Date: Fri, 19 Aug 2022 06:56:38 GMT Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to https [v2] In-Reply-To: References: Message-ID: > 8289562: Change bugs.java.com and bugreport.java.com URL's to https Joe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - changed the hrl from http to https JDK-8289562 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9445/files - new: https://git.openjdk.org/jdk/pull/9445/files/324f877c..07b7be0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=00-01 Stats: 142897 lines in 2088 files changed: 75388 ins; 52973 del; 14536 mod Patch: https://git.openjdk.org/jdk/pull/9445.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9445/head:pull/9445 PR: https://git.openjdk.org/jdk/pull/9445 From duke at openjdk.org Fri Aug 19 08:58:59 2022 From: duke at openjdk.org (Joe) Date: Fri, 19 Aug 2022 08:58:59 GMT Subject: Integrated: 8289562: Change bugs.java.com and bugreport.java.com URL's to https In-Reply-To: References: Message-ID: <3PKzwl7RxEVyWEBTVdySoL1eKjal-7IRGDANL2ABqG8=.7dc34842-62c6-40a5-8ce3-1bf0e9f58852@github.com> On Mon, 11 Jul 2022 08:04:20 GMT, Joe wrote: > 8289562: Change bugs.java.com and bugreport.java.com URL's to https This pull request has now been integrated. Changeset: 1f484dae Author: Joe Committer: Fairoz Matte URL: https://git.openjdk.org/jdk/commit/1f484dae4efaa60cf18a3d4df947c05f1497bd5b Stats: 18 lines in 17 files changed: 0 ins; 0 del; 18 mod 8289562: Change bugs.java.com and bugreport.java.com URL's to https Co-authored-by: Joe Cherian Reviewed-by: prr, jjg, naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/9445 From aturbanov at openjdk.org Tue Aug 23 07:43:32 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 23 Aug 2022 07:43:32 GMT Subject: RFR: 8289658: Avoid redundant LinkedHashMap.get call in TagletManager.addNewSimpleCustomTag [v4] In-Reply-To: <3nd9uNRqSEEzBEz0_KowRIn9zqaXNRQetzWP6ANQ5dY=.2e235c00-d64d-4653-8c89-b75064929c7e@github.com> References: <3nd9uNRqSEEzBEz0_KowRIn9zqaXNRQetzWP6ANQ5dY=.2e235c00-d64d-4653-8c89-b75064929c7e@github.com> Message-ID: On Mon, 1 Aug 2022 07:01:15 GMT, Andrey Turbanov wrote: >> Instead of pair `LinkedHashMap.get`+`LinkedHashMap.remove` calls, we can use value returned from single `allTaglets.remove` call. >> It's shorter and a bit faster. >> https://github.com/openjdk/jdk/blob/d46f404b3179c66e8e5775a9e2253c95238153c7/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java#L314-L325 > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289658: Avoid redundant LinkedHashMap.get call in TagletManager.addNewSimpleCustomTag > > improve comment I believe it's good enough. Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9137 From aturbanov at openjdk.org Tue Aug 23 07:46:51 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 23 Aug 2022 07:46:51 GMT Subject: Integrated: 8289658: Avoid redundant LinkedHashMap.get call in TagletManager.addNewSimpleCustomTag In-Reply-To: References: Message-ID: On Sat, 11 Jun 2022 10:52:29 GMT, Andrey Turbanov wrote: > Instead of pair `LinkedHashMap.get`+`LinkedHashMap.remove` calls, we can use value returned from single `allTaglets.remove` call. > It's shorter and a bit faster. > https://github.com/openjdk/jdk/blob/d46f404b3179c66e8e5775a9e2253c95238153c7/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java#L314-L325 This pull request has now been integrated. Changeset: b4e1aa87 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/b4e1aa87e3caa56bde52120bb3d84da53e7ebaa3 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod 8289658: Avoid redundant LinkedHashMap.get call in TagletManager.addNewSimpleCustomTag Reviewed-by: attila, prappo ------------- PR: https://git.openjdk.org/jdk/pull/9137 From jgneff at openjdk.org Mon Aug 29 21:12:53 2022 From: jgneff at openjdk.org (John Neffenger) Date: Mon, 29 Aug 2022 21:12:53 GMT Subject: RFR: 8292892: Javadoc index descriptions are not deterministic Message-ID: Please review these changes to the Javadoc index builders. This pull request adds 423 missing entries to the index of the JDK API Specification, corrects their package names in the member search index, and makes their descriptions deterministic. I'll follow up with more information in a separate comment. ------------- Commit messages: - Add a unit test case to verify the fix - Add members to index using containing type element Changes: https://git.openjdk.org/jdk/pull/10070/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10070&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292892 Stats: 312 lines in 6 files changed: 310 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10070.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10070/head:pull/10070 PR: https://git.openjdk.org/jdk/pull/10070 From jgneff at openjdk.org Mon Aug 29 21:41:09 2022 From: jgneff at openjdk.org (John Neffenger) Date: Mon, 29 Aug 2022 21:41:09 GMT Subject: RFR: 8292892: Javadoc index descriptions are not deterministic In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 21:03:34 GMT, John Neffenger wrote: > Please review these changes to the Javadoc index builders. This pull request adds 423 missing entries to the index of the JDK API Specification, corrects their package names in the member search index, and makes their descriptions deterministic. I'll follow up with more information in a separate comment. This is an interesting bug. It's the first one I've encountered that is impossible to miss with reproducible builds but might have been impossible to find without them. It also reveals a surprising feature of the Java language: inaccessible members can be made public by an intermediate subclass. That feature first caused problems for Javadoc in 2002 with bug JDK-4780441. The fix for that bug made it so that "inherited members from package private classes are now documented as though they were declared in the inheriting class." The fix was released in Java SE 5 ("Tiger"), adding the members to the pages of their inheriting classes. The members were added to the index in Java SE 15. Below is a description of the problem, as I understand it, and my proposed solution. ### The problem The Javadoc code refers to the type in which a member is found as the *containing type element* and stores it in its own `IndexItem` class. The type in which a member is declared is referred to as the *enclosing element.* The problem occurs because the code assumes that these two elements are always the same, yet for the few cases where members are otherwise inaccessible, they aren't. For example, there are four index items of `LOCCRC` in the `java.util.jar` package. They are shown below with their string values, where `iN` represents an instance of `IndexItem`. i1.getLabel() "LOCCRC" i1.getContainingTypeElement() "java.util.jar.JarEntry" i1.getElement().getEnclosingElement() "java.util.zip.ZipConstants" i2.getLabel() "LOCCRC" i2.getContainingTypeElement() "java.util.jar.JarFile" i2.getElement().getEnclosingElement() "java.util.zip.ZipConstants" i3.getLabel() "LOCCRC" i3.getContainingTypeElement() "java.util.jar.JarInputStream" i3.getElement().getEnclosingElement() "java.util.zip.ZipConstants" i4.getLabel() "LOCCRC" i4.getContainingTypeElement() "java.util.jar.JarOutputStream" i4.getElement().getEnclosingElement() "java.util.zip.ZipConstants" Index items are stored in a set, and the set's comparator function uses the index label and the enclosing element to determine whether an item is already in the set. The four items above appear the same to the comparator, so only the first one makes it into the set. The first one is just the one first found in the package directory when they are loaded in *directory order* (unsorted). So the random order in which the source files are stored by the file system in their directory determines which one of the items gets listed in the index. There's a related problem in the member search index. The class name of the containing type element is appended to the package name of the enclosing element. That works for most members, but for these specially-inherited members, it creates entries that don't exist. For example, the search index might list `java.util.zip.JarEntry.LOCCRC` and link it to the file `java/util/zip/JarEntry.html`. ### The solution The solution is to add a step to the comparator: when two index items are the same after comparing their labels and enclosing elements, make an additional comparison of their containing type elements. For the related problem in the member search index, the solution is to get the package name from the containing type element instead of from the enclosing element. The 423 new index entries are shown as insertions in the `git diff` files linked below: * [JDK API Index: Before vs. After JDK-8292892 ](https://gist.github.com/jgneff/cd3d1622bf1b5150e9dde8fd26c41cfc) * [JDK API Search: Before vs. After JDK-8292892](https://gist.github.com/jgneff/3c74d38ec7b46a29ebc4bb1282b47d16) As far as I can tell, all of the new entries are inherited from just the following members: package java.awt; abstract class AttributeValue { public int hashCode() {...} public String toString() {...} } package java.lang; abstract sealed class AbstractStringBuilder implements Appendable, CharSequence permits StringBuilder, StringBuffer { public IntStream chars() {...} public IntStream codePoints() {...} } package java.lang.foreign; public sealed interface MemoryLayout permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout { long bitAlignment(); long bitSize(); long byteSize(); boolean isPadding(); Optional name(); } package java.time.chrono; public interface ChronoLocalDate extends Temporal, TemporalAdjuster, Comparable { String toString(); long until(Temporal endExclusive, TemporalUnit unit); } package java.util.zip; interface ZipConstants { static final int CENATT = 36; ... static final int LOCVER = 4; } package jdk.incubator.vector; abstract class AbstractVector extends Vector { public final Vector castShape(VectorSpecies toSpecies, int part) {...} public final Vector check(Class elementType) {...} public final Vector check(VectorSpecies species) {...} public abstract Vector convertShape(Conversion conv, VectorSpecies rsp, int part); public final Vector convert(Conversion conv, int part) {...} public final VectorMask maskAll(boolean bit) {...} public DoubleVector reinterpretAsDoubles() {...} public FloatVector reinterpretAsFloats() {...} public IntVector reinterpretAsInts() {...} public LongVector reinterpretAsLongs() {...} public ShortVector reinterpretAsShorts() {...} public final VectorSpecies species() {...} } ------------- PR: https://git.openjdk.org/jdk/pull/10070 From prappo at openjdk.org Mon Aug 29 23:01:10 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 29 Aug 2022 23:01:10 GMT Subject: RFR: 8292892: Javadoc index descriptions are not deterministic In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 21:03:34 GMT, John Neffenger wrote: > Please review these changes to the Javadoc index builders. This pull request adds 423 missing entries to the index of the JDK API Specification, corrects their package names in the member search index, and makes their descriptions deterministic. I'll follow up with more information in a separate comment. I've checked the code, the tests and the resulting JDK API Documentation. All look good. That said, I leave it to Jon to make the final determination, as he's an expert in this area and knows a lot more about the problem of intermediate types than I do. Separately, thanks for using the JLS terminology (_package access_) for what is colloquially known as _package-private_ or _package-protected_. ------------- PR: https://git.openjdk.org/jdk/pull/10070 From jjg at openjdk.org Mon Aug 29 23:34:44 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 29 Aug 2022 23:34:44 GMT Subject: RFR: 8292892: Javadoc index descriptions are not deterministic In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 21:03:34 GMT, John Neffenger wrote: > Please review these changes to the Javadoc index builders. This pull request adds 423 missing entries to the index of the JDK API Specification, corrects their package names in the member search index, and makes their descriptions deterministic. I'll follow up with more information in a separate comment. Excellent analysis and write up. (Just) for the record, I will note there is potentially another case that could be tested, where the element with package access is not exposed until a couple of subtypes down, as compared to being exposed in a direct subtype. That would stress the use of `containingType` in the code. But the general policy of using and documenting these somewhat hidden elements is all a bit ugly anyway, and I don't know that this extra case appears in JDK. test/langtools/jdk/javadoc/doclet/testIndexInherited/TestIndexInherited.java line 111: > 109: public static void main(String... args) throws Exception { > 110: TestIndexInherited tester = new TestIndexInherited(); > 111: tester.runTests(m -> new Object[]{Path.of(m.getName())}); These days, you can simplify this down to just `tester.runTests();`. The implication of the method will check the signature of the test methods and provide the appropriate path automatically. test/langtools/jdk/javadoc/doclet/testIndexInherited/TestIndexInherited.java line 154: > 152: public void testSuperclass(Path base) { > 153: String dir = base.resolve("out").toString(); > 154: javadoc("-d", dir, "-sourcepath", testSrc, "-private", "pkg1", "pkg2"); At first glance, the use of the `-private` option does not seem to match the method name `testSuperclass` or its matching description (tests entries in the superclass). There are two characteristics here that seem to be getting mixed up: 1. testing subclasses and superclasses 2. testing with default access (document public and protected) and with "more" access, such as using `-package` or `-private` options. Ideally, the tests should test subclasses and superclasses with default access, and then repeat, testing subclasses and superclasses with "more" access, such as with `-private`. test/langtools/jdk/javadoc/doclet/testIndexInherited/pkg1/ClassA.java line 1: > 1: /* It's not wrong to use separate files, as you have for `ClassA`, `ClassB` and `ClassC` but generally the prevailing style these days is to generate small test files (like these) from text blocks in the main test file. This makes it easier to see the sources all together, and avoids the overhead of the legal block. That being said, The amount of text after the legal block puts these in the gray area where either style is OK. ------------- PR: https://git.openjdk.org/jdk/pull/10070 From jjg at openjdk.org Mon Aug 29 23:46:11 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 29 Aug 2022 23:46:11 GMT Subject: RFR: 8292892: Javadoc index descriptions are not deterministic In-Reply-To: References: Message-ID: <80ogxbgejZAkrRsrNOHRVUsp96Ui5nABIe7SrfVPDqI=.64e9dd8c-302d-4ae8-b35e-22b6306e30b6@github.com> On Mon, 29 Aug 2022 21:03:34 GMT, John Neffenger wrote: > Please review these changes to the Javadoc index builders. This pull request adds 423 missing entries to the index of the JDK API Specification, corrects their package names in the member search index, and makes their descriptions deterministic. I'll follow up with more information in a separate comment. _?The sins of the father are to be laid upon the children.?_ I see this arises from `ZipConstants`, authored in JDK 1.1, before the availability of `import static` in JDK 5 onwards. Early on, the use was eventually seen as something of an anti-pattern, with unappreciated implications for compatibility, meaning that once in the API, it is hard to remove them. While the approach in this PR is probably correct and for the best, it is depressing to see the exact same constants being defined multiple times in the documentation. ------------- PR: https://git.openjdk.org/jdk/pull/10070 From darcy at openjdk.org Tue Aug 30 00:12:33 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 Aug 2022 00:12:33 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac Message-ID: Update to remove support for -source/-target/--release 7 from javac. As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work. ------------- Commit messages: - Small refactoring to remove more stale code. - Remove effectively dead code. - Adjust data for CheckExamples test. - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java. - Merge branch 'master' into JDK-8173605 - Fix MultiReleaseJars.java. - Test fixes. - Clean langtools test run. - CheckExamples passes. - Type annotations. - ... and 13 more: https://git.openjdk.org/jdk/compare/76ee5495...f3095350 Changes: https://git.openjdk.org/jdk/pull/10074/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8173605 Stats: 4514 lines in 156 files changed: 25 ins; 4362 del; 127 mod Patch: https://git.openjdk.org/jdk/pull/10074.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074 PR: https://git.openjdk.org/jdk/pull/10074 From darcy at openjdk.org Tue Aug 30 00:20:09 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 Aug 2022 00:20:09 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy wrote: > Update to remove support for -source/-target/--release 7 from javac. > > As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work. Please also review the accompanying CSR: https://bugs.openjdk.org/browse/JDK-8293047 Note that the DEFAULT_METHODS enum constant is used indirectly by a test to force a class file's minor version bits to be set as if a preview feature were used. If some other idiom is available, the DEFAULT_METHOD constant could be removed. Tier 1 and tier 2 test results were clean with this changes. ------------- PR: https://git.openjdk.org/jdk/pull/10074 From darcy at openjdk.org Tue Aug 30 01:05:23 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 Aug 2022 01:05:23 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References:

Message-ID: <7caOzUK-O_rtHE24lEnLDODLPj_gvixrSSFI-Is5zS0=.78f37a82-868c-4719-9145-cb2bd8df0588@github.com> On Tue, 30 Aug 2022 00:16:09 GMT, Joe Darcy wrote: > Please also review the accompanying CSR: > > https://bugs.openjdk.org/browse/JDK-8293047 > > Note that the DEFAULT_METHODS enum constant is used indirectly by a test to force a class file's minor version bits to be set as if a preview feature were used. If some other idiom is available, the DEFAULT_METHOD constant could be removed. > > Tier 1 and tier 2 test results were clean with this changes. PS I'll run a copyright update script before any push. ------------- PR: https://git.openjdk.org/jdk/pull/10074 From alanb at openjdk.org Tue Aug 30 06:29:52 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Aug 2022 06:29:52 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy wrote: > Update to remove support for -source/-target/--release 7 from javac. > > As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work. test/jdk/java/lang/reflect/OldenCompilingWithDefaults.java line 28: > 26: * @bug 8009267 > 27: * @summary Verify uses of isAnnotationPresent compile under older source versions > 28: * @compile OldenCompilingWithDefaults.java I skimmed through the description of JDK-8009267 and I'm wondering if this test is of any value now. ------------- PR: https://git.openjdk.org/jdk/pull/10074 From darcy at openjdk.org Tue Aug 30 21:59:10 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 Aug 2022 21:59:10 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References:

Message-ID: On Tue, 30 Aug 2022 06:26:25 GMT, Alan Bateman wrote: >> Update to remove support for -source/-target/--release 7 from javac. >> >> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work. > > test/jdk/java/lang/reflect/OldenCompilingWithDefaults.java line 28: > >> 26: * @bug 8009267 >> 27: * @summary Verify uses of isAnnotationPresent compile under older source versions >> 28: * @compile OldenCompilingWithDefaults.java > > I skimmed through the description of JDK-8009267 and I'm wondering if this test is of any value now. Certainly less useful than it once was! I can remove it in the next push. ------------- PR: https://git.openjdk.org/jdk/pull/10074 From vromero at openjdk.org Wed Aug 31 17:17:07 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 31 Aug 2022 17:17:07 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy wrote: > Update to remove support for -source/-target/--release 7 from javac. > > As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work. looks good to me the PR looks good to me. You have mentioned that further refactorings could be done later on, I agree but you are already removing a lot of code, although that could have been forced to make some tests pass. I would recommend removing some support for 7 at `com.sun.tools.javac.comp.Infer` particularly the one guarded by `allowGraphInference`. I can also help with that later on if you prefer. If so please assign a follow-up for this issue to myself ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10074 From darcy at openjdk.org Wed Aug 31 17:25:09 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 31 Aug 2022 17:25:09 GMT Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option in javac In-Reply-To: References:

Message-ID: On Wed, 31 Aug 2022 17:13:04 GMT, Vicente Romero wrote: > the PR looks good to me. You have mentioned that further refactorings could be done later on, I agree but you are already removing a lot of code, although that could have been forced to make some tests pass. I would recommend removing some support for 7 at `com.sun.tools.javac.comp.Infer` particularly the one guarded by `allowGraphInference`. I can also help with that later on if you prefer. If so please assign a follow-up for this issue to myself Thanks Vicente; I assigned JDK-8293051: Further refactor javac after removal of -source/-target/--release 7 to you. ------------- PR: https://git.openjdk.org/jdk/pull/10074 From jjg at openjdk.org Wed Aug 31 18:18:36 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 31 Aug 2022 18:18:36 GMT Subject: RFR: JDK-8293178: Remove obsolete properties from javadoc resource file Message-ID: Please review a trivial update to remove some obsolete properties from a javadoc resource file. ------------- Commit messages: - JDK-8293178: Remove obsolete properties from javadoc resource file Changes: https://git.openjdk.org/jdk/pull/10105/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293178 Stats: 10 lines in 2 files changed: 0 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10105.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10105/head:pull/10105 PR: https://git.openjdk.org/jdk/pull/10105 From prappo at openjdk.org Wed Aug 31 20:59:08 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 31 Aug 2022 20:59:08 GMT Subject: RFR: JDK-8293178: Remove obsolete properties from javadoc resource file In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 18:11:09 GMT, Jonathan Gibbons wrote: > Please review a trivial update to remove some obsolete properties from a javadoc resource file. Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10105 From jjg at openjdk.org Wed Aug 31 22:16:12 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 31 Aug 2022 22:16:12 GMT Subject: Integrated: JDK-8293178: Remove obsolete properties from javadoc resource file In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 18:11:09 GMT, Jonathan Gibbons wrote: > Please review a trivial update to remove some obsolete properties from a javadoc resource file. This pull request has now been integrated. Changeset: 6f297346 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/6f297346dc34f58d10c64a7bbe4e0f5b52ed33e3 Stats: 10 lines in 2 files changed: 0 ins; 6 del; 4 mod 8293178: Remove obsolete properties from javadoc resource file Reviewed-by: prappo ------------- PR: https://git.openjdk.org/jdk/pull/10105