On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie wrote:
> The test
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
> verifies different failure modes of resource bundles. One of the failures is
> that the runner class, `MissingResourceCause
d at the of the
> day, testing file unreadability is not an important regression test for
> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
From code review: u
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato wrote:
>> The test
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
>> verifies different failure modes of resource bundles. One of the failures is
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a
On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy wrote:
>> Time to start getting ready for JDK 20...
>
> Joe Darcy 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
The test
`test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
verifies different failure modes of resource bundles. One of the failures is
that the runner class, `MissingResourceCauseTestRun.java`, creates a file
`UnreadableRB`, and runs `chmod 000` on it, to make it
On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie wrote:
> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2,
> since it does not properly detect this environment.
This pull request has now been integrated.
Changeset: f1dd559e
Author:Magnus Ihse Bursi
The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since
it does not properly detect this environment.
-
Commit messages:
- 8287896: PropertiesTest.sh fail on msys2
Changes: https://git.openjdk.java.net/jdk/pull/9057/files
Webrev:
On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>>
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
On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by core-libs, and accepted those changes
> where it indeed discovered real typos.
>
> I will update copyright years using a script before pushing (otherwise like
> every seco
much
> harder).
>
> The long term goal here is to make tooling support for running `codespell`.
> The trouble with 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 Bu
much
> harder).
>
> The long term goal here is to make tooling support for running `codespell`.
> The trouble with 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 up
On Wed, 27 Apr 2022 15:50:20 GMT, Roger Riggs 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
much
> harder).
>
> The long term goal here is to make tooling support for running `codespell`.
> The trouble with 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 Bu
On Wed, 27 Apr 2022 17:11:34 GMT, Pavel Rappo wrote:
>> I ran `codespell` on modules owned by core-libs, and accepted those changes
>> where it indeed discovered real typos.
>>
>> I will update copyright years using a script before pushing (otherwise like
>> every second change would be a
On Wed, 27 Apr 2022 15:45:12 GMT, Roger Riggs wrote:
>> I ran `codespell` on modules owned by core-libs, and accepted those changes
>> where it indeed discovered real typos.
>>
>> I will update copyright years using a script before pushing (otherwise like
>> every second change would be a
On Wed, 27 Apr 2022 16:50:30 GMT, Pavel Rappo wrote:
>> I ran `codespell` on modules owned by core-libs, and accepted those changes
>> where it indeed discovered real typos.
>>
>> I will update copyright years using a script before pushing (otherwise like
>> every second change would be a
On Wed, 27 Apr 2022 16:18:15 GMT, Naoto Sato wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties
>> line 188:
>>
>>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>>> 187:
>>> 188: main.plugin.category=\u7C7B\u522B
>>
>> what's this?
>
> Removing the
On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev
wrote:
>> - It is not possible to support native JDK commands such as "java" inside
>> Mac App Store bundles due to embedded info.plist. Workarounds suggested in
>> JDK-8286122 does not seems to be visible.
>> - With proposed fix we will
On 2022-05-12 13:17, Michael Hall wrote:
I had read this but possibly didn’t grok the issue myself. If I
understand correctly now the conflict isn’t within the application but
across applications to some other application that has already been
added to the Mac App Store that included the
On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Calculate char offset before realloc()
>
> Thanks for all to review this PR! I think we should separate this
On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change to the build system which now makes
> bundled zlib as the default for macos aarch64 systems?
>
> We have been running into various intermittent failures on macos aarch64
> systems for several
(cc:ing build-dev.)
On 2022-05-12 00:17, Michael Hall wrote:
Is this restricted somehow to Mac App Store applications?
Is a warning issued as stripping native commands may break application
functionality?
Is it not possible for the user to provide their own Info.plist with a
different
On Wed, 11 May 2022 19:14:54 GMT, Lance Andersen wrote:
>> make/autoconf/lib-bundled.m4 line 220:
>>
>>> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
>>> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS
>>> -I$TOPDIR/src/java.base/share/native/libzip/zlib"
>>> 220: if test "x$OPENJDK_TARGET_OS"
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which fixes build failures on macos
>> when using `--with-zlib=bundled`?
>>
>> With this change the build now passes (tested both with bundled and system
>> zlib variants).
>>
>> tier1, tier2
On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - copyright years
>> - disable format-nonliteral warning when building LIBSPLASHSCREEN with
>> bundled zlib
>> -
On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin wrote:
>> make/modules/jdk.jfr/Java.gmk line 26:
>>
>>> 24: #
>>> 25:
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>>
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the
>> `lossy-conversions` warning should not be
On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote:
>> Please review this patch adding new lint option, **lossy-conversions**, to
>> javac to warn about type casts in compound assignments with possible lossy
>> conversions.
>>
>> The new lint warning is shown if the type of the right-hand
On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which fixes build failures on macos
> when using `--with-zlib=bundled`?
>
> With this change the build now passes (tested both with bundled and system
> zlib variants).
>
> tier1, tier2 and tier3
On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>>
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>>
I ran `codespell` on modules owned by core-libs, and accepted those changes
where it indeed discovered real typos.
I will update copyright years using a script before pushing (otherwise like
every second change would be a copyright update, making reviewing much harder).
The long term goal here
On Thu, 21 Apr 2022 16:17:20 GMT, Kevin Walls wrote:
>> I ran `codespell` on modules owned by the serviceability team
>> (`java.instrument java.management.rmi java.management jdk.attach
>> jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi
>> jdk.jdwp.agent jdk.jstatd
On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs wrote:
>> I ran `codespell` on modules owned by the serviceability team
>> (`java.instrument java.management.rmi java.management jdk.attach
>> jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi
>> jdk.jdwp.agent jdk.jstatd
I ran `codespell` on modules owned by the serviceability team (`java.instrument
java.management.rmi java.management jdk.attach jdk.hotspot.agent
jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd
jdk.management.agent jdk.management`), and accepted those changes where
On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato wrote:
> Fixing performance regression caused by the fix to
> https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra
> looping through the resource map multiple times which was not necessary. The
> execution time of the tool now
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
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
> 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
> 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
On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `make` directory, and accepted those changes where
> it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> Most of the fix
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
I ran `codespell` on the `make` directory, and accepted those changes where it
indeed discovered real typos.
(Due to false positives this can unfortunately not be run automatically)
Most of the fixes are in comments. A few are in messages aimed at the user.
-
Commit messages:
-
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:
On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote:
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
> JDK version to target.
>
> We will refresh this PR periodically to pick up changes and fixes from the
> loom repo.
>
> Most of the new mechanisms in the
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's
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 *actua
lved, 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.desk
lved, 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
lved, 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.desk
On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote:
> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the
> https://openjdk.java.net/projects/riscv-port branch.
>
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
> Unmatched board.
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.
>
lved, 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
lved, 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.desk
> 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
lved, 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.desk
lved, 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.desk
lved, 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.desk
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
>> - Fix
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,
kay 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 by ja
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,
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,
lved, 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 Tue, 15 Mar 2022 08:17:24 GMT, Ioi Lam wrote:
>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry
On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote:
>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry
The Skara bots messed up this one badly. It was a reply to David's
comment, not Ioi's latest push.
/Magnus
On 2022-03-10 13:56, Magnus Ihse Bursie wrote:
On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote:
This patch makes the result of "java -Xshare:dump" deterministic:
- Disable
On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote:
>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry
On Wed, 9 Mar 2022 11:45:59 GMT, David Holmes wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed zero build
>
> The "heap dump" aspect of this is not something I'm familiar with, but if the
> threads don't affect
On Wed, 9 Mar 2022 07:58:51 GMT, Thomas Stuefe wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed zero build
>
> Hi Ioi,
>
> some questions, comments inline.
>
> Like David in the comments, I am also a bit vague
On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing wrote:
>> The caller class returned by Reflection::getCallerClass was used to gain
>> access to it's module in most cases and class loader in one case. I added a
>> method to translate the caller class to caller module so that the decision
>> of
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
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
On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote:
> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting
> this, together with a valid backend using `--with-hsdis`, will bundle the
> generated hsdis library with the JDK.
>
> The PR also include
t; breaking it out to a separate file `lib-hsdis.gmk`, and breaking the
> functionality up in separate functions per backend.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Somehow the tabs got converted to spaces
-
Ch
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
On Tue, 22 Feb 2022 16:54:21 GMT, Andrew Haley wrote:
> Maybe I missed it, but are there instructions somewhere about how to build
> this, and what should be downloaded?
See https://github.com/openjdk/jdk/blob/master/src/utils/hsdis/README.md
-
PR:
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
This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this,
together with a valid backend using `--with-hsdis`, will bundle the generated
hsdis library with the JDK.
The PR also includes a refactoring of the hsdis handling in autoconf, breaking
it out to a separate file
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 Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Build changes are OK
-
Marked as reviewed by ihse (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7447
On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote:
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
> null
Build changes LGTM.
-
Marked as reviewed by ihse (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7448
On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote:
> Exploratory builds indicate it is not currently necessary to exclude the
> doclint accessibility checks; this patch enables them.
>
> (Enabling the reference checks is left for future work.)
-
Marked as reviewed by ihse
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
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 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 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 Wed, 1 Dec 2021 11:06:12 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by:
On Mon, 22 Nov 2021 14:37:47 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to keep track of the last modified
On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch milliseconds) option to jar and
>> jmod to allow specification of time to use for created/updated jar/jmod
>> entries. This then allows the ability to make the content deterministic.
>>
>>
On Tue, 23 Nov 2021 19:23:40 GMT, Joe Darcy wrote:
>> 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
>>
On Tue, 23 Nov 2021 14:34:23 GMT, Andrew Leonard wrote:
>>> I've added updates to the jar and jmod man pages, as "Notes" about
>>> ordering, does that sound reasonable?
>>
>> The true source of the man pages are still kept in our closed repository.
>> The copy in the jdk repo is generated
On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote:
> 8277429: Conflicting jpackage static library name
Ok, I'm still a bit confused. Are executables converted to static libs (with a
main method?) when doing static builds? I thought this affected only dynamic
libraries. Are we sure that
On Tue, 23 Nov 2021 10:04:51 GMT, Andrew Leonard wrote:
>> Both jar and jmod utilise java.io file operations whose methods define no
>> ordering of the return file lists, and in fact rely on OS query file
>> ordering, which can differ by underlying OS architecture.
>> This PR adds sort
On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote:
> 8277429: Conflicting jpackage static library name
How come BUILD_JPACKAGE_APPLAUNCHEREXE results in a library? It sounds like an
executable...
That is, I realize this patch fixes the problem as described, I just don't
understand why
On Thu, 18 Nov 2021 11:05:54 GMT, Andrew Leonard wrote:
>> I'm guessing Mandy asks not if the keys are sorted -- this is changed by
>> your patch, but if the value retrieved -- the String[], is sorted. It's a
>> valid question, I think. It's not apparent to me at least that this is the
>>
On Thu, 18 Nov 2021 11:38:08 GMT, Andrew Leonard wrote:
>> Just to verify, this test jar had 16000 files in a single directory? Since
>> having 100 files in 160 directories would not have the same impact, right?
>
>> Just to verify, this test jar had 16000 files in a single directory? Since
>>
1 - 100 of 405 matches
Mail list logo
