Re: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

2021-07-26 Thread Sean Mullan
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] > Colleciton.toArray()` call and then manually copy array into another array > with required type. > This PR cleanups such places to more shorter call `T[] > Collection.toArra

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

2021-05-23 Thread Sean Mullan
On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > src/java.base/share/classes/java/lang/SecurityManager.j

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

2021-05-19 Thread Sean Mullan
On Tue, 18 May 2021 21:44:43 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 >> `-Djav

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

2021-05-18 Thread Sean Mullan
On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman wrote: >> It includes both: >> ![Screen Shot 2021-05-18 at 8 41 11 >> AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) > > Thanks for checking, I assumed that was the case so wondering if it

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

2021-05-18 Thread Sean Mullan
On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman 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. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e3

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Sean Mullan
On Fri, 20 Nov 2020 15:50:11 GMT, Alan Bateman wrote: > > Ok, but then how about putting a similar note in the javadoc for the > > RuntimePermission "modifyThreadGroup" target? > > The "modifyThread" and "modifyThreadGroup" permission targets list methods > that have been terminally deprecated

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

2020-11-20 Thread Sean Mullan
On Fri, 20 Nov 2020 14:49:16 GMT, Alan Bateman wrote: > > I think it would be useful in the javadoc of the RuntimePermission targets > > (stopThread, etc) to add a note/link that the corresponding method that the > > permission applies to is terminally deprecated. Something as simple as > > "N

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Sean Mullan
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote: > This change terminally deprecates the following methods defined by > java.lang.ThreadGroup > > - stop > - destroy > - isDestroyed > - setDaemon > - isDaemon > > The stop method has been deprecated since=1.2 because it is inherently

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,…

2020-11-20 Thread Sean Mullan
On Thu, 19 Nov 2020 18:53:09 GMT, Sergey Bylokhov wrote: >> Marked as reviewed by serb (Reviewer). > > The changes in the awt are trivial and look fine. I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method

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

2018-09-14 Thread Sean Mullan
On 9/13/18 7:52 PM, Stuart Marks wrote: I'd guess that security-dev would have reviewers for the change to default.policy. Cc'd. The default.policy file change looks like this is not specifically related to this change because the jdk.desktop module no longer exists. I guess it is ok to inclu

Re: [10] RFR 8193435: Remove pre-1.2 SecurityManager text from java.awt.Toolkit

2017-12-18 Thread Sean Mullan
This looks good to me. The JDK SecurityManager implementation of checkRead and checkConnect have both been changed to call checkPermission since JDK 1.2 so the fallback code is redundant. --Sean On 12/18/17 11:47 AM, Dmitry Markov wrote: Hello, Could you review a fix for jdk10, please?  bu

Re: [10] Review request for 8154405: AccessControlException by URLPermission check

2017-12-13 Thread Sean Mullan
On 12/13/17 2:38 AM, Dmitry Markov wrote: Sean, Could you take a look at http://cr.openjdk.java.net/~dmarkov/8154405/webrev.00/ , please? Looks good. Thanks, Sean

Re: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities

2015-07-14 Thread Sean Mullan
You don't need to add the /secure option to jtreg. That's overriding jtreg's SecurityManager and causing you to have to grant jtreg permissions to read files in the jtreg.security.policy file. Just add the /java.security.policy option -- this will use jtreg's SecurityManager which is sufficient

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

2013-12-11 Thread Sean Mullan
On 12/10/2013 08:51 AM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we change

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

2013-11-26 Thread Sean Mullan
t): Initial comments (20 Sep [3]) - Michael McMahon (net): Initial comments (20 Sept [4]) - Steffan Larsen (svc): APPROVED (20 Sept [5]) - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments (15 Oct [7]) - Sean Mullan (sec): Initial comments (26 Sept [8]) [2]: http://mail.openjdk.j

Re: RFR(L): 8024854: Basic changes and files to build the class library on AIX

2013-09-26 Thread Sean Mullan
On 09/16/2013 12:30 PM, Volker Simonis wrote: src/share/lib/security/java.security-aix - Provide default java.security-aix for AIX. The login.configuration.provider property should be set to: sun.security.provider.ConfigFile See 8016848 for more info. After you make this change, java.se

Re: Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

2012-04-27 Thread Sean Mullan
Looks fine, just a couple of nits. src/macosx/classes/com/apple/concurrent/LibDispatchNative.java, - the closing static brace is not indented the same as the open brace. src/solaris/classes/sun/management/FileSystemImpl.java src/windows/classes/sun/management/FileSystemImpl.java - line-bre

Re: [security-dev 01209]: 6854954: Eliminate static dependency on java.awt.AWTPermission

2009-09-15 Thread Sean Mullan
Looks good to me. Super small nit in SecurityConstants: 120try { indentation is off by one space with rest of code. --Sean Alan Bateman wrote: Sean, Mandy - can you review this? I also need someone from the AWT team. This patch eliminates the static dependency on ja