On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs wrote:
>> This is a bit of forced move. Same thing with Thread.checkAccess and
>> ThreadGroup.checkAccess that also have to be re-specified to throw
>> unconditionally. They are called out in the CSR.
>
> OK
While I disagree with this change on th
On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd wrote:
>> OK
>
> While I disagree with this change on the principle of "the system should
> operate as if no security manager were installed", the workaround for callers
> is actually rather simple:
>
>
> if (System.getSecurityManager() != null
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman wrote:
>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>>
>>> 2428: @Deprecated(since="17", forRemoval=true)
>>> 2429: public void checkAccess() {
>>> 2430: throw new SecurityException();
>>
>> Though
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> mai
On Tue, 12 Mar 2024 15:07:47 GMT, Julian Waters wrote:
>>> I have verified that this works fine in the Oracle internal CI.
>>>
>>> Erik's point still stands:
>>>
>>> > I still think it would be prudent to verify this patch with all the
>>> > currently accepted versions of autoconf (2.69, 2.70,
On Tue, 15 Oct 2024 11:04:40 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update make/autoconf/flags-cflags.m4
>>
>> Co-authored-by: Magnus Ihse Bursie
>
> make/autoconf/flags-cflags.m
> Hi,
> Can you help to review the patch? Previously it's
> https://github.com/openjdk/jdk/pull/18605.
> This pr is based on https://github.com/openjdk/jdk/pull/20781.
>
> Thanks!
>
> ## Test
> ### tests:
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ### opti
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
> autoconf flags being added to the command line, and solves the issue by
> filtering out the added flags by force. This is not optimal however, as doing
> so leaves the autoconf message that the flags were added still
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Mon, 14 Oct 2024 13:08:32 GMT, Aleksey Shipilev wrote:
> This implicitly fixes x86-32 builds that fail at runtime, because late
> barrier expansion is not implemented for them. I think about this check as
> something that we should have done as part of original JDK-8334060.
>
> The first ve
On Mon, 14 Oct 2024 13:08:32 GMT, Aleksey Shipilev wrote:
> This implicitly fixes x86-32 builds that fail at runtime, because late
> barrier expansion is not implemented for them. I think about this check as
> something that we should have done as part of original JDK-8334060.
>
> The first ve
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
This is the implementation of JEP 486: Permanently Disable the Security
Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
[CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main
changes in the JEP and also includes an apidiff of the specification
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Thu, 5 Sep 2024 10:17:11 GMT, Alan Bateman wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked
>> check
>
> src/java.base/unix/native/li
On Thu, 5 Sep 2024 00:15:35 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked
>> check
>
> src/java.base/unix/native/li
> Please review this change that adds a new test root `docs` dedicated to
> testing the documentation, which has been a work in progress for a while.
> Tests for links, encoding, HTML, accessibility will be later added in
> following PRs.
>
> We also define a new make target `test-docs` meant
On Tue, 15 Oct 2024 17:57:44 GMT, Erik Joelsson wrote:
>> Nizar Benalla has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Whitespace
>
> make/RunTestsPrebuiltSpec.gmk line 182:
>
>> 180: ifneq ($(TIDY_HOME), )
>> 181: TIDY := $(TIDY_HOM
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Thu, 5 Sep 2024 20:41:35 GMT, Jiangli Zhou wrote:
>> You are right, this is dead code. Thanks for spotting this.
>>
>> During my experimentation, I tried passing along LDFLAGS from the individual
>> libraries as well, but it turned out not to be a good idea -- the way we
>> have used them
On Tue, 15 Oct 2024 18:50:27 GMT, Magnus Ihse Bursie wrote:
> After thinking a bit more on this, I concluded that we cannot automatically
> extract a proper set of ld flags from what's being passed to the individual
> libraries. The LDFLAGS needed by the monolithic static library needs to be
>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
On Mon, 14 Oct 2024 14:57:46 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review the patch? Previously it's
> https://github.com/openjdk/jdk/pull/18605.
> This pr is based on https://github.com/openjdk/jdk/pull/20781.
>
> Thanks!
>
> ## Test
> ### tests:
> * test/jdk/jdk/incubator/vector/
> *
On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao wrote:
>> This patch enables BTI branch protection for runtime part on Linux/aarch64
>> platform.
>>
>> Motivation
>>
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level
>> packages can gain additional hardening by compiling
On Tue, 15 Oct 2024 09:29:48 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory `jm
On Mon, 14 Oct 2024 21:47:00 GMT, Martin Doerr wrote:
>@offamitkumar: It could still be done after this PR is integrated, but I guess
>you want to provide an s390 implementation.
I haven't looked into it yet. I am looking into other issues for now, but I
will if I can get time to work on this.
On Mon, 9 Sep 2024 11:53:13 GMT, Thomas Schatzl wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/klass.hpp line 169
On Tue, 15 Oct 2024 12:42:40 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Tue, 15 Oct 2024 12:16:28 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch? Previously it's
>> https://github.com/openjdk/jdk/pull/18605.
>> This pr is based on https://github.com/openjdk/jdk/pull/20781.
>>
>> Thanks!
>>
>> ## Test
>> ### tests:
>> * test/jdk/jdk/incubator/v
On Fri, 12 Jan 2024 14:49:11 GMT, Julian Waters wrote:
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
> autoconf flags being added to the command line, and solves the issue by
> filtering out the added flags by force. This is not optimal however, as doing
> so le
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
On Thu, 19 Sep 2024 15:01:26 GMT, Hamlin Li wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2'
>> into JDK-8305895-v4
>> - review feedback
>
>
On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao wrote:
>> This patch enables BTI branch protection for runtime part on Linux/aarch64
>> platform.
>>
>> Motivation
>>
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level
>> packages can gain additional hardening by compiling
On Wed, 3 Apr 2024 14:40:42 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review the patch?
> This pr is based on previous work and discussion in [pr
> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
> 18294](https://github.com/openjdk/jdk/pull/18294).
> * NOTE: This pr depends on https:
Hi,
Can you help to review the patch? Previously it's
https://github.com/openjdk/jdk/pull/18605.
This pr is based on https://github.com/openjdk/jdk/pull/20781.
Thanks!
## Test
### tests:
* test/jdk/jdk/incubator/vector/
* test/hotspot/jtreg/compiler/vectorapi/
### options:
* -XX:UseSVE=1 -XX:+E
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> mai
On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd wrote:
>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>> it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad
>> idea. Always throwing a `SecurityException` is the s
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Tue, 15 Oct 2024 15:28:49 GMT, Nizar Benalla wrote:
>> Can I get a review for this patch that adds the necessary changes for local
>> support of the `tidy` library.
>>
>> The dependency can be retrieved by running `make/devkit/createTidyBundle.sh`
>> on Linux and MacOs systems.
>>
>> This
> Can I get a review for this patch that adds the necessary changes for local
> support of the `tidy` library.
>
> The dependency can be retrieved by running `make/devkit/createTidyBundle.sh`
> on Linux and MacOs systems.
>
> This dependency is primarily going to be used to test the generated
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
> Can I get a review for this patch that adds the necessary changes for local
> support of the `tidy` library.
>
> The dependency can be retrieved by running `make/devkit/createTidyBundle.sh`
> on Linux and MacOs systems.
>
> This dependency is primarily going to be used to test the generated
On Mon, 14 Oct 2024 11:04:44 GMT, Nizar Benalla wrote:
>> Can I get a review for this patch that adds the necessary changes for local
>> support of the `tidy` library.
>>
>> The dependency can be retrieved by running `make/devkit/createTidyBundle.sh`
>> on Linux and MacOs systems.
>>
>> This
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan wrote:
> While making `LogManager.checkAccess` be a no-op might be more convenient, it
> could unconditionally permit operations that formerly required a permission
> check: clearly a bad idea. Always throwing a `SecurityException` is the
> safest
On Tue, 15 Oct 2024 17:43:17 GMT, Erik Joelsson wrote:
>> Nizar Benalla has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove check in RunTests.gmk, different approach.
>> Remove environment_name TIDY_HOME
>
> make/RunTestsPrebuiltSpe
> Can I get a review for this patch that adds the necessary changes for local
> support of the `tidy` library.
>
> The dependency can be retrieved by running `make/devkit/createTidyBundle.sh`
> on Linux and MacOs systems.
>
> This dependency is primarily going to be used to test the generated
On Tue, 15 Oct 2024 17:57:59 GMT, Nizar Benalla wrote:
>> Can I get a review for this patch that adds the necessary changes for local
>> support of the `tidy` library.
>>
>> The dependency can be retrieved by running `make/devkit/createTidyBundle.sh`
>> on Linux and MacOs systems.
>>
>> This
On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>>
>>> 70: private static class StackWalkerHolder {
>>> 71: static final StackWalker STACK_WALKER =
>>> 72:
>>> StackWalker.getInstance(StackWalker
On Tue, 15 Oct 2024 18:39:50 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/unix/native/libjli/java_md.c line 509:
>>
>>> 507:
>>> 508: if (GetApplicationHome(path, pathsize)) {
>>> 509: if (JLI_IsStaticallyLinked()) {
>>
>> In passing, GetJREPath's function description includes "
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 8 Oct 2024 13:35:27 GMT, Magnus Ihse Bursie wrote:
>> Personally I think it is foolish to trust this compiler and rather than
>> dropping the optimisation level for the one file we've been lucky enough to
>> know has been compiled incorrectly, we should issue a fatal error if this
>> c
On Tue, 15 Oct 2024 18:59:32 GMT, Jiangli Zhou wrote:
>> After thinking a bit more on this, I concluded that we cannot automatically
>> extract a proper set of ld flags from what's being passed to the individual
>> libraries. The LDFLAGS needed by the monolithic static library needs to be
>> e
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main chan
On Tue, 15 Oct 2024 18:45:37 GMT, Nizar Benalla wrote:
>> Please review this change that adds a new test root `docs` dedicated to
>> testing the documentation, which has been a work in progress for a while.
>> Tests for links, encoding, HTML, accessibility will be later added in
>> following P
On Tue, 15 Oct 2024 18:46:55 GMT, Nizar Benalla wrote:
>> make/RunTestsPrebuiltSpec.gmk line 182:
>>
>>> 180: ifneq ($(TIDY_HOME), )
>>> 181: TIDY := $(TIDY_HOME)
>>> 182: endif
>>
>> This is worse than before. Please forget what I said initially about
>> `TIDY_HOME`, it should certainly not
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Tue, 15 Oct 2024 10:47:55 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
74 matches
Mail list logo
