Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v2]

On Wed, 1 Jun 2022 21:07:16 GMT, Xue-Lei Andrew Fan wrote: >> This is a follow up update per comments in [JDK-8287384 >> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in >> open part looks good to me. Please help to run Mach5 just case the closed >> test cases are

Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC

On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan wrote: > This is a follow up update per comments in [JDK-8287384 > PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in > open part looks good to me. Please help to run Mach5 just case the closed > test cases are

Re: RFR: 8285890: Fix some @param tags

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 > (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not > included in the API Documentation, are visible in and processed

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5]

On Thu, 28 Apr 2022 18:24:33 GMT, Andrey Turbanov wrote: >> 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 request contains seven additional commits

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4]

On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), >> please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated >> out

Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes

On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of > proxies (requires change in "Java Object Serialization Specification"). Makes > the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The

Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v3]

On Mon, 21 Mar 2022 20:19:03 GMT, Kevin Walls wrote: >> Removing permission checks which, in the presence of a Security Manager, >> would check for a RuntimePermission "className.subclass". This was to >> prevent subclassing these classes, but is no longer necessary with strong >>

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

On Mon, 21 Mar 2022 16:29:25 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* used by

Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v2]

On Fri, 18 Mar 2022 17:49:05 GMT, Kevin Walls wrote: >> Removing permission checks which, in the presence of a Security Manager, >> would check for a RuntimePermission "className.subclass". This was to >> prevent subclassing these classes, but is no longer necessary with strong >>

Re: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed [v2]

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote: >> Remove the use of Security Manager from jstatd. >> Add use of an ObjectInputFilter to restrict RMI. >> >> Also we can undo the property-setting Launcher.gmk change from: 8279007: >> jstatd fails to start because SecurityManager is

Re: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed [v2]

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote: >> Remove the use of Security Manager from jstatd. >> Add use of an ObjectInputFilter to restrict RMI. >> >> Also we can undo the property-setting Launcher.gmk change from: 8279007: >> jstatd fails to start because SecurityManager is

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian wrote: >> src/java.base/share/classes/java/lang/Object.java line 481: >> >>> 479: * system resources or to perform other cleanup. >>> 480: * >>> 481: * When running in a Java virtual machine in which finalization >>> has been >>

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java > API" portion of JEP 421 ("Deprecate Finalization for Removal") for code > review. > > This change makes the indicated deprecations, and updates the API

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java > API" portion of JEP 421 ("Deprecate Finalization for Removal") for code > review. > > This change makes the indicated deprecations, and updates the API

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for > launching various applications in one JVM was used to reduce memory usage and > each application was isolated from each other. > > This isolation was

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote: > Hmm I was under the impression this was removing AppContext itself but it is > just removing the backdoor needed by logging > Perhaps this isn't the change that requires the CSR but it then leaves an > inconsistent state where desktop

Re: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v7]

On Tue, 27 Jul 2021 02:50:54 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of >> java.security.SecurityManager. Now that JEP 411 has been integrated, this >> class should be updated to no longer subclass SecurityManager. >> >> The only reason for using

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11]

On Mon, 12 Jul 2021 05:21:34 GMT, Yi Yang wrote: > I'm not familiar with the review process of core-lib group. Is it sufficient > for merging with one approval? Should I have more reviews for this? 樂 It depends on the change. For this patch, it's good to get another reviewer to look through

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11]

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of >> checkIndex by >> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in >> the whole JDK codebase. > > Yi Yang has refreshed the contents of this pull

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]

On Wed, 7 Jul 2021 16:22:25 GMT, Mandy Chung wrote: >> Hi Mandy, thanks for reviewing this. >> >>> I suggest to separate the client changes (both src and test) in a separate >>> PR for the client review. >> >> Does "client changes" means

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]

On Wed, 7 Jul 2021 02:10:10 GMT, Yi Yang wrote: > Does "client changes" means changes involving src/java.desktop and > test/java/awt? src/java.desktop, test/java/awt, and test/javax/imageio - PR: https://git.openjdk.java.net/jdk/pull/4507

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]

On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of >> checkIndex by >> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in >> the whole JDK codebase. > > Yi Yang has updated the pull request

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes wrote: >> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest >> version? Thanks. > > @kelthuzadx I did not see any response to my query about the change in > initialization (not load) order. I also remain concerned about

Re: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v4]

On Fri, 4 Jun 2021 10:14:21 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 109: >> >>> 107: @SuppressWarnings("removal") >>> 108: List stack = >>> 109: AccessController.doPrivileged(pa).walk(Stream::toList); >>

Re: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v4]

On Thu, 3 Jun 2021 22:27:16 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of >> java.security.SecurityManager. Now that JEP 411 has been integrated, this >> class should be updated to no longer subclass SecurityManager. >> >> The only reason for using

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. >

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityManager()` need >

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v15]

On Mon, 10 May 2021 18:15:01 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3]

On Fri, 30 Apr 2021 12:24:38 GMT, Maurizio Cimadamore wrote: > I've added `@CS` in the interface methods too. I've also added a stronger > test which creates method handles in one module (which doesn't have native > access) and then calls them from another module (which does NOT have native

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3]

On Thu, 29 Apr 2021 10:31:29 GMT, Maurizio Cimadamore wrote: > I think I expect that, with caller sensitive, it is possible from a client in > an "enabled" module to obtain a MethodHandle, and then pass it to an > unprivileged module, which then calls it, and works ok. This matches my >

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3]

On Wed, 28 Apr 2021 21:10:33 GMT, Maurizio Cimadamore wrote: > I just did a test: > > ``` > public class TestLookup { > public static void main(String[] args) throws Throwable { > MethodHandle handle = > MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", >

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3]

On Wed, 28 Apr 2021 20:38:47 GMT, Maurizio Cimadamore wrote: > To be clear - by aliasing you mean when the @CallerSensitive implementation > is called with invokeinterface - so, e.g. doing > `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? Yes. The caller would be java.base

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2]

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2]

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8259021: SharedSecrets should avoid double racy reads from non-volatile fields [v2]

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung wrote: >> @wangweij Moving build tools is a related, but separate, question, which is >> addressed by https://bugs.openjdk.java.net/browse/JDK-8241463. >> >> I send out a review earlier this year (see >> https://m

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie wrote: >> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into >> java.base as well? >> >> Update: I see all subdirs in tools are still there. > > @wangweij Moving build tools is a related, but separate, question, which is >

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons 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 > > I have reviewed all lines in the patch file with or

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: 8253208: Move CDS related code to a separate class [v3]

On Mon, 21 Sep 2020 22:24:15 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a >> separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional >

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a >> separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional >

Re: Fix for Javadoc errors in java.base

Looks fine. Thanks Mandy On 8/18/20 10:02 AM, Julia Boes wrote: Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 23:55:41.953638446 +0530 +++

Re: RFR: 8191138: Remove deprecated java.security.acl APIs

On 7/25/19 9:15 AM, Sean Mullan wrote: Please review this change to remove the deprecated java.security.acl APIs. These APIs have long had a warning in the javadocs (since at least JDK 1.3.1 and possibly earlier) indicating that they were superseded by other APIs. They were initially

Re: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

in which I had doubt about using default policy. I kept them on problem list. Other tests, as I understand, manipulate permissions for test classes. They don't extend system classes so default policy should not affect test class permissions. Thanks, Vladimir On 6/19/19 11:23 PM, Mandy Chung

Re: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

could also be fixed in these tests by inspecting the CodeSource of the ProtectionDomain. Or better yet, they should just use the jtreg java.security.policy option and a policy file and avoid the need to create a Policy implementation. Thanks, Sean On 6/20/19 11:04 AM, Mandy Chung wrote: The Polic

Re: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

, If this were java.base, we would use doPrivilege to ignore the policy and place specific limits. Encumbering the default policy with conditions needed by a trusted subsystem seems like distributing what should be a local implementation issue. $.02, Roger On 6/20/19 2:23 AM, Mandy Chung wrote: Hi

Re: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

Hi Vladimir, Indeed these are test issues that the tests will need to grant permissions to jdk.internal.vm.compiler as the default policy grants. Thanks for going extra miles to fix the tests. My suggestion may be a bit general.  What I intend to say the custom security policy should extend

Re: CSR Review Request, JDK-8218932 Remove the internal package com.sun.net.ssl

On 2/13/19 1:51 PM, Xuelei Fan wrote: Hi, Could I get the CSR reviewed:    https://bugs.openjdk.java.net/browse/JDK-8218932 The internal package com.sun.net.ssl had been deprecated since JDK 1.4, and was not exported in the java.base module since JDK 9.  Application cannot use them

Re: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

On 1/14/19 9:39 AM, Vladimir Kozlov wrote: Thank you, Alan On 1/14/19 2:27 AM, Alan Bateman wrote: On 13/01/2019 02:46, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8216151 Have to update default.policy after changes in

Re: 12 RFR(M) 8214583: AccessController.getContext may return wrong value after JDK-8212605

This looks okay to me. Mandy On 12/14/18 4:59 PM, dean.l...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8214583 http://cr.openjdk.java.net/~dlong/8214583/webrev This change includes two new regression test that demonstrate the problem, and a fix that allows the tests to pass.

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Hi Dean, I reviewed webrev.4 version.  It looks good.  Happy to see moving the doPrivileged support to Java and the performance improvement. On 10/31/18 3:23 PM, dean.l...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8212605 http://cr.openjdk.java.net/~dlong/8212605/webrev.1

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 2:34 PM, dean.l...@oracle.com wrote: @Hidden is internal and no CSR is needed. FYI.  JDK-8212620 is the RFE to consider providing a standard mechanism to hide frames from stack trace. OK, I already filed JDK-8213234 but I think I should just close it as a duplicate of

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 1:18 AM, Vladimir Ivanov wrote: I think it's a good idea, but I believe it would require a CSR request. Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? Sure. Most of the annotations in jdk.internal.vm.annotation were originally located in

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On 10/2/18 10:14 AM, Sean Mullan wrote: On 10/2/18 1:05 PM, Mandy Chung wrote: I'm not a fan of using double == which is not obvious to catch the typo.  I think the `==` syntax may not be commonly known either (I suspect it's seldom for a user to override java.security.policy rather than

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On 10/2/18 8:34 AM, Sean Mullan wrote: Hello, Thanks for all the comments so far, and the interesting discussions about the future of the SecurityManager. We will definitely return to those discussions in the near future, but for now I have a second webrev ready for review for this

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On 9/13/18 4:50 PM, Stuart Marks wrote: Hi Sean, Looks sensible to me. On 9/13/18 1:02 PM, Sean Mullan wrote: 2. A new JDK-specific system property to disallow the setting of the security manager at run-time: jdk.allowSecurityManager If set to false, it allows the run-time to optimize the

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On 9/13/18 1:02 PM, Sean Mullan wrote: This is a SecurityManager related change which warrants some additional details for its motivation. The current System.setSecurityManager() API allows a SecurityManager to be set at run-time. However, because of this mutability, it incurs a

Re: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped

On 9/13/18 2:43 PM, Sergey Bylokhov wrote: Hello. Please review fix for jdk12. Bug: https://bugs.openjdk.java.net/browse/JDK-8210692 Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8210693 Thus change looks okay to me.  This class is

Re: RFR: JDK-8210274: Source Launcher should work with a security manager

On 9/11/18 12:34 PM, Alan Bateman wrote: What are the implications for uses of javax.tools and com.sun.tools.javac.Main in code running with a security manager? Maybe that is a separate project but I would have expected to see privileged blocks in places that need permissions. The intent

Re: RFR (JDK 12): 6899533: SecureClassLoader and URLClassLoader have unnecessary check for createClassLoader permission

On 9/6/18 12:29 PM, Sean Mullan wrote: Please review this change to remove code that is no longer necessary now that pre-JDK 1.2 SecurityManager methods are no longer supported [1]. In addition, the initialized flag and associated code has been removed from SecureClassLoader as this was only

Re: RFR: 8202419: Avoid creating Permission constants early

On 4/30/18 8:25 PM, Claes Redestad wrote: Hi, moving a couple of local permission constants to sun.security.util.SecurityConstants ensures we delay and avoid loading permission classes very early during bootstrap. Delaying load is profitable since it's happening early enough (before

Re: [11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs

On 3/27/18 11:15 PM, Sean Mullan wrote: Please remove this change to remove several SecurityManager methods that have been marked for removal since Java SE 9: checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess, and checkMemberAccess. These methods no longer have any

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

This is a very good change and no more mapfile to maintain!! Please do file JBS issues for the component teams to clean up their exports. Mandy On 3/23/18 7:30 AM, Erik Joelsson wrote: I have looked at the build changes and they look good. Will you file followups for each component team to

Re: RFR 8194251: Deadlock between UsageTracker and System.getProperty() when using a malformed security policy

This looks fine to me. Mandy On 2/5/18 11:26 AM, Adam Petcher wrote: Please review the following change: JBS: https://bugs.openjdk.java.net/browse/JDK-8194251 Webrev: http://cr.openjdk.java.net/~apetcher/8194251/webrev.00/ We ran into a problem related to loading locale data when a security

Re: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields

On 11/22/17 6:37 AM, Sean Mullan wrote: Please review this change to remove the pre-JDK 1.2 SecurityManager methods that have been deprecated since JDK 1.2 and marked for removal in JDK 9. These methods are fragile, error-prone and have been obsolete since the SecurityManager was revamped in

Re: StackOverflowError - Java 9 Build 181

FYI.  jdk.javaws is granted with AllPermissions in conf/security/javaws.policy.   Maybe javaws.policy is not augmented to the security policy at runtime? Mandy On 9/20/17 12:45 PM, Sean Mullan wrote: Tom, Try adding the following lines to the lib/security/default.policy file in your JDK

Re: RFR 8186931: jdk.security.jarsigner package is missing package summary

+1 Mandy On 9/5/17 5:16 PM, Weijun Wang wrote: The package info for com.sun.security.jgss in jdk.security.jgss is also missing. The updated change looks like this (I omit the copyright header): src/jdk.jartool/share/classes/jdk/security/jarsigner/package-info.java: +/** + * This package

Re: RFR 8184744 : Replace finalizer in crypto classes with Cleaner

Thanks for doing this. It’s good to see JDK finalizes being replaced. It looks good to me. I wonder if there is any existing security utility class that may be a good place for this zero-ing byte array method to share. Sean and other may have opinion. Mandy > On Aug 3, 2017, at 1:01 PM,

Re: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions

> On Aug 2, 2017, at 4:21 PM, Jonathan Gibbons > wrote: > > (I'm not sure if there is a better list for this request, but the request is > so simple, I'm hoping it will be sufficient. > > Please review this very simple fix to replace two uses of ... > with

Re: RFR 8182118: Package summary is missing in jdk.security.auth module

Looks fine to me. Mandy > On Jun 19, 2017, at 6:17 AM, Weijun Wang wrote: > > Updated at http://cr.openjdk.java.net/~weijun/8182118/webrev.02/. > > --Max > > On 06/19/2017 08:23 PM, Sean Mullan wrote: >> On 6/19/17 8:17 AM, Weijun Wang wrote: There is more than

Re: RFR 8182118: Package summary is missing in jdk.security.auth module

> On Jun 18, 2017, at 8:33 PM, Weijun Wang wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8182118/webrev.00/ > > Basically, a description line is added into package-info.java of each of > these packages: > > -

Re: RFR [9]: 8181295: Document that SecurityManager::checkPackageAccess may be called by the VM

> On Jun 16, 2017, at 1:25 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 6/16/17 11:13 AM, Mandy Chung wrote: >>> On Jun 16, 2017, at 8:00 AM, Sean Mullan <sean.mul...@oracle.com> wrote: >>> >>> Please review this clarification to the

Re: RFR [9]: 8181295: Document that SecurityManager::checkPackageAccess may be called by the VM

> On Jun 16, 2017, at 8:00 AM, Sean Mullan wrote: > > Please review this clarification to the SecurityManager::checkPackageAccess > method to note that the method may be called by the Virtual Machine when > loading classes: > >

Re: SecurityManager.checkPackageAccess for qualified exports

> On May 12, 2017, at 8:01 AM, Sean Mullan wrote: > > On 5/12/17 9:14 AM, Langer, Christoph wrote: >> >> I think the package access check walking down the whole stack is fine and >> should be done here, not just the module access check. One thing to mention is that

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

> On May 11, 2017, at 3:25 PM, Brent Christian > wrote: > > Hi, > > I have one more update, with a couple of suggested changes to simplify the > execute() calls: > > * execute() takes a vararg, so explicit String[] creation can be omitted > (mostly). > > * args

Re: RFR: [Updated] Update tables in java.base to be HTML5-friendly.

> On May 5, 2017, at 3:52 PM, Jonathan Gibbons > wrote: > > This is an updated review for the changes to improve tables in java.base. > : > Webrevs: > > langtools (the stylesheet): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ > > jdk

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

> On May 9, 2017, at 4:23 PM, Brent Christian > > I've removed the test case for automatic modules, and added a @run action for > each policy file + system classloader configuration. I also removed the code > to compile test sources, using @build instead. > > I

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

> On May 1, 2017, at 12:47 PM, Brent Christian > wrote: > > >> One refactor you can consider by separating >> them in several @run actions. The timeout will apply to each action >> but that does not help shorten the test execution time. > > I had the same

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

Looks like this test execs a new VM for 66 times to exhaust the combination of with and without security manager, with a valid or malformed policy, client & custom loader in unnamed, named, automatic module. I think we could take out the automatic module case as named module would verify it.

Re: RFR: 8179370: Replace use of , and tags in java.base

> On Apr 26, 2017, at 6:49 PM, Jonathan Gibbons > wrote: > > Updated webrev to address Joe's suggestion to try harder to use {@code} as a > substitute for . > > http://cr.openjdk.java.net/~jjg/8179370/webrev.01 Looks good. Mandy

Re: RFR: 8179370: Replace use of , and tags in java.base

Looks okay. Mandy > On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons > wrote: > > Please review these mostly simple changes to replace HTML tags which are not > valid in HTML 5 in public doc comments in java.base. > > As with the previous changes, the changes were

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: > > I’ve reworked the webrev as requested to make jdk.vm.compiler a > non-upgradeable platform module, this allowing it to be mentioned in > default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ Looks good.

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 30, 2017, at 1:36 PM, Doug Simon <doug.si...@oracle.com> wrote: > > >> On 30 Jan 2017, at 21:55, Mandy Chung <mandy.ch...@oracle.com> wrote: >> >> >>> On Jan 30, 2017, at 10:38 AM, Doug Simon <doug.si...@oracle.com> wrote: >&

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: > > I’ve extended the webrev with that change - please re-review: > > http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev > +1 > Strangely, there was no existing declaration of jdk.vm.compiler in > Modules.gmk. >

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: > >> >> jdk.vm.compiler is defined by the application class loader and it’s used by >> AOT tool. I wonder why it has to run with security manager. > > Without java.security.AllPermission, the policy for jdk.vm.compiler

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

(dropping jdk9-dev. security-libs is the appropriate list to review security permission) > On Jan 23, 2017, at 1:56 PM, Doug Simon wrote: > > Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a > security manager is present. Since neither of these

Review Request JDK-8172808: Handle sun.security.util.Resources bundle in ResourcesMgr in the same way as AuthResources

Adam, Sean, Can you review this simple fix: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172808/webrev.00/ This change updates ResourcesMgr to handle both Resources and AuthResources consistently. This removes doPrivileged block because it is not really needed. This is covered by an

Re: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization

> On Jan 19, 2017, at 7:28 AM, Adam Petcher wrote: > > My last attempt to solve this problem didn't work because some classes needed > for string formatting were not loaded by init level 3 in some cases. So I had > to backtrack and try a different approach. > > This

Re: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth

> On Jan 23, 2017, at 6:59 AM, Adam Petcher <adam.petc...@oracle.com> wrote: > > Comments below. > > On 1/21/2017 11:02 PM, Mandy Chung wrote: >>> On Jan 21, 2017, at 6:37 PM, Weijun Wang <weijun.w...@oracle.com> >>> <mailto:weijun.w...@oracle.co

Re: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth

> On Jan 21, 2017, at 6:37 PM, Weijun Wang <weijun.w...@oracle.com> wrote: > > > > On 01/22/2017 09:18 AM, Mandy Chung wrote: >> AFAIK, no permission check from RB::getBundle loading this resource bundle. >> The implementation should wrap all security sensiti

Re: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth

> > On 01/22/2017 05:55 AM, Mandy Chung wrote: >> Since AuthResources is the only altBundle, Max suggests to replace >> getString(String, String) with a method for AuthResources bundle >> specifically. It’s an alternative I considered too. Here is the revised >> webre

Re: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth

> On Jan 18, 2017, at 8:10 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ > > sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is > one existing mechanism to ge

Re: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki

> On Jan 20, 2017, at 10:22 AM, Anthony Scarpino > wrote: > > Good catch.. that'll teach me for trusting the graphical tool to rename a > directory when I used 'Rename'. > > Also I found Brad's issue as it was a new changeset that just showed up in > that file.

Re: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki

> On Jan 19, 2017, at 11:39 AM, Anthony Scarpino > wrote: > > Hi, > > I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This > is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. > For those not familiar with

Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth

Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is one existing mechanism to get the localized string from AuthResources and have sun.security.util.AuthResources resource bundle

Re: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default

> On Jan 18, 2017, at 1:23 PM, Sean Mullan wrote: > >> Similar to the feedback I suggest for JDK-8168075. We can move this >> initialization to the holder class and trigger the initialization in >> the SecurityManager constructor. > > For now, I would prefer to leave

Re: RFR: 8037325: Class.getConstructor() performance regression

> On Jan 16, 2017, at 1:59 PM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8037325/webrev.02/ +1 Mandy

Re: RFR: 8037325: Class.getConstructor() performance regression

> On Jan 12, 2017, at 6:48 AM, Claes Redestad wrote: > > Hi, > > please review this fix to various performance regressions observed > as the security model has evolved over the years. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 > Webrev:

Re: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization

> On Jan 13, 2017, at 7:30 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 1/12/17 3:53 PM, Mandy Chung wrote: >> >>> On Jan 11, 2017, at 5:34 AM, Adam Petcher <adam.petc...@oracle.com> >>> wrote: >>> >>> Please review the f

Re: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default

> On Jan 9, 2017, at 11:25 AM, Sean Mullan wrote: > > Please review this JDK 9 change to make the > SecurityManager::checkPackageAccess and checkPackageDefinition > implementations restrict access to the same set of internal JDK packages as > the module system. > >

  1   2   3   4   >