hg: jdk8/tl/jdk: 8024861: Incomplete token triggers GSS-API NullPointerException

2013-09-27 Thread weijun . wang
Changeset: eb2c81533876 Author:weijun Date: 2013-09-27 15:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb2c81533876 8024861: Incomplete token triggers GSS-API NullPointerException Reviewed-by: mullan ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test

hg: jdk8/tl/jdk: 8026235: keytool NSS test should use 64 bit lib on Solaris

2013-10-10 Thread weijun . wang
Changeset: 74b4d20769fd Author:weijun Date: 2013-10-10 15:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74b4d20769fd 8026235: keytool NSS test should use 64 bit lib on Solaris Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh

hg: jdk8/tl/jdk: 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases

2013-10-15 Thread weijun . wang
Changeset: a70aab9b373e Author:weijun Date: 2013-10-16 14:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a70aab9b373e 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/krb5/InitialToken.ja

hg: jdk8/tl/jdk: 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so

2013-10-17 Thread weijun . wang
Changeset: 37e3dcb798c3 Author:weijun Date: 2013-10-17 20:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37e3dcb798c3 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so Reviewed-by: vinnie ! test/sun/security/to

hg: jdk8/tl/jdk: 7025699: Policy Tool is not accessible by keyboard

2013-10-17 Thread weijun . wang
Changeset: c1616a944d1c Author:weijun Date: 2013-10-18 08:57 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1616a944d1c 7025699: Policy Tool is not accessible by keyboard Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/poli

hg: jdk8/tl/jdk: 8027026: Change keytool -genkeypair to use -keyalg RSA

2013-10-22 Thread weijun . wang
Changeset: d545d67e2f68 Author:weijun Date: 2013-10-23 08:32 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d545d67e2f68 8027026: Change keytool -genkeypair to use -keyalg RSA Reviewed-by: alanb, chegar, mullan ! test/ProblemList.txt ! test/java/util/TimeZone/TimeZoneDatePer

hg: jdk8/tl/jdk: 8026929: remove accelerators from policytool resources

2013-10-24 Thread weijun . wang
Changeset: e9ec0ca5bab1 Author:weijun Date: 2013-10-25 08:38 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9ec0ca5bab1 8026929: remove accelerators from policytool resources Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/

hg: jdk8/tl/jdk: 8027991: InputStream should be closed in sun.security.tools.jarsigner.Main

2013-11-11 Thread weijun . wang
Changeset: 7304b3195212 Author:weijun Date: 2013-11-11 16:54 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7304b3195212 8027991: InputStream should be closed in sun.security.tools.jarsigner.Main Reviewed-by: xuelei ! src/share/classes/sun/security/tools/jarsigner/Main.java

How to manually assign a canonicalized host name?

2013-11-11 Thread Weijun Wang
This is probably not Java-related, but I guess you guys might know the answer. I know adding a line to /etc/hosts could resolve a host name to any IP address. But where can I do the reverse? I am using a tool (kvno from MIT krb5) now and it is trying to perform something on the argument

Re: How to manually assign a canonicalized host name?

2013-11-11 Thread Weijun Wang
rdns = false in [libdefaults] works. ignore_acceptor_hostname seems to be for server side, which allows a server (acceptor) to expose itself as any name even if it only has keys for one name. The /etc/hosts way also works, and I've mapped several names to different 127.0.1.*. At least on Lin

hg: jdk8/tl/jdk: 8028479: runNameEquals still cannot precisely detect if a usable native krb5 is available

2013-11-18 Thread weijun . wang
Changeset: 7b71e53c6a2b Author:weijun Date: 2013-11-19 14:14 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b71e53c6a2b 8028479: runNameEquals still cannot precisely detect if a usable native krb5 is available Reviewed-by: xuelei ! test/sun/security/krb5/runNameEquals.sh

hg: jdk8/tl/jdk: 8029181: ts.sh generates invalid file after JDK-8027026

2013-11-26 Thread weijun . wang
Changeset: 1738dfb0c52a Author:weijun Date: 2013-11-27 09:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1738dfb0c52a 8029181: ts.sh generates invalid file after JDK-8027026 Reviewed-by: vinnie, mullan ! test/sun/security/tools/jarsigner/TimestampCheck.java

Re: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname

2013-12-02 Thread Weijun Wang
Hi Michael 492 boolean implies(Authority other) { 493 return userinfo.equals(other.userinfo) && 494impliesHostrange(other) && impliesPortrange(other); 495 } This means http://example.com does not imply http://some...@example.com. Is this inten

Re: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname

2013-12-02 Thread Weijun Wang
Is it possible to just ignore the userinfo part? I wonder if people will complain why "user:pass" is not the same as "user". --Max On 12/2/13, 18:00, Michael McMahon wrote: This means http://example.com does not imply http://some...@example.com. Is this intended? http://cr.openjdk.java.net/

Re: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname

2013-12-02 Thread Weijun Wang
:41, Weijun Wang wrote: Is it possible to just ignore the userinfo part? I wonder if people will complain why "user:pass" is not the same as "user". --Max On 12/2/13, 18:00, Michael McMahon wrote: This means http://example.com does not imply http://some...@example.com. Is th

hg: jdk8/tl/jdk: 8028351: JWS doesn't get authenticated when using kerberos auth proxy

2013-12-03 Thread weijun . wang
Changeset: e1bc55ddf1ad Author:weijun Date: 2013-12-04 09:14 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1bc55ddf1ad 8028351: JWS doesn't get authenticated when using kerberos auth proxy Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule

hg: jdk8/tl/jdk: 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed

2014-01-25 Thread weijun . wang
Changeset: 4d891c8db5c1 Author:weijun Date: 2014-01-21 12:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d891c8db5c1 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java + test/s

Re: RFR 8064924: Update java.net.URL to work with modules

2015-02-04 Thread Weijun Wang
It should be checked, otherwise a non-initialized parent object comes into being. On 2/4/2015 22:38, Peter Levart wrote: Just a thought,... Is JVM bytecode verifier checking that a constructor chains to super constructor? If yes, we are ok. If not, specially crafted bytecode could skip securit

RFR 8072615: test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java wrong on Windows

2015-02-05 Thread Weijun Wang
Hi All A test helper tries to parse the "test.src.path" system property using delimiter ":". This is not correct on Windows. The fix is simply diff --git a/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java b/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java --- a/test/lib/

Re: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection

2015-05-20 Thread Weijun Wang
Hi Rob The src change is good. As for the test, this line will return the Subject you want Context.fromUserPass(WEB_USER, WEB_PASS, false).s() Thanks Max On 5/20/2015 8:24 PM, Rob McKenna wrote: Hi folks, Looking for a review of this webrev: http://cr.openjdk.java.net/~robm/8077155/web

Re: TLS ALPN Proposal v5

2015-09-25 Thread Weijun Wang
New to ALPN and this thread, just my $0.02. On 09/25/2015 05:47 PM, Xuelei Fan wrote: Here is the question to answer, which preference should be respected firstly between cipher suite and application protocol? No concrete answer, but I think it's always better to "first respect what the user

Re: RFR 8151788: NullPointerException from ntlm.Client.type3

2016-07-12 Thread Weijun Wang
On 7/12/2016 22:34, Pavel Rappo wrote: What's the difference between no security buffer and an empty one (from the com.sun.security.ntlm.Client#type3's perspective)? I quickly browse through the NTLM protocol and yes they look like the same in each case. (Except for one which I am not sure,

Re: Ping~ Re: RFR 8181080/10, Refactor several sun/net shell tests to plain java tests

2017-06-06 Thread Weijun Wang
On 06/06/2017 01:43 PM, Felix Yang wrote: Missed "Add back read access" before trying to delete it? Based on my test results (local and JPRT), it deleted w/o any exceptions. This was originally added by Max in https://bugs.openjdk.java.net/browse/JDK-7078355. TO Max, could you comment if suc

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-24 Thread Weijun Wang
> On May 25, 2018, at 11:58 AM, Ivan Gerasimov > wrote: > >> I also wonder whether a smart compiler might not flag code where the errors >> do infact have the same value: >> >> if (errno == 11 || errno == 11) ... >> > At least gcc -O completely removes the second redundant test, so no > ob

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-24 Thread Weijun Wang
https://stackoverflow.com/questions/27509061/macro-to-avoid-duplicate-case-value Someone has already used them in a switch expression... > On May 25, 2018, at 12:45 PM, David Holmes wrote: > >>> I also wonder whether a smart compiler might not flag code where the errors >>> do infact have the

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

2018-10-14 Thread Weijun Wang
Hi John I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined? If so, then we have a chance to ASCII-fy the testkeys file and directly in

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

2018-10-15 Thread Weijun Wang
consequence they can't > compile against library classes which are on the classpath. > This is the unfortunate reason for the presence of a > SimpleSSLContext clone in there. > > best regards, > > -- daniel > > On 15/10/2018 03:53, Weijun Wang wrote:

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

2018-10-15 Thread Weijun Wang
> On Oct 15, 2018, at 6:01 PM, Chris Hegarty wrote: > > On 15/10/18 10:53, Weijun Wang wrote: >> This is bad. > > In the absence of better test library, module-patching, > and jtreg support, this is what we end up with. It's > not too bad. I meant this

A parallel HttpClient sendAync question

2018-11-12 Thread Weijun Wang
I'm scanning a file and downloading links inside: lines.flapMap(x -> Stream.ofNullable(findURIFrom(x))) .map(l -> download(c, l)) .forEach(f -> f.join()); CompletableFuture> download(HttpClient c, URI link) { return c.sendAsync(HttpRequest.newBuilder(link).build(), HttpR

Re: A parallel HttpClient sendAsync question

2018-11-12 Thread Weijun Wang
> On Nov 13, 2018, at 11:09 AM, Pavel Rappo wrote: > >> On 13 Nov 2018, at 02:35, Weijun Wang wrote: >> >> I'm scanning a file and downloading links inside: >> >> lines.flapMap(x -> Stream.ofNullable(findURIFrom(x))) >>.m

Re: A parallel HttpClient sendAync question

2018-11-12 Thread Weijun Wang
> On Nov 13, 2018, at 11:41 AM, Chris Yin wrote: > >> >> On 13 Nov 2018, at 10:35 AM, Weijun Wang wrote: >> >> I'm scanning a file and downloading links inside: >> >> lines.flapMap(x -> Stream.ofNullable(findURIFrom(x))) >>

Re: A parallel HttpClient sendAync question

2018-11-13 Thread Weijun Wang
> > That's what I would use too. Though Chris Y.'s suggestion below > should also work: > > On 13/11/2018 03:41, Chris Yin wrote: > lines.flapMap(x -> > Stream.ofNullable(findURIFrom(x))) >>.map(l -> download(c, l)) >>.collect(Collectors.toList()) >>.forEach(f -> f.join()); > > sinc

Re: RFR 8220598: Malformed copyright year range in a few files in java.base

2019-03-13 Thread Weijun Wang
+1 (on the security class). Thanks, Max > On Mar 14, 2019, at 1:10 AM, Lance Andersen wrote: > > +1 >> On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote: >> >> Trivially, there should be a comma after the year. Just add it. >> >> >> $ hg diff src/java.base/share/classes/jdk/ src/java.base/sh

How to deal with multi-step WWW-Authenticate with the new HttpClient

2019-04-16 Thread Weijun Wang
Hi, All, I am trying the new HttpClient to deal with a multi-step Negotiate authentication with Windows IIS, and here is my code. HttpClient hc = HttpClient.newBuilder().build(); var req = HttpRequest.newBuilder().uri(new URI(args[0])); while (true) { var resp = hc.send(req.build(), HttpResp

Re: How to deal with multi-step WWW-Authenticate with the new HttpClient

2019-04-17 Thread Weijun Wang
Sorry, after adding "-Djdk.httpclient.HttpClient.log=headers,errors,channel" I found out it's my problem. > On Apr 17, 2019, at 11:09 AM, Weijun Wang wrote: > > Hi, All, > > I am trying the new HttpClient to deal with a multi-step Negotiate > authentication

Re: Is SPNEGO supposed to work out of the box on domain joined Windows client

2019-12-11 Thread Weijun Wang
> On Dec 12, 2019, at 8:23 AM, Daniel Fuchs wrote: > > Hi, > > By default transparent authentication is disabled on windows. > You may have to specify a non-default value for the > jdk.http.ntlm.transparentAuth property [1], or configure > an Authenticator [2] that has the appropriate credent

Re: Need sponsor to fix Javadoc warnings

2020-04-13 Thread Weijun Wang
The additional patch looks fine to me. Thanks, Max > On Apr 12, 2020, at 3:23 AM, Vipin Sharma wrote: > > Hi Pavel, > >> On Apr 9, 2020, at 2:45 AM, Pavel Rappo wrote: >> >> If your new patch addresses a similar type of problem, please send it in >> reply to this email, >> so that I could m

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

2020-05-04 Thread Weijun Wang
There are several security-related files (name.contains("security")) and they all look fine. --Max > On May 4, 2020, at 1:12 PM, Mikael Vidstedt > wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: >

Re: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8]

2021-02-08 Thread Weijun Wang
On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8080272: Refactor I/O stream copying

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

2021-05-17 Thread Weijun Wang
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 `-Djava.security.manager=allow` when launched. This PR covers such changes for

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

2021-05-17 Thread Weijun Wang
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/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Depr

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

2021-05-17 Thread Weijun Wang
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. > https://github.c

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

2021-05-18 Thread Weijun Wang
On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs 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 >> `-Dja

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

2021-05-18 Thread Weijun Wang
On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman wrote: > The changes look okay but a bit inconsistent on where -Djava...=allow is > inserted for tests that already set other system properties or other > parameters. Not a correctness issue, just looks odd in several places, e.g. > > test/jdk/jav

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

2021-05-18 Thread Weijun Wang
On Tue, 18 May 2021 17:36:55 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: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

2021-05-18 Thread Weijun Wang
On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/AccessController.java line 877: >> >>> 875: @CallerSensitive >>> 876: public static T doPrivileged(PrivilegedExcept

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

2021-05-18 Thread Weijun Wang
system > property is now "disallow", most of the tests calling > `System.setSecurityManager()` need to launched with > `-Djava.security.manager=allow`. This is covered in a different PR at > https://github.com/openjdk/jdk/pull/4071. Weijun Wang has u

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

2021-05-18 Thread Weijun Wang
; permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => > permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated t

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

2021-05-19 Thread Weijun Wang
On Tue, 18 May 2021 21:21:45 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: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-19 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fixi

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

2021-05-19 Thread Weijun Wang
On Wed, 19 May 2021 18:26:25 GMT, Phil Race 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.desktop/share/c

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

2021-05-19 Thread Weijun Wang
On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Container.java line 97: >> >>> 95: * @since 1.0 >>> 96: */ >>> 97: @SuppressWarnings("removal") >> >> Same issue as with Component.

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

2021-05-19 Thread Weijun Wang
On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang wrote: >> Similar as the one above, it's because of >> >> static { >> // Don't lazy-read because every app uses invalidate() >> isJavaAwtSmartInvalidate = AccessController.doPrivileged(

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

2021-05-19 Thread Weijun Wang
On Wed, 19 May 2021 19:31:24 GMT, Phil Race wrote: >> This happens when a deprecated method is called inside a static block. The >> annotation can only be added to a declaration and here it must be the whole >> class. The call in this file is >> >> s = java.security.AccessController.do

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

2021-05-19 Thread Weijun Wang
On Wed, 19 May 2021 22:04:57 GMT, Phil Race wrote: >> Correct, there are ways to modify the code to make it more >> annotation-friendly. We thought about whether it's good to do it before >> adding the annotations or after it. Our decision now is to do it after >> because it will be more easy

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

2021-05-19 Thread Weijun Wang
On Wed, 19 May 2021 23:50:04 GMT, Phil Race wrote: >> I just made it P3 (P4 was the default value), and I will target it to 17 >> once JEP 411 is targeted 17. But I think it's probably not a good idea to >> include it inside *this* PR. There are some middle ground where it's >> debatable if a

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

2021-05-19 Thread Weijun Wang
On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang wrote: >> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and >> definitely if it misses the fork, >> and I don't get why you can't do it here. And if it isn't done the JEP isn't >>

RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K

2021-05-20 Thread Weijun Wang
The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
cated method call to a new local > variable and add annotation on the declaration, and then assign that value to > the original l-value. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. Weijun Wang has updated the pull requ

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

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 18:26:48 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> adjust order of VM options > > test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile

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

2021-05-21 Thread Weijun Wang
; permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => > permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpC

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-21 Thread Weijun Wang
cated method call to a new local > variable and add annotation on the declaration, and then assign that value to > the original l-value. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. Weijun Wang has updated the pull requ

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

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 20:43:05 GMT, Phil Race wrote: > I haven't seen any response to this comment I made a couple of days ago and I > suspect it got missed > > > Weijun Wang has updated the pull request incrementally with one additional > > commit since the las

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

2021-05-24 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revi

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

2021-05-24 Thread Weijun Wang
On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 104: >> >>> 102: * method will throw an {@code UnsupportedOperationException}). If the >>> 103: * {@systemProperty java.security.manager} system property is set to >>> the >

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

2021-05-24 Thread Weijun Wang
; permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => > permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pu

Integrated: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

2021-05-24 Thread Weijun Wang
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.setSecurityM

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-24 Thread Weijun Wang
On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs wrote: > Thanks for taking in my suggestions for FtpClient. I have also reviewed the > changes to java.util.logging and JMX. I wish there was a way to handle > doPrivileged returning void more nicely. Maybe component maintainers will be > able to

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

2021-05-27 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request

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

2021-05-27 Thread Weijun Wang
On Thu, 27 May 2021 20:16:25 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: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-27 Thread Weijun Wang
On Thu, 27 May 2021 17:42:56 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update FtpClient.java > > src/java.desktop/share/classes/java/awt/Component.java line 63

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-27 Thread Weijun Wang
On Fri, 28 May 2021 03:12:35 GMT, Phil Race wrote: >> There *is* a tiny refactoring here: a new variable `s2` is introduced so the >> 2nd `doPrivileged` call on line 636 is now also in a declaration statement >> (for `s2`) and therefore annotatable. Without this I cannot add the >> annotation

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

2021-05-31 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revisi

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

2021-05-31 Thread Weijun Wang
On Mon, 31 May 2021 15:02:57 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: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7]

2021-06-01 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: r

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

2021-06-01 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now co

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

2021-06-02 Thread Weijun Wang
notations and javadoc tags, build, compiler, > core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are > reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now

Integrated: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

2021-06-02 Thread Weijun Wang
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. > https://github.c

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v4]

2021-06-02 Thread Weijun Wang
nt into a single statement if possible. > 4. Rewrite code to achieve #3 above. > > I'll add a copyright year update commit before integration. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8267521

Integrated: 8267521: Post JEP 411 refactoring: maximum covering > 50K

2021-06-02 Thread Weijun Wang
On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang wrote: > The code change refactors classes that have a `SuppressWarnings("removal")` > annotation that covers more than 50KB of code. The big annotation is often > quite faraway from the actual deprecated API usage it is suppr

RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-07 Thread Weijun Wang
More loudly and precise warning messages when either a security manager is enabled at startup or installed at runtime. - Commit messages: - 8268349: Provide more detail in JEP 411 warning messages Changes: https://git.openjdk.java.net/jdk/pull/4400/files Webrev: https://webrevs.op

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-08 Thread Weijun Wang
On Tue, 8 Jun 2021 06:41:11 GMT, Alan Bateman wrote: > > You might want to make your "WARNING" consistent with the VM's "Warning" so > > that OutputAnalyzer's logic to ignore warnings will automatically ignore > > these too. > > The uppercase "WARNING" is intentional here, it was the same with

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-08 Thread Weijun Wang
On Tue, 8 Jun 2021 06:11:17 GMT, Alan Bateman wrote: >> More loudly and precise warning messages when a security manager is either >> enabled at startup or installed at runtime. > > src/java.base/share/classes/java/lang/System.java line 331: > >> 329: >> 330: // Remember original System.er

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-08 Thread Weijun Wang
On Tue, 8 Jun 2021 17:15:29 GMT, Alan Bateman wrote: >> I thought about that but not sure of performance impact. Is the worst >> problem that more than one warnings will be printed for a single caller? >> It's not really harmless. >> >> As for the frame, if the warning message only contain the

Withdrawn: 8268349: Provide more detail in JEP 411 warning messages

2021-06-10 Thread Weijun Wang
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either > enabled at startup or installed at runtime. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jd

[jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-25 Thread Weijun Wang
More refactoring to limit the scope of `@SuppressWarnings` annotations. Sometimes I introduce new methods. Please feel free to suggest method names you like to use. - Commit messages: - 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K Changes: https://git.o

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-25 Thread Weijun Wang
> More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-26 Thread Weijun Wang
On Sat, 26 Jun 2021 16:53:30 GMT, Alan Bateman wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> one more > > src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java lin

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-28 Thread Weijun Wang
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote: >> More refactoring to limit the scope of `@SuppressWarnings` annotations. >> >> Sometimes I introduce new methods. Please feel free to suggest method names >> you like to use. > > Weijun Wang has updated the p

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v3]

2021-06-28 Thread Weijun Wang
> More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-28 Thread Weijun Wang
On Mon, 28 Jun 2021 12:20:38 GMT, Daniel Fuchs wrote: >> This cast is only to tell the compiler which overloaded method to call, and >> I don't think there will be a real cast at runtime. It might look a little >> ugly but extracting it into a variable declaration/definition plus a new >> `ini

[jdk17] Withdrawn: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-28 Thread Weijun Wang
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote: > More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. This pull request has been closed without bein

RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-28 Thread Weijun Wang
More refactoring to limit the scope of `@SuppressWarnings` annotations. Sometimes I introduce new methods. Please feel free to suggest method names you like to use. Note: this is copied from https://github.com/openjdk/jdk17/pull/152. - Commit messages: - copy all code change from

Integrated: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-28 Thread Weijun Wang
On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang wrote: > More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. > > Note: this is copied from https://github.com/

Re: RFR: 8272805: Avoid looking up standard charsets

2021-08-22 Thread Weijun Wang
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20

Re: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

2021-09-21 Thread Weijun Wang
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. Looks fine. Thanks. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5551

Re: RFR: 8274237: Replace 'for' cycles with iterator with enhanced-for in java.base

2021-09-24 Thread Weijun Wang
On Thu, 23 Sep 2021 20:42:48 GMT, Andrey Turbanov wrote: > There are few places in code where manual `for` loop is used with Iterator to > iterate over Collection. > Instead of manual `for` cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read

Re: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base

2021-10-08 Thread Weijun Wang
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check > if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to rea

  1   2   3   4   5   >