On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Build changes look good. Thanks for the cleanu
On Thu, 21 Apr 2022 13:51:27 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by the security team (`java.security.jgss
> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jg
automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Revert changes to Apach
On Thu, 21 Apr 2022 14:11:08 GMT, Alan Bateman wrote:
>> I ran `codespell` on modules owned by the security team (`java.security.jgss
>> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
>> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>> acce
I ran `codespell` on modules owned by the security team (`java.security.jgss
java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
accepted those changes where it indeed discovered real typos.
I will up
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majori
On Tue, 19 Apr 2022 16:24:43 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>
> local variable name, and a couple in parameter declarations.
>
> Annoyingly, there are several instances of "childs" (instead of "children")
> in the source code, but they were not local and I dared not change them.
> Someone braver than me might take a stab
> local variable name, and a couple in parameter declarations.
>
> Annoyingly, there are several instances of "childs" (instead of "children")
> in the source code, but they were not local and I dared not change them.
> Someone braver than me might take a stab
> local variable name, and a couple in parameter declarations.
>
> Annoyingly, there are several instances of "childs" (instead of "children")
> in the source code, but they were not local and I dared not change them.
> Someone braver than me might take a stab
I ran `codespell` on the `src/java.base` directory, and accepted those changes
where it indeed discovered real typos.
(Due to false positives this can unfortunately not be run automatically)
The majority of fixes are in comments. A handful is in strings, one in a local
variable name, and a cou
On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote:
>> Found various typos of expected: `exepected`, `exept`, `epectedly`,
>> `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8284853: Fi
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
> 18 mars 2022 kl. 11:04 skrev Alan Bateman :
>
> I can't tell if you are planning to integrate this or wait until there is
> discussion on the locations proposed in the Informational JEP that you've
> just submitted. Maybe you plan to just integrate and then adjust/move again
> if needed?
I
On Wed, 16 Dec 2020 18:34:37 GMT, Naoto Sato wrote:
>>> @AlanBateman The process of modularization was not fully completed with
>>> Project Jigsaw, and a few ugly warts remained. I was under the impression
>>> that these should be addressed in follow-up fixes, but this was
>>> unfortunately ne
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On Wed, 16 Mar 2022 21:31:08 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 12 commits:
>>
>> - Merge branch 'master' into shuffle-data-reborn
>&
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is
at sound okay to you?
/Magnus
-Alan
On 15/03/2022 23:59, Magnus Ihse Bursie wrote:
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie
wrote:
A lot (but not all) of the data in make/data is tied to a specific
module. For instance, the publicsuffixlist is used by java.base,
and fontconfig
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is
On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> What problem are you having editing the PR header? You should be able to do
> so as the author of the PR
@LanceAnde
On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the
> appropriate reviewers and avoid eye-strain. The c
On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeliński wrote:
>> Please review this PR that enables
>> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
>> compiler flag, which makes assigning a string liter
On Tue, 22 Feb 2022 14:13:43 GMT, Daniel Jeliński wrote:
>> make/autoconf/flags-cflags.m4 line 136:
>>
>>> 134: CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>>> 135:
>>> 136: WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
>>
>> This is not strictly a flag to enable warnings. I'd recommend you mov
On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeliński wrote:
> Please review this PR that enables
> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
> compiler flag, which makes assigning a string literal
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 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.
>>
>> Si
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 contai
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in java.xml and
> java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
> order, and fixes it otherwise. I have manually checked the cha
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in java.xml and
> java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
> order, and fixes it otherwise. I have manually checked the cha
I ran bin/blessed-modifier-order.sh on source code in java.xml and
java.xml.crypto. This scripts verifies that modifiers are in the "blessed"
order, and fixes it otherwise. I have manually checked the changes made by the
script to make sure they are sound.
-
Commit messages:
- 827
On Thu, 4 Nov 2021 11:19:34 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the scr
On Thu, 4 Nov 2021 17:21:40 GMT, Magnus Ihse Bursie wrote:
>> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This
>> scripts verifies that modifiers are in the "blessed" order, and fixes it
>> otherwise. I have manually checked the change
> I ran bin/blessed-modifier-order.sh on source owned by security-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure they are sound.
Magnus Ihse Bursi
I ran bin/blessed-modifier-order.sh on source owned by security-libs. This
scripts verifies that modifiers are in the "blessed" order, and fixes it
otherwise. I have manually checked the changes made by the script to make sure
they are sound.
-
Commit messages:
- 8276632: Use bles
On Fri, 15 Oct 2021 14:56:23 GMT, Weijun Wang wrote:
>> If that means the build will become non-reproducible, then *I* certainly
>> have thoughts about it! ;-)
>
> The certificate stored in a PKCS12 file has no date associated. Whenever you
> load a keystore, the creation time is set to the loa
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote:
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
Marked as reviewed by
On Fri, 15 Oct 2021 14:02:15 GMT, Sean Mullan wrote:
>> The cacerts file is now a password-less PKCS12 file. This make sure old code
>> that uses a JKS KeyStore object can continuously load it using a null
>> password (in fact, any password) and see all certificates inside.
>
> make/jdk/src/cla
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Thu, 11 Mar 2021 09:25:34 GMT, Magnus Ihse Bursie wrote:
>> Disable the "missing" target for java.smartcardio from doclint.
>
> Looks good to me.
... however, this fix does not achieve what the bug report is asking for.
The patch here will modify flags to javac. The
On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote:
> Disable the "missing" target for java.smartcardio from doclint.
Revoking approval.
-
Changes requested by ihse (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2930
On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote:
> Disable the "missing" target for java.smartcardio from doclint.
Looks good to me.
-
Marked as reviewed by ihse (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2930
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley wrote:
>> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.
>
>> > Umm, so how does patching work? We don't even know if other threads are
>> > executing the code we need to patch.
>>
>> I thought java can handle that scenario in
On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> make/autoconf/flags.m4 line 140:
>
>> 138: else
>> 139: MACOSX_VERS
On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>> libosxkrb5/SCDynamicStoreConfig.m](https://b
On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward
wrote:
> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>
> Unless there's something I'm missing it only requires a few lines of change
> to src/utils/hsdis/makefile (it already has support for macos x86_64)
I agree
On Sun, 31 Jan 2021 18:45:19 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>> libosxkrb5/SCDynamicStoreConfig.m](https://
On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster
wrote:
>> @luhenry , could you please check this comment, I think SA-agent was MS's
>> job here.
>
> The target is identified by the header file now:
> https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083
On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik wrote:
>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>>
>>> 1273: UNAME_PROCESSOR="aarch64"
>>> 1274: fi
>>> 1275: fi ;;
>>
>> Almost, but not quite, correct. We cannot change the a
On 2021-01-26 13:09, Vladimir Kempik wrote:
On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward
wrote:
AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`--with-extra-ldflags='-F
/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework
On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman wrote:
> We should create a separate issue to rename them and get rid of the copying
> in the make file.
I opened https://bugs.openjdk.java.net/browse/JDK-8260406.
-
PR: https://git.openjdk.java.net/jdk/pull/1611
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman When I moved the charset templates, I found this
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On 2021-01-15 19:27, mark.reinh...@oracle.com wrote:
Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of 2014.
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman That sounds like an excellent idea. I'll update
On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote:
>> Magnus Ihse Bursie 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 ei
On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman wrote:
>> I think this is almost ready to be pushed, but I'd like to have someone from
>> the client team review the changes for java.desktop as well. @prrace Any
>> change you can have a look at this?
>
> I think it will be annoying to have the ch
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `character
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [ ] java.desktop
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [ ] java.base
> - [ ] java.desktop
&
On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each ch
On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each cha
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the `$MODULE`
>> part is essent
On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie wrote:
>> Hi Magnus,
>>
>> I see the motivation of moving these build files for better identification
>> of ownership. Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option. Given that skara wi
On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote:
>> I have reviewed all lines in the patch file with or near instances of
>> `jdk.compiler`
>
> Hi Magnus,
>
> I see the motivation of moving these build files for better identification of
> ownership. Placing them under
> `src/$MODULE/{shar
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
Magnus Ihse Bursie has updated the pull request incrementally with one
additio
On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie wrote:
>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered
> JEP, but this is the text I suggest should replace the current definition
On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote:
>> Regarding the chosen layout. Did you consider following the existing pattern
>> of src//{share,}/data?
>
> @erikj79 Good point, that makes much more sense.
I'm not sure about the formal process for suggesting
On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote:
>> My understanding of JEPs is that they should be viewed as living documents.
>> In this case, I think it's perfectly valid to update JEP 201 with additional
>> source code layout. Both for this and for the other missing dirs.
>
> Regarding
On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote:
>> Are you proposing any text or guidelines to be added to JEP 201 as part of
>> this?
>>
>> I think the location of jdwp.spec and its location in the build tree may
>> need to be looked at again. It wa
On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote:
>> To facilitate review, here is a list on how the different directories under
>> make/data has moved.
>>
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsr
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually
A lot (but not all) of the data in make/data is tied to a specific module. For
instance, the publicsuffixlist is used by java.base, and fontconfig by
java.desktop. (A few directories, like mainmanifest, is *actually* used by make
for the whole build.)
These data files should move to the module
On Tue, 17 Nov 2020 21:33:13 GMT, Magnus Ihse Bursie wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> This PR looks seriously messed up:
>
> JimLaskey added 30 commits on Oct 9
> @Jim
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
This PR looks seriously messed up:
JimLaskey added 30 commits
On Tue, 22 Sep 2020 14:04:55 GMT, Sean Mullan wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove JDKOPT_DETECT_INTREE_EC from configure.ac
>
> throw new IllegalStateException(
> new InvalidA
Sorry for being late on this one (I'm working through a huge backlog),
but it does not seem like the removal was complete.
ENABLE_INTREE_EC is still present in spec.gmk. And it is still checked
in modules/jdk.crypto.ec/Lib.gmk. In fact, this entire file should be
removed.
Anthony, can you pl
On Fri, 23 Oct 2020 14:06:22 GMT, Maurizio Cimadamore
wrote:
>> Changes requested by ihse (Reviewer).
>
> @magicus the files you commented on are not part of this PR, but they are
> introduced as part of:
> https://git.openjdk.java.net/jdk/pull/548
> (you seemed to have approved the changes the
On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393
On Mon, 19 Oct 2020 10:34:32 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * f
On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393
On Mon, 12 Oct 2020 10:50:48 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the
>> API in 3 main ways:
>> * fir
On 2020-09-29 13:17, Kim Barrett wrote:
On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote:
On Sep 28, 2020, at 11:13 AM, Eric Liu wrote:
Hi,
Thanks for looking at this.
For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches
we talked previous don't work).
I'm tryi
On 2020-09-02 09:50, Kim Barrett wrote:
On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie
wrote:
On 2020-09-01 11:46, Kim Barrett wrote:
I really hate -Wstringop-truncation. It's been a constant source of churn
for us ever since it appeared. The changes being made to getIndex and
get
On 2020-09-01 11:46, Kim Barrett wrote:
On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
Hi all,
Please review this simple change to fix some compile warnings.
The newer gcc (gcc-8 or higher) would warn for calls to bounded string
manipulation functions such as 'strncpy' that may either truncate t
Otherwise looks good.
/Erik
On 2018-06-07 13:22, Magnus Ihse Bursie wrote:
This change needs some background information.
I've been working on simplifying and streamlining the compilation of
native libraries of the JDK. Previously, I introduced the
SetupJdkLibrary function, and started t
1 - 100 of 147 matches
Mail list logo
