> The time to get JDK 19 underway draws nigh, please review this usual set of
> start-of-release updates, including CSRs for the javac and javax.lang.model
> updates:
>
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
>
> JDK-8277514: Add source 19
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 iris (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6688
An exploratory build indicates that it is not necessary to disable the
accessibility doclint check for the java.naming module.
-
Commit messages:
- JDK-8278179: Enable all doclint warnings for build of java.naming
Changes: https://git.openjdk.java.net/jdk/pull/6688/files
Webrev:
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.
Looks good.
I don't think
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
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
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
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
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.
-
Commit messages:
- 8251400: Fix incorrect addition of library to test in
On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie wrote:
> This is basically Andrew's old patch that was backed out, with a single
> change: I'm using ZipFile instead of ZipInputStream to read in the original
> zip. The latter is not capable of reading the extended attributes that
>
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
-
Commit messages:
- 8278163: --with-cacerts-src
On Thu, 2 Dec 2021 19:12:37 GMT, Andrew Leonard wrote:
>> Oh, I didn't expand the diff far enough to actually see the context
>> correctly when I reviewed this as I would never have imagined the
>> conditional to be placed after the rule. While this will work as so far as
>> using the correct
On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie wrote:
> This is basically Andrew's old patch that was backed out, with a single
> change: I'm using ZipFile instead of ZipInputStream to read in the original
> zip. The latter is not capable of reading the extended attributes that
>
On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie wrote:
> This is basically Andrew's old patch that was backed out, with a single
> change: I'm using ZipFile instead of ZipInputStream to read in the original
> zip. The latter is not capable of reading the extended attributes that
>
On Thu, 2 Dec 2021 18:46:09 GMT, Erik Joelsson wrote:
>> this was my understanding:
>> https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
>>
>> This occurs after make has finished reading all the makefiles and the target
>> is determined to be out of date; so, the
On Thu, 2 Dec 2021 14:55:14 GMT, Magnus Ihse Bursie wrote:
> This is basically Andrew's old patch that was backed out, with a single
> change: I'm using ZipFile instead of ZipInputStream to read in the original
> zip. The latter is not capable of reading the extended attributes that
>
This is basically Andrew's old patch that was backed out, with a single change:
I'm using ZipFile instead of ZipInputStream to read in the original zip. The
latter is not capable of reading the extended attributes that contain the unix
permissions. (Why this is so, is not fully clear to me.
On Thu, 2 Dec 2021 18:03:50 GMT, Andrew Leonard wrote:
>> my assumption was the recipe gets resolved later
>
> this was my understanding:
> https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
>
> This occurs after make has finished reading all the makefiles and the
> The time to get JDK 19 underway draws nigh, please review this usual set of
> start-of-release updates, including CSRs for the javac and javax.lang.model
> updates:
>
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
>
> JDK-8277514: Add source 19
On Thu, 2 Dec 2021 17:48:04 GMT, Andrew Leonard wrote:
>> you make a valid point, but i've tested this numerous times, but let me
>> check again
>
> my assumption was the recipe gets resolved later
this was my understanding:
On Thu, 2 Dec 2021 17:46:35 GMT, Andrew Leonard wrote:
>> I would have expected to see something like:
>>
>> ifneq ($(CACERTS_SRC), )
>> GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>> else
>> GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/
>> endif
>>
>> at line 63.
>
> you make a valid
On Thu, 2 Dec 2021 17:35:36 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Gendata.gmk line 76:
>>
>>> 74: ifneq ($(CACERTS_SRC), )
>>> 75: GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>>> 76: endif
>>
>> Does this even work?! You are reassigning the variable after it has been
>> used.
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.
>>
>>
On Thu, 2 Dec 2021 17:33:49 GMT, Magnus Ihse Bursie wrote:
>> 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
>>
On Wed, 1 Dec 2021 18:30:06 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.
>
>
On Thu, 2 Dec 2021 14:29:00 GMT, Sean Mullan wrote:
> I don’t have any major concerns with this change, as long as the default
> cacerts are still the ones that are in the JDK. As an aside, using Mozilla's
> root certificates might be fine for TLS certificates, but if you need to
> support
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.
>>
>>
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.
>>
>>
On Thu, 2 Dec 2021 09:16:59 GMT, Alan Hayward wrote:
> @dholmes-ora
>
> Fixed flags based on comments on the CSR:
Flag updates look good - thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/6334
On Wed, 1 Dec 2021 18:47:41 GMT, Erik Joelsson wrote:
>> 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
>>
> 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
On Thu, 2 Dec 2021 00:09:31 GMT, Sergey Bylokhov wrote:
> I have a question related to the custom cacerts which can be added to the
> OpenJDK bundle. How do you pass the tests like
> test/jdk/sun/security/lib/cacerts/VerifyCACerts.java using that custom jdk
> bundle? Probably we can add an
On Mon, 22 Nov 2021 17:35:41 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value when it is loaded back from the stack. If an
> attacker
34 matches
Mail list logo
