Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5]

2025-02-28 Thread Kevin Walls
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5]

2025-02-27 Thread Kevin Walls
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5]

2025-02-27 Thread Kevin Walls
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8345799: Update copyright year to 2024 for core-libs in files where it was missed [v2]

2024-12-09 Thread Kevin Walls
On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie wrote: >> Some files have been modified in 2024, but the copyright year has not been >> properly updated. This should be fixed. >> >> I have located these modified files using: >> >> git log --since="Jan 1" --name-only --pretty=format: | sor

Re: RFR: 8345799: Update copyright year to 2024 for core-libs in files where it was missed [v2]

2024-12-09 Thread Kevin Walls
On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie wrote: >> Some files have been modified in 2024, but the copyright year has not been >> properly updated. This should be fixed. >> >> I have located these modified files using: >> >> git log --since="Jan 1" --name-only --pretty=format: | sor

Re: RFR: 8345286: Remove use of SecurityManager API from misc areas [v9]

2024-12-04 Thread Kevin Walls
On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes usages of >> SecurityManager related APIs and some leftover related to SecurityManager >> changes? >> >> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these >>

Re: RFR: 8345286: Remove use of SecurityManager API from misc areas [v9]

2024-12-04 Thread Kevin Walls
On Tue, 3 Dec 2024 09:03:20 GMT, Jaikiran Pai wrote: > Although trivial, there are some changes to files from the serviceability > area. So it would be good if someone from that area could review this too. Yes, looks good. I will update https://github.com/openjdk/jdk/pull/22478 to avoid the c

Re: RFR: 8344056: Use markdown format for man pages

2024-11-13 Thread Kevin Walls
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open > repo, and a content-wise identical copy is stored as markdown (another text > format) in the closed repo. > > Since markdown is preferred to troff in terms o

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11]

2024-11-12 Thread Kevin Walls
On Tue, 12 Nov 2024 14:44:55 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 ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10]

2024-11-12 Thread Kevin Walls
On Tue, 12 Nov 2024 13:01:33 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 ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Kevin Walls
On Fri, 18 Oct 2024 19:03:30 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 ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Kevin Walls
On Fri, 18 Oct 2024 19:03:30 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 ch

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-05 Thread Kevin Walls
On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang wrote: >> Right, this does not depend on the SM. All we need to do is get the >> Subject. >> This method implements the basic monitor (readonly) and control (readwrite) >> access. >> accessMap maps identity String to Access, and the checkAccess() m

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-05 Thread Kevin Walls
On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan wrote: >> I was not exactly sure if we will support this functionality when there is >> no SM. The class name has `AccessControler` and the method names use >> `checkAccess`, but they actually do not always depend on security manager. > > I think we

Re: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2]

2023-04-11 Thread Kevin Walls
On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol >> problems when statically linking the launcher executable with JDK native >> libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional