Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]

2024-05-13 Thread Weijun Wang
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

RFR: 8331864: Update Public Suffix List to 1cbd6e7

2024-05-07 Thread Weijun Wang
Update PSL to the latest upstream version. - Commit messages: - the change Changes: https://git.openjdk.org/jdk/pull/19127/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19127=00 Issue: https://bugs.openjdk.org/browse/JDK-8331864 Stats: 568 lines in 5 files changed: 408

Integrated: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs

2024-03-20 Thread Weijun Wang
On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang wrote: > This code change adds an alternative implementation of user-based > authorization `Subject` APIs that doesn't depend on Security Manager APIs. > Depending on if the Security Manager is allowed, the methods store the > cur

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

2024-03-20 Thread Weijun Wang
On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the

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

2024-03-20 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request incr

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

2024-03-19 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request with a

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

2024-03-14 Thread Weijun Wang
On Wed, 13 Mar 2024 19:53:40 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> revert changes to MBeanServerFileAccessController.java > > test/j

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

2024-03-05 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request incremen

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

2024-03-05 Thread Weijun Wang
On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls wrote: >> Do you know where the subject is set? If it's set by a `doAs` call then it >> will co-operate with `current()` no matter if SM is allowed. I tried to >> search in the whole module and cannot find a `doAs` call. If it is also >> through

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

2024-03-05 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request with a

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

2024-03-05 Thread Weijun Wang
On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls wrote: >> I think we need @kevinjwalls or @dfuch to help advise on this. > > 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. >

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

2024-03-04 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request incre

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

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > src/java.base/share/classes/ja

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

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > test/jdk/javax/security/auth/Subj

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

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > test/jdk/javax/management/monitor/

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

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > src/java.management/share/class

Integrated: 8325506: Ensure randomness is only read from provided SecureRandom object

2024-02-26 Thread Weijun Wang
On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang wrote: > Many crypto service classes require a `SecureRandom` object at > initialization. This test goes through each of them and calculates (generate, > encrypt, sign,...) twice with the same `SecureRandom` object and ensures the

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v3]

2024-02-17 Thread Weijun Wang
On Sat, 17 Feb 2024 01:01:49 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> assertNotEqualsByteArray > > test/lib/jdk/test/lib/Asserts.java line 285: > >&g

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v4]

2024-02-17 Thread Weijun Wang
> Many crypto service classes require a `SecureRandom` object at > initialization. This test goes through each of them and calculates (generate, > encrypt, sign,...) twice with the same `SecureRandom` object and ensures the > output is the same. Weijun Wang has updated the

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v3]

2024-02-13 Thread Weijun Wang
> Many crypto service classes require a `SecureRandom` object at > initialization. This test goes through each of them and calculates (generate, > encrypt, sign,...) twice with the same `SecureRandom` object and ensures the > output is the same. Weijun Wang has updated the

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v2]

2024-02-08 Thread Weijun Wang
> Many crypto service classes require a `SecureRandom` object at > initialization. This test goes through each of them and calculates (generate, > encrypt, sign,...) twice with the same `SecureRandom` object and ensures the > output is the same. Weijun Wang has updated the

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object

2024-02-08 Thread Weijun Wang
On Thu, 8 Feb 2024 20:53:03 GMT, Kevin Driver wrote: >> Many crypto service classes require a `SecureRandom` object at >> initialization. This test goes through each of them and calculates >> (generate, encrypt, sign,...) twice with the same `SecureRandom` object and >> ensures the output is

RFR: 8325506: Ensure randomness is only read from provided SecureRandom object

2024-02-08 Thread Weijun Wang
Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same. - Commit messages: - initial change

Re: RFR: JDK-8325189: Enable this-escape javac warning in java.base

2024-02-07 Thread Weijun Wang
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the > base module was not updated to be able to compile with this warning enabled. > This PR makes the necessary changes to allow the base module to build with > the

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

2024-01-30 Thread Weijun Wang
On Tue, 30 Jan 2024 16:41:28 GMT, Weijun Wang wrote: >> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java >> line 307: >> >>> 305: AccessController.doPrivileged(new PrivilegedAction<>() { >>&g

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

2024-01-30 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull reque

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

2024-01-30 Thread Weijun Wang
On Tue, 30 Jan 2024 16:45:34 GMT, Weijun Wang wrote: >> OK - things seem to be a bit convoluted here and some pieces might be >> missing. I suspect that what needs to be done is more complicated: >> >> `RMIConnectionImpl` sets up an ACC and calls do

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

2024-01-30 Thread Weijun Wang
e current `AccessControlContext`, then instead of storing the > previous `AccessControlContext` object and passing it into `getSubject` to > get the "previous" subject, the application should store the `current()` > return value directly. Weijun Wang has updated the pull request incremen

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

2024-01-30 Thread Weijun Wang
On Tue, 30 Jan 2024 13:56:53 GMT, Daniel Fuchs wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the >> current subject

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

2024-01-30 Thread Weijun Wang
On Tue, 30 Jan 2024 14:19:02 GMT, Daniel Fuchs wrote: >> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java >> line 349: >> >>> 347: @SuppressWarnings("removal") >>> 348: private Subject getSubject() { >>> 349: return Subject.current(); >>

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

2024-01-26 Thread Weijun Wang
This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for

RFR: 8320208: Update Public Suffix List to b5bf572

2023-11-16 Thread Weijun Wang
Update `public_suffix_list.dat` to the latest. - Commit messages: - initial change Changes: https://git.openjdk.org/jdk/pull/16692/files Webrev: https://webrevs.openjdk.org/?repo=jdk=16692=00 Issue: https://bugs.openjdk.org/browse/JDK-8320208 Stats: 3002 lines in 4 files

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v5]

2023-06-16 Thread Weijun Wang
On Fri, 16 Jun 2023 12:14:49 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional > commit since the last revision: > > Pass

Re: RFR: JDK-8308398 Move SunEC crypto provider into java.base

2023-06-16 Thread Weijun Wang
On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino wrote: > Hi, > > I need a code review for moving the contents of the jdk.crypto.ec module into > java.base. This moves the SunEC JCE Provider (Elliptic Curve) into > java.base. EC has always been separate from the base module/pkg because

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v3]

2023-06-14 Thread Weijun Wang
On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v3]

2023-06-14 Thread Weijun Wang
On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v3]

2023-06-14 Thread Weijun Wang
On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]

2023-06-13 Thread Weijun Wang
On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the >> previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which >> displays the localized changes next

Re: RFR: 8281658: Add a security category to the java -XshowSettings option

2023-06-10 Thread Weijun Wang
On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information > about JDK security configuration src/java.base/share/classes/sun/launcher/LauncherHelper.java line 349: > 347: // split lines longer than 60

Re: RFR: 8308286 Fix clang warnings in linux code [v3]

2023-06-06 Thread Weijun Wang
On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov wrote: >> I didn't ask to revert the change. It's >> `s/TARGET_OS_MAC/defined(__APPLE__)/`. > > This is rarely used in the code and is not the essence of the current changes. > If you introduce such changes, then throughout the code. > Moreover,

Re: RFR: 8308286 Fix clang warnings in linux code [v3]

2023-06-01 Thread Weijun Wang
On Thu, 1 Jun 2023 15:02:16 GMT, Artem Semenov wrote: >> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47: >> >>> 45: >>> 46: // Condition was copied from >>> 47: // >>> Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h

Re: RFR: 8308286 Fix clang warnings in linux code [v3]

2023-05-31 Thread Weijun Wang
On Wed, 31 May 2023 13:37:06 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter >> various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional > commit

RFR: 8305972: Update XML Security for Java to 3.0.2

2023-05-05 Thread Weijun Wang
Update XML Security for Java to 3.0.2. Some change to tests: 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. - Commit messages: - the change Changes:

RFR: 8302182: Update Public Suffix List to 88467c9

2023-04-25 Thread Weijun Wang
Update PSL for JDK 21. - Commit messages: - the upgrade Changes: https://git.openjdk.org/jdk/pull/13662/files Webrev: https://webrevs.openjdk.org/?repo=jdk=13662=00 Issue: https://bugs.openjdk.org/browse/JDK-8302182 Stats: 1479 lines in 5 files changed: 647 ins; 697 del; 135

RFR: 8305846: Support compilation in Proc test utility

2023-04-11 Thread Weijun Wang
Enhance the `Proc` utility to support compilation. - Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/13425/files Webrev: https://webrevs.openjdk.org/?repo=jdk=13425=00 Issue: https://bugs.openjdk.org/browse/JDK-8305846 Stats: 139 lines in 4 files changed:

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4]

2023-03-17 Thread Weijun Wang
On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Adjust CF test to read in with UTF-8 to fix failing test > > make/jdk/src/classes

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v4]

2023-03-17 Thread Weijun Wang
On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in

Re: RFR: 8300259: Add test coverage for processing of pending block files in signed JARs [v2]

2023-02-06 Thread Weijun Wang
On Tue, 17 Jan 2023 18:54:13 GMT, Eirik Bjorsnos wrote: >> This PR adds test coverage for pending block files in signed JAR files >> >> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes >> before the corresponding signature file [SF] in the JAR. >> >>

Re: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories [v15]

2023-01-27 Thread Weijun Wang
On Tue, 24 Jan 2023 12:31:30 GMT, Eirik Bjorsnos wrote: >> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that >> files reside in META-INF directly, and not in a subdirectory of META-INF. >> >> The mentioned call sites needs updates to check and ignore such files. >> >> A

Re: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]

2023-01-25 Thread Weijun Wang
On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace >> tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last

Re: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]

2023-01-25 Thread Weijun Wang
On Wed, 25 Jan 2023 17:56:15 GMT, Damon Nguyen wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties >> line 113: >> >>> 111: >>> doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 >>>

Re: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]

2023-01-25 Thread Weijun Wang
On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace >> tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last

Re: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]

2023-01-25 Thread Weijun Wang
On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace >> tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories [v15]

2023-01-24 Thread Weijun Wang
On Tue, 24 Jan 2023 12:31:30 GMT, Eirik Bjorsnos wrote: >> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that >> files reside in META-INF directly, and not in a subdirectory of META-INF. >> >> The mentioned call sites needs updates to check and ignore such files. >> >> A

Re: RFR: 8300259: Add test coverage for processing of pending block files in signed JARs

2023-01-17 Thread Weijun Wang
On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos wrote: > This PR adds test coverage for pending block files in signed JAR files > > A signed JAR has pending block files if the block file [RSA, DSA, EC] comes > before the corresponding signature file [SF] in the JAR. > >

Re: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories [v6]

2023-01-17 Thread Weijun Wang
On Sat, 14 Jan 2023 12:02:11 GMT, Eirik Bjorsnos wrote: >> src/java.base/share/classes/java/util/zip/ZipFile.java line 1748: >> >>> 1746: .isBlockOrSF(new String(name, off, len, >>> UTF_8.INSTANCE) >>> 1747: .toUpperCase(Locale.ENGLISH))); >>> 1748: >> >>

Re: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories [v6]

2023-01-17 Thread Weijun Wang
On Sat, 14 Jan 2023 12:14:54 GMT, Eirik Bjorsnos wrote: >> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 980: >> >>> 978: * Returns true iff the entry resides directly in the META-INF/ >>> directory >>> 979: */ >>> 980: private boolean

Re: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories

2023-01-13 Thread Weijun Wang
On Thu, 12 Jan 2023 18:44:26 GMT, Eirik Bjorsnos wrote: > Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that > files reside in META-INF directly, and not in a subdirectory of META-INF. > > The mentioned call sites needs updates to check and ignore such files. > > A new

Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4]

2022-12-16 Thread Weijun Wang
On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen wrote: >> Yes, you can replace all "存在安全风险" (that is not after ""被视为") to "被视为存在安全风险". >> >> There are also similar usages in >> `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. > > Hi @wangweij , I believe I fixed the

Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4]

2022-12-16 Thread Weijun Wang
On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java >> line 75: >> >>> 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, >>> //-genseckey >>> 74: {"key.algorithm.weak", "%1$s

Re: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4]

2022-12-15 Thread Weijun Wang
On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last revision: > > Revert double quote as well

Re: RFR: 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code

2022-12-02 Thread Weijun Wang
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote: > According to [the > specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) > trailing whitespaces in the values of properties files are (somewhat > surprisingly)

Re: RFR: 8295803: Console should be usable in jshell and other environments [v2]

2022-12-02 Thread Weijun Wang
On Fri, 2 Dec 2022 08:18:35 GMT, Alan Bateman wrote: >> If the console cannot be used anyway inside jshell, then this is good enough. > > Naoto has confirmed that the password prompt from keytool does not echo, good! > > The intention is that Console be usable in jshell so I think the issue is

Re: RFR: 8295803: Console should be usable in jshell and other environments [v2]

2022-12-01 Thread Weijun Wang
On Thu, 1 Dec 2022 19:30:29 GMT, Naoto Sato wrote: >> What's the expected behavior? > > I confirmed that the standalone `keytool` did not echo the input, which > should be OK for this IMO. If the console cannot be used anyway inside jshell, then this is good enough. - PR:

Re: RFR: 8295803: Console should be usable in jshell and other environments [v2]

2022-12-01 Thread Weijun Wang
On Thu, 1 Dec 2022 16:08:39 GMT, Weijun Wang wrote: >> Sure. Trying out now... > > I can still see the password on screen. Here `in` is a > `jdk.jshell.execution.Util` so the updated check on line 58 above failed. > > $ jshell -C--add-exports -Cjava.base/sun.security.tool

Re: RFR: 8295803: Console should be usable in jshell and other environments [v2]

2022-12-01 Thread Weijun Wang
On Thu, 1 Dec 2022 15:49:30 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/Password.java line 63: >> >>> 61: // readPassword returns "" if you just press ENTER with >>> the built-in Console, >>> 62:

Re: RFR: 8295803: Console should be usable in jshell and other environments [v2]

2022-12-01 Thread Weijun Wang
On Thu, 1 Dec 2022 15:16:29 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Adds a test >> - Removed JavaIOAccess.charset() which is no longer needed > >

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]

2022-11-21 Thread Weijun Wang
On Tue, 22 Nov 2022 00:45:00 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional > commit since the last revision: > > Modify as reviews. Everything looks fine now.

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v6]

2022-11-21 Thread Weijun Wang
On Mon, 21 Nov 2022 00:29:34 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional > commit since the last revision: > > Modify as review and update copyright. Looks almost

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v5]

2022-11-20 Thread Weijun Wang
On Sun, 20 Nov 2022 06:27:32 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional > commit since the last revision: > > Modify as reviews. `codomain`,

Re: RFR: JDK-8296547: Add @spec tags to API

2022-11-10 Thread Weijun Wang
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc > comments, as appropriate, to leverage the recent new javadoc feature to > generate a new page listing the references to all external specifications >

Integrated: 8296167: test/langtools/tools/jdeps/jdkinternals/ShowReplacement.java failing after JDK-8296072

2022-11-01 Thread Weijun Wang
On Tue, 1 Nov 2022 14:18:27 GMT, Weijun Wang wrote: > The argument of `DerEncoder::derEncode` changed. This pull request has now been integrated. Changeset: da0ae512 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/da0ae5128a250bb7a5c6a7484589528db8220ed2 Stats:

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Weijun Wang
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` > to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components > according to the escaping mechanism defined

Re: RFR: 8295729: Add jcheck whitespace checking for properties files [v3]

2022-10-25 Thread Weijun Wang
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same >> whitespace checks as all other source code, so we don't get spurious >> trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to

Re: RFR: 8295729: Add jcheck whitespace checking for properties files [v3]

2022-10-25 Thread Weijun Wang
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same >> whitespace checks as all other source code, so we don't get spurious >> trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to

Re: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to validate i18n compliance [v2]

2022-10-11 Thread Weijun Wang
On Mon, 10 Oct 2022 23:23:00 GMT, Bill Huang wrote: >> The jarsigner and keytool are localized into English, German, Japanese and >> Simplified Chinese. This task is to modify the existing i18n tests to >> validate i18n compliance in these tools. >> >> In addition, this task also contains

Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]

2022-10-01 Thread Weijun Wang
On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote: >> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? > > This is correct. > AccessBridge.h is published with the include/header files of the JDK and > anyone reading it there can't exactly make use of "../" Thanks

Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]

2022-09-30 Thread Weijun Wang
On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> http -> https > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line > 34: > >> 32: * the

Re: RFR: 8215788: Clarify JarInputStream Manifest access [v6]

2022-09-19 Thread Weijun Wang
On Mon, 19 Sep 2022 17:53:51 GMT, Lance Andersen wrote: >>> I can remove, but I am not sure I agree we need to describe main vs >>> attribute here given we are pointing to the Jar spec and if there is any >>> discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess >>> the

Re: RFR: 8215788: Clarify JarInputStream Manifest access [v3]

2022-09-14 Thread Weijun Wang
On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen wrote: >> Please review this PR which updates the JarInputStream class description to >> clarify when the Manifest is accessible via JarInputStream::getManifest and >> JarInputStream::get[Jar]Entry. >> >> It is worth noting that with this

Re: RFR: 8215788: Clarify JarInputStream Manifest access [v2]

2022-09-13 Thread Weijun Wang
On Wed, 14 Sep 2022 01:42:20 GMT, Lance Andersen wrote: >> Please review this PR which updates the JarInputStream class description to >> clarify when the Manifest is accessible via JarInputStream::getManifest and >> JarInputStream::get[Jar]Entry. >> >> It is worth noting that with this

Re: RFR: 8215788: Clarify JarInputStream Manifest access

2022-09-13 Thread Weijun Wang
On Tue, 13 Sep 2022 20:58:04 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36: >> >>> 34: * The {@code JarInputStream} class, which extends {@linkplain >>> ZipInputStream}, >>> 35: * is used to read the contents of a JAR file from an input

Re: RFR: 8215788: Clarify JarInputStream Manifest access

2022-09-13 Thread Weijun Wang
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen wrote: > Please review this PR which updates the JarInputStream class description to > clarify when the Manifest is accessible via JarInputStream::getManifest and > JarInputStream::get[Jar]Entry. > > It is worth noting that with this update,

Re: RFR: 8215788: Clarify JarInputStream Manifest access

2022-09-13 Thread Weijun Wang
On Thu, 1 Sep 2022 11:06:41 GMT, Lance Andersen wrote: >> That's right. But I think we care about the MANIFEST more. It's not that >> important whether META-INF is there. > > True we do care more about the manifest, but was also trying to address the > difference between ZipInputStream which

Re: RFR: 8215788: Clarify JarInputStream Manifest access

2022-09-13 Thread Weijun Wang
On Wed, 31 Aug 2022 18:31:13 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarInputStream.java line 62: >> >>> 60: * is the second jar entry >>> 61: * >>> 62: * >> >> I wonder if it's necessary to duplicate these lines. How about something >> like

Re: RFR: 8215788: Clarify JarInputStream Manifest access

2022-09-13 Thread Weijun Wang
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen wrote: > Please review this PR which updates the JarInputStream class description to > clarify when the Manifest is accessible via JarInputStream::getManifest and > JarInputStream::get[Jar]Entry. > > It is worth noting that with this update,

Re: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code

2022-07-21 Thread Weijun Wang
On Thu, 21 Jul 2022 15:37:40 GMT, Сергей Цыпанов wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. The `X509CertPath.java` change looks fine, but I'm not sure about the other one. It means the whole content from the input stream is read into a single array

Re: RFR: 8289768: Clean up unused code [v2]

2022-07-07 Thread Weijun Wang
On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeliński wrote: >> This patch removes many unused variables and one unused label reported by >> the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list >> of disabled warnings