RFR: 8278251: Enable "missing-explicit-ctor" check in the jdk.unsupported.desktop module
The "missing-explicit-ctor" check was disabled by the [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853). So we can re-enable this check again. The fix will remove the "Java.gmk" file and as a result the "jdk.unsupported.desktop" folder. All "Pre-submit tests" builds are green. - Commit messages: - Delete Java.gmk Changes: https://git.openjdk.java.net/jdk/pull/6708/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6708=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278251 Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6708.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6708/head:pull/6708 PR: https://git.openjdk.java.net/jdk/pull/6708
Re: RFR: JDK-8278175: Enable all doclint warnings for build of java.desktop
On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy wrote: > In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. > Therefore, it is now possible to enable the full doclint checks for the > java.desktop module if the instances of warnings are suppressed. This patch > does this; it would be preferable to address the doc warnings directly, but > that is beyond what I'm attempting to do here. > Sure; filed JDK-8278254 Cleanup doclint warnings in java.desktop module - PR: https://git.openjdk.java.net/jdk/pull/6687
Integrated: JDK-8278175: Enable all doclint warnings for build of java.desktop
On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy wrote: > In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. > Therefore, it is now possible to enable the full doclint checks for the > java.desktop module if the instances of warnings are suppressed. This patch > does this; it would be preferable to address the doc warnings directly, but > that is beyond what I'm attempting to do here. This pull request has now been integrated. Changeset: 02ee337a Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/02ee337ae0d163ae44b1691eb9de12c5608ba178 Stats: 34 lines in 20 files changed: 16 ins; 0 del; 18 mod 8278175: Enable all doclint warnings for build of java.desktop Reviewed-by: erikj, prr - PR: https://git.openjdk.java.net/jdk/pull/6687
Re: RFR: JDK-8278175: Enable all doclint warnings for build of java.desktop
On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy wrote: > In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. > Therefore, it is now possible to enable the full doclint checks for the > java.desktop module if the instances of warnings are suppressed. This patch > does this; it would be preferable to address the doc warnings directly, but > that is beyond what I'm attempting to do here. Looks OK. Could you file a P4 bug showing the warnings/errors that would be generated so that we know what we need to work on to later remove these the right way. - Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6687
Re: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2]
On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard wrote: >> Addition of a configure option --with-cacerts-src='user cacerts folder' to >> allow developers to specify their own cacerts PEM folder for generation of >> the cacerts store using the deterministic openjdk GenerateCacerts tool. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard 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 four additional > commits since the last revision: > > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable > deterministic cacerts generation > >Signed-off-by: Andrew Leonard > - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable > determinsitic cacerts generation > >Signed-off-by: Andrew Leonard > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable > determinsitic cacerts generation > >Signed-off-by: Andrew Leonard The purpose of this test is to ensure integrity of the cacerts file along with basic validation of included roots. Having a config file with this information sounds like a good idea for now to be able to handle multiple files. - PR: https://git.openjdk.java.net/jdk/pull/6647
Re: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard wrote: > This is the case at Adoptium for example, which uses the Mozilla trusted CA > certs. But they didn't think skipping this test was too strong a step? For example validation of the certs expiration is quite useful. I tried to update the test to take into account additional certs, but it caused a merge conflict each time the certs in OpenJDK are updated. Probably we can add a config file that can inject/override some info in the test(at least skip the checksum validation)? By default this config file will be empty and will not be modified in the OpenJDK, but the vendors will be able to modify it. @wangweij @rhalade what do you think? - PR: https://git.openjdk.java.net/jdk/pull/6647
Integrated: JDK-8278179: Enable all doclint warnings for build of java.naming
On Fri, 3 Dec 2021 03:28:46 GMT, Joe Darcy wrote: > An exploratory build indicates that it is not necessary to disable the > accessibility doclint check for the java.naming module. This pull request has now been integrated. Changeset: 780b8b10 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/780b8b1072811208968e4f32f5368eab622fcdcc Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8278179: Enable all doclint warnings for build of java.naming Reviewed-by: iris, erikj - PR: https://git.openjdk.java.net/jdk/pull/6688
Integrated: 8251400: Fix incorrect addition of library to test in JDK-8237858
On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie wrote: > In JDK-8237858, -pthread was added to all native tests, instead of the one > single test that needed it. In the meantime, two new tests with pthread > dependencies has crept in unnoticed due to this. This pull request has now been integrated. Changeset: fbf096ee Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/fbf096eea46756bdac6f474266caec500c4dc5c5 Stats: 13 lines in 2 files changed: 5 ins; 7 del; 1 mod 8251400: Fix incorrect addition of library to test in JDK-8237858 Reviewed-by: dholmes, erikj - PR: https://git.openjdk.java.net/jdk/pull/6682
Re: RFR: 8251400: Fix incorrect addition of library to test in JDK-8237858
On Fri, 3 Dec 2021 03:22:03 GMT, David Holmes wrote: >> In JDK-8237858, -pthread was added to all native tests, instead of the one >> single test that needed it. In the meantime, two new tests with pthread >> dependencies has crept in unnoticed due to this. > > Looks good. > > I don't think `-pthread` would actually hurt anything though. > > Thanks, > David @dholmes-ora I agree that it's mostly benign in this case, but where do you draw the line? For every library you can argue "this does not really hurt to include on all tests" and suddenly you have a very complex testing environment if all tests have all libraries all the time... - PR: https://git.openjdk.java.net/jdk/pull/6682
Re: RFR: JDK-8272945: Use snippets in java.compiler documentation
On Fri, 3 Dec 2021 00:41:23 GMT, Magnus Ihse Bursie wrote:
>> Please review a patch to use snippets in the `java.compiler` documentation,
>> instead of a mix of raw HTML and/or `{@code ...}`. The change is just about
>> the presentation of the code fragments; there are no changes to the
>> normative specifications for the module.
>>
>> One of the examples went to extraordinary lengths to include the character
>> sequence `*/` within the example. That example has been replaced by an
>> external snippet in a separate source file, which does not have any
>> restriction on the use of `*/`. However, it does require that the file be
>> excluded from standard compilation, and that is done by setting `EXCLUDES`,
>> once for the "interim" compiler, and once again for the "product" compiler.
>> Going forward, a better solution might be to modify the
>> `SetupJavaCompilation` macro to ignore all directories whose name is not a
>> valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or
>> `snippet-files`.)
>
> make/modules/java.compiler/Java.gmk line 30:
>
>> 28:
>> 29: EXCLUDES += \
>> 30: javax/tools/snippet-files \
>
> You can put this just on a single line :-).
>
> And I'm frankly not sure if make is happy about having a trailing backslash
> but no additional line...
As long as the next line is empty, it works, but it's not a good idea. That's
why we came up with the terminating # in our 1 element per line lists. In this
case, I would prefer a single line assignment without any backslashes.
-
PR: https://git.openjdk.java.net/jdk/pull/6686
Re: RFR: JDK-8278179: Enable all doclint warnings for build of java.naming
On Fri, 3 Dec 2021 03:28:46 GMT, Joe Darcy wrote: > An exploratory build indicates that it is not necessary to disable the > accessibility doclint check for the java.naming module. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6688
Re: RFR: 8251400: Fix incorrect addition of library to test in JDK-8237858
On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie wrote: > In JDK-8237858, -pthread was added to all native tests, instead of the one > single test that needed it. In the meantime, two new tests with pthread > dependencies has crept in unnoticed due to this. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6682
Re: RFR: JDK-8278175: Enable all doclint warnings for build of java.desktop
On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy wrote: > In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. > Therefore, it is now possible to enable the full doclint checks for the > java.desktop module if the instances of warnings are suppressed. This patch > does this; it would be preferable to address the doc warnings directly, but > that is beyond what I'm attempting to do here. Build change looks good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6687
Integrated: 8278163: --with-cacerts-src variable resolved after GenerateCacerts recipe setup
On Thu, 2 Dec 2021 21:07:30 GMT, Andrew Leonard wrote: > PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC > fir --with-cacerts-src after the recipe, which meant the dependencies were > wrong. > This PR moves it before the recipe. > > Signed-off-by: Andrew Leonard This pull request has now been integrated. Changeset: 45da3aea Author:Andrew Leonard URL: https://git.openjdk.java.net/jdk/commit/45da3aea22fd85f214e661b2c98631cb91ddb55d Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod 8278163: --with-cacerts-src variable resolved after GenerateCacerts recipe setup Reviewed-by: ihse - PR: https://git.openjdk.java.net/jdk/pull/6680
Re: RFR: JDK-8272945: Use snippets in java.compiler documentation
On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons wrote:
> Please review a patch to use snippets in the `java.compiler` documentation,
> instead of a mix of raw HTML and/or `{@code ...}`. The change is just about
> the presentation of the code fragments; there are no changes to the normative
> specifications for the module.
>
> One of the examples went to extraordinary lengths to include the character
> sequence `*/` within the example. That example has been replaced by an
> external snippet in a separate source file, which does not have any
> restriction on the use of `*/`. However, it does require that the file be
> excluded from standard compilation, and that is done by setting `EXCLUDES`,
> once for the "interim" compiler, and once again for the "product" compiler.
> Going forward, a better solution might be to modify the
> `SetupJavaCompilation` macro to ignore all directories whose name is not a
> valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or
> `snippet-files`.)
src/java.compiler/share/classes/javax/tools/JavaCompiler.java line 189:
> 187: * source code stored in a string:
> 188: *
> 189: * {@snippet id=fileObject class=JavaSourceFromString }
JEP 413 uses the "file" attribute for external snippets, so using "class" here
is new (to me anyway). Maybe the JEP should include an example that uses it.
Is this the first use of an external snippet in the src tree? I suspect files
in the snippet-files directory will need a copyright header (downstream
builders will report issues on this). It's not clear to me how that works if
@replace region replacement="" isn't the first line of the external file.
-
PR: https://git.openjdk.java.net/jdk/pull/6686
