Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5]

[Weijun Wang]

On Thu, 28 Apr 2022 16:56:38 GMT, XenoAmess  wrote:

>> These are the changes that too many to be reviewed in 8186958, thus split 
>> some of them out.
>
> XenoAmess has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   revert changes to java.desktop as prrace said

src/java.base/share/classes/sun/security/rsa/SunRsaSignEntries.java line 58:

> 56: // start populating content using the specified provider
> 57: // common attribute map
> 58: HashMap attrs = HashMap.newHashMap(3);

Looks like 1 is enough.

-

PR: https://git.openjdk.java.net/jdk/pull/8301

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

[Weijun Wang]

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung  wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

The security related changes look fine, except for the year 2021.

-

PR: https://git.openjdk.java.net/jdk/pull/7765

Re: RFR: 8272805: Avoid looking up standard charsets

[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 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by 
> tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop 
> tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), 
> J2DBench(should be compatible to 1.4), some code in the network(the change 
> there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

The security related change looks fine to me.

-

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5210

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

[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/openjdk/jdk17/pull/152.

This pull request has now been integrated.

Changeset: e9b2c058
Author:Weijun Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/e9b2c058a4ed5de29b991360f78fc1c5263c9268
Stats: 293 lines in 21 files changed: 165 ins; 64 del; 64 mod

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

Reviewed-by: lancea, naoto

-

PR: https://git.openjdk.java.net/jdk/pull/4615

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

[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 jdk17

Changes: https://git.openjdk.java.net/jdk/pull/4615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4615=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 293 lines in 21 files changed: 165 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4615/head:pull/4615

PR: https://git.openjdk.java.net/jdk/pull/4615

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

[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 being integrated.

-

PR: https://git.openjdk.java.net/jdk17/pull/152

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

[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 
>> `initStatic` method seems not worth doing, IMHO.
>
> Why not simply declare a local variable in the static initializer below?
> 
> 
> private static final long CURRENT_PID;
> private static final boolean ALLOW_ATTACH_SELF;
> static {
> PrivilegedAction pa = ProcessHandle::current;
> @SuppressWarnings("removal")
> long pid = AccessController.doPrivileged(pa).pid();
> CURRENT_PID = pid;
> String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
> ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
> }

I've just pushed a commit with a different fix:

private static final long CURRENT_PID = pid();

@SuppressWarnings("removal")
private static long pid() {
PrivilegedAction pa = () -> ProcessHandle.current();
return AccessController.doPrivileged(pa).pid();
}

-

PR: https://git.openjdk.java.net/jdk17/pull/152

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

[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 pull request incrementally with one additional 
> commit since the last revision:
> 
>   one more

I'm going to move this to jdk18.

-

PR: https://git.openjdk.java.net/jdk17/pull/152

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

[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:

  one more refinement

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/774eb9da..2e4a8ba7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=152=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=152=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

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

[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 line 
> 53:
> 
>> 51: private static final long CURRENT_PID = 
>> AccessController.doPrivileged(
>> 52: (PrivilegedAction) 
>> ProcessHandle::current).pid();
>> 53: 
> 
> The original code separated out the declaration of the PrivilegedAction to 
> avoid this cast. If you move the code from the original static initializer 
> into a static method that it called from initializer then it might provide 
> you with a cleaner way to refactor this. There are several other places in 
> this patch that could do with similar cleanup.

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 
`initStatic` method seems not worth doing, IMHO.

-

PR: https://git.openjdk.java.net/jdk17/pull/152

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

[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:

  one more

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/d8b384df..774eb9da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=152=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=152=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

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

[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.openjdk.java.net/jdk17/pull/152/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=152=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 289 lines in 21 files changed: 161 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

Integrated: 8267543: Post JEP 411 refactoring: security

[Weijun Wang]

On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang  wrote:

> For all modified files in #4073 having "security", "crypto", or "ssl" in 
> their names. Codes are refactored to bring a `@SuppressWarning` annotation 
> nearer to the deprecated API usage and also shrink the size of its target.
> 
> I'll add a copyright year update commit before integration.

This pull request has now been integrated.

Changeset: 40d23a0c
Author:Weijun Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/40d23a0c0b955ae4636800be183da7a71665f79f
Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 mod

8267543: Post JEP 411 refactoring: security

Reviewed-by: mullan

-

PR: https://git.openjdk.java.net/jdk/pull/4172

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

[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 suppressing, and 
> with the annotation covering too big a portion it's easy to call other 
> deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide 
> annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local 
> variable and add annotation on the declaration, and then assign that value to 
> the original l-value if not void. The local variable will be called `tmp` if 
> later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

This pull request has now been integrated.

Changeset: 508cec75
Author:Weijun Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod

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

Reviewed-by: dfuchs, prr

-

PR: https://git.openjdk.java.net/jdk/pull/4138

Re: RFR: 8267543: Post JEP 411 refactoring: security [v3]

[Weijun Wang]

> For all modified files in #4073 having "security", "crypto", or "ssl" in 
> their names. Codes are refactored to bring a `@SuppressWarning` annotation 
> nearer to the deprecated API usage and also shrink the size of its target.
> 
> 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:

  8267543: Post JEP 411 refactoring: security

-

Changes: https://git.openjdk.java.net/jdk/pull/4172/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4172=02
  Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4172.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172

PR: https://git.openjdk.java.net/jdk/pull/4172

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

[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 
> deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide 
> annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local 
> variable and add annotation on the declaration, and then assign that value to 
> the original l-value if not void. The local variable will be called `tmp` if 
> later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment 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: Post JEP 411 refactoring: maximum covering > 50K

-

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4138=03
  Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>  The essential change for this JEP, including the `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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.

This pull request has now been integrated.

Changeset: 6765f902
Author:Weijun Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1
Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod

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

Co-authored-by: Sean Mullan 
Co-authored-by: Lance Andersen 
Co-authored-by: Weijun Wang 
Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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 contains 14 commits:

 - copyright years
 - merge from master, resolve one conflict
 - Merge branch 'master'
 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5

-

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4073=08
  Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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 contains 11 commits:

 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

-

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4073=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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:

  rename setSecurityManagerDirect to implSetSecurityManager

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4073=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4073=05-06

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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. 
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` 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.
>> 
>> Update: the deprecation annotations 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:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to 
`-Djava.security.manager=allow`. No warning will be shown when the system 
property is set to "allow", "disallow", or not set. A new test is added to 
check these warning messages. Some tests are updated to match the new behavior.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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:

  default behavior reverted to allow

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4073=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4073=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 on line 635.
>
> Ok. But I will quote you
> "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"
> 
> So the way you explained this before made it sound like any time there was 
> any SM API usage in a static block, the entire class needed to be annotated.
> 
> Why has the explanation changed ?

I should have been more precise. An annotation can only be added on a 
declaration, whether it's a variable, a method, or a class. Static block is not 
a declaration and the only one covers it is the class. But then if it's on a 
local variable declaration inside a static block, we certainly can annotate on 
that variable.

-

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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 630:
> 
>> 628: }
>> 629: 
>> 630: @SuppressWarnings("removal")
> 
> I'm confused. I thought the reason this wasn't done in the JEP implementation 
> PR is because of refactoring
> that was needed because of the usage in this static block and you could not 
> apply the annotation here.
> Yet it seems you are doing exactly what was supposed to be impossible with no 
> refactoring.
> Can you explain ?

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 on 
line 635.

-

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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. 
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` 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.
>> 
>> Update: the deprecation annotations 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 contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in 
`XMLSchemaFactory.java` got [its 
own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429)
 `@SuppressWarnings` and have to be merged with the one here. Another file 
`ResourceBundle.java` had a portion of a method extracted into a [new 
method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175)
 and the annotation must be moved there.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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 contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4073=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

Re: RFR: 8267543: Post JEP 411 refactoring: security [v2]

[Weijun Wang]

On Tue, 25 May 2021 21:25:54 GMT, Sean Mullan  wrote:

> Update copyright dates to 2021, if applicable.

Will do. Since this PR can only be integrated after its parent PR #4073 is 
integrated. I'll delay the copyright update by then.

-

PR: https://git.openjdk.java.net/jdk/pull/4172

Re: RFR: 8267543: Post JEP 411 refactoring: security [v2]

[Weijun Wang]

> For all modified files in #4073 having "security", "crypto", or "ssl" in 
> their names. Codes are refactored to bring a `@SuppressWarning` annotation 
> nearer to the deprecated API usage and also shrink the size of its target.
> 
> I'll add a copyright year update commit before integration.

Weijun Wang has updated the pull request incrementally with one additional 
commit since the last revision:

  one more change

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4172/files
  - new: https://git.openjdk.java.net/jdk/pull/4172/files/b22fd7d7..176f44e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4172=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4172=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4172.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172

PR: https://git.openjdk.java.net/jdk/pull/4172

Re: RFR: 8267543: Post JEP 411 refactoring: security [v2]

[Weijun Wang]

On Tue, 25 May 2021 13:44:30 GMT, Sean Mullan  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   one more change
>
> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java 
> line 709:
> 
>> 707: }
>> 708: if (GSSUtil.useSubjectCredsOnly(caller)) {
>> 709: @SuppressWarnings("removal")
> 
> It looks like you missed removing the @SuppressWarnings("removal") from the 
> initSecContext method above.

Oops. Fixed.

-

PR: https://git.openjdk.java.net/jdk/pull/4172

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

[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 deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a 
method might make it faraway from its caller. In L114 of `FtpClient.java` I 
managed to invent a return value and I thought it was perfect. But you said 
it's "a bit strange". :-(

-

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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.setSecurityManager()`  need 
> `-Djava.security.manager=allow` when launched. This PR covers such changes 
> for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is 
> divided into multiple commits for different areas (~~serviceability~~, 
> ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, 
> ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, 
> ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the 
> same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my 
> best to avoid putting too many tests into `core-libs`. If a file is covered 
> by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the 
> `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the 
> `rmi` commit.
> 4. One file not covered by any label -- 
> `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in 
> the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 
> 411, as the possible values of this system property was already defined long 
> time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of 
> `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it 
> was not `othervm` and we add one. Sometimes there's no `@run` at all and we 
> add the line.
> 
> There are several tests that launch another Java process that needs to call 
> the `System.setSecurityManager()` method, and the system property is added to 
> `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a 
> shell test).
> 
> 3 langtools tests are added into problem list due to 
> [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line 
> but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => 
> 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.

This pull request has now been integrated.

Changeset: 640a2afd
Author:Weijun Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats: 1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

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

Co-authored-by: Lance Andersen 
Co-authored-by: Weijun Wang 
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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 tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is 
> divided into multiple commits for different areas (~~serviceability~~, 
> ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, 
> ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, 
> ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the 
> same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my 
> best to avoid putting too many tests into `core-libs`. If a file is covered 
> by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the 
> `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the 
> `rmi` commit.
> 4. One file not covered by any label -- 
> `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in 
> the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 
> 411, as the possible values of this system property was already defined long 
> time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of 
> `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it 
> was not `othervm` and we add one. Sometimes there's no `@run` at all and we 
> add the line.
> 
> There are several tests that launch another Java process that needs to call 
> the `System.setSecurityManager()` method, and the system property is added to 
> `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a 
> shell test).
> 
> 3 langtools tests are added into problem list due to 
> [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line 
> but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => 
> 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 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 20 additional commits since the 
last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4071=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4071=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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
>>> 104:  * special token "{@code allow}", then a security manager will not be 
>>> set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a 
>> given system property? I thought it should be used only once, at the place 
>> where the system property is defined. Maybe @jonathan-gibbons can offer some 
>> more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, 
> and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty 
> java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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:

  keep only one systemProperty tag

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4073=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4073=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57: ProcessCommunicator
> > 58: .executeChildProcess(Consumer.class, new 
> > String[0]);
> > 59: if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at 
the end of page.

This is because the process is now launched with 
`-Djava.security.manager=allow` (because of another change in 
https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in 
stderr. Therefore I switched to stdout.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 
> deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide 
> annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated 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 request incrementally with one additional 
commit since the last revision:

  update FtpClient.java

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4138=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4138=01-02

  Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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 550:
> 
>> 548:  * @throws IOException if the connection was unsuccessful.
>> 549:  */
>> 550: @SuppressWarnings("removal")
> 
> Could the scope of the annotation be further reduced by applying it to the 
> two places where `doPrivileged` is called in this method?

I'll probably need to assign the doPriv result on L631 to a tmp variable and 
then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you 
already have similar suggestion in the next comment.

-

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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/FtpClient.java line 120:
> 
>> 118: vals[1] = 
>> Integer.getInteger("sun.net.client.defaultConnectTimeout", 
>> 300_000).intValue();
>> 119: return System.getProperty("file.encoding", 
>> "ISO8859_1");
>> 120: }
> 
> It is a bit strange that "file.encoding" seem to get a special treatment - 
> but I guess that's OK.

You might say we thus avoid wasting the return value, as much as possible.

-

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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 tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is 
> divided into multiple commits for different areas (~~serviceability~~, 
> ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, 
> ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, 
> ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the 
> same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my 
> best to avoid putting too many tests into `core-libs`. If a file is covered 
> by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the 
> `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the 
> `rmi` commit.
> 4. One file not covered by any label -- 
> `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in 
> the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 
> 411, as the possible values of this system property was already defined long 
> time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of 
> `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it 
> was not `othervm` and we add one. Sometimes there's no `@run` at all and we 
> add the line.
> 
> There are several tests that launch another Java process that needs to call 
> the `System.setSecurityManager()` method, and the system property is added to 
> `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a 
> shell test).
> 
> 3 langtools tests are added into problem list due to 
> [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line 
> but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => 
> 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 pull request incrementally with one additional 
commit since the last revision:

  feedback from Phil
  
  reverted:

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4071=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4071=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights 
>> reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually 
> modified.

Oops, I'll back it out. Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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 
> deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide 
> annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated 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 request incrementally with one additional 
commit since the last revision:

  typo on windows

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4138=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4138=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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 deprecated 
methods without being noticed.

-

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267521: Post JEP 411 refactoring: maximum covering > 50K

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4138=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267521
  Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

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

[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 
>> really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds 
>> to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply 
>> your automated tool to the file but this is just work you'd have to have 
>> done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the 
>> question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual 
> work and we will see everyone having their preferences. The more time we 
> spend on this PR the more likely there will be merge conflict. There are just 
> too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be 
> after the automatic conversion. In fact, the data about which cases are more 
> worth fixing come from the automatic conversion itself. Also, as the manual 
> work will be done part by part, if the automatic conversion is after it, 
> there will be rounds and rounds of history rewriting and force push. This is 
> quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, 
> `java.awt.Component` is the one with the biggest class -- estimated number of 
> bytes that the annotation covers is over 380K. In the client area, the 2nd 
> place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, 
> `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 
> classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix 
it after RDP. So I'll convert it now.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 change is worth doing (Ex: which is uglier between an 
>> a-liitle-faraway-annotation and a temporary variable?) so it's not obvious 
>> what the scope of the refactoring can be. Thus it will be divided into 
>> smaller sub-tasks. It's not totally impossible that part of the work will be 
>> delayed to next release.
>
> 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 
> really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to 
> do that.
> Then yes, you would have to deal with the fact that now you need to reapply 
> your automated tool to the file but this is just work you'd have to have done 
> anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the 
> question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual 
work and we will see everyone having their preferences. The more time we spend 
on this PR the more likely there will be merge conflict. There are just too 
many files here.

And no matter if we include that change in this PR or after it, it will be 
after the automatic conversion. In fact, the data about which cases are more 
worth fixing come from the automatic conversion itself. Also, as the manual 
work will be done part by part, if the automatic conversion is after it, there 
will be rounds and rounds of history rewriting and force push. This is quite 
unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, 
`java.awt.Component` is the one with the biggest class -- estimated number of 
bytes that the annotation covers is over 380K. In the client area, the 2nd 
place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, 
`java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 
classes over 10KB, and other 11 classes smaller than 10KB.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 to see why it's necessary and we can take time 
>> to do them little by little. A new enhancement at 
>> https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) 
> do next release.
> I think it should all be taken care of as part of this proposed change.

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 change 
is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and 
a temporary variable?) so it's not obvious what the scope of the refactoring 
can be. Thus it will be divided into smaller sub-tasks. It's not totally 
impossible that part of the work will be delayed to next release.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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.doPrivileged(
>> new 
>> GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that 
> it is insurmountable.
> You can define a static private method to contain this and call it from the 
> static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements 
> ImageObserver, MenuContainer,
>   */
>  static boolean isInc;
>  static int incRate;
> +
> +private static void initIncRate() {
> +String s = java.security.AccessController.doPrivileged(
> + new 
> GetPropertyAction("awt.image.incrementaldraw"));
> +isInc = (s == null || s.equals("true"));
> +
> +s = java.security.AccessController.doPrivileged(
> +  new GetPropertyAction("awt.image.redrawrate"));
> +incRate = (s != null) ? Integer.parseInt(s) : 100;
> +}
> +
>  static {
>  /* ensure that the necessary native libraries are loaded */
>  Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements 
> ImageObserver, MenuContainer,
>  if (!GraphicsEnvironment.isHeadless()) {
>  initIDs();
>  }
> -
> -String s = java.security.AccessController.doPrivileged(
> -   new 
> GetPropertyAction("awt.image.incrementaldraw"));
> -isInc = (s == null || s.equals("true"));
> -
> -s = java.security.AccessController.doPrivileged(
> -new 
> GetPropertyAction("awt.image.redrawrate"));
> -incRate = (s != null) ? Integer.parseInt(s) : 100;
> +initIncRate();
>  }

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 to 
see why it's necessary and we can take time to do them little by little. A new 
enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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(
>> new GetBooleanAction("java.awt.smartInvalidate"));
>> }
>
> We are thinking of more tweaks after this overall change to make the 
> annotation more precise. For example, in this case we can assign the 
> `doPrivileged` result to a local variable right at its declaration, and then 
> assign it to `isJavaAwtSmartInvalidate`. Some people might think this is 
> ugly. Such manual code changes need to done little by little to ease code 
> reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit 
totally automatic. Hopefully you have more confidence on the program than my 
hand. All annotations are added to the nearest declarations.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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. a > 5,000 line file that uses AccessController 
>> in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific 
>> site ?
>
> Similar as the one above, it's because of
> 
> static {
> // Don't lazy-read because every app uses invalidate()
> isJavaAwtSmartInvalidate = AccessController.doPrivileged(
> new GetBooleanAction("java.awt.smartInvalidate"));
> }

We are thinking of more tweaks after this overall change to make the annotation 
more precise. For example, in this case we can assign the `doPrivileged` result 
to a local variable right at its declaration, and then assign it to 
`isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual 
code changes need to done little by little to ease code reviewing.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author  Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 
> places it uses AccessController or AcessControlContext.

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.doPrivileged(
new 
GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since 1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController 
> in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site 
> ?

Similar as the one above, it's because of

static {
// Don't lazy-read because every app uses invalidate()
isJavaAwtSmartInvalidate = AccessController.doPrivileged(
new GetBooleanAction("java.awt.smartInvalidate"));
}

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57: ProcessCommunicator
>> 58: .executeChildProcess(Consumer.class, new 
>> String[0]);
>> 59: if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the 
other PR) and a warning will be printed to stderr. Therefore I move the message 
to stdout.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.
> 
> Update: the deprecation annotations 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:

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4073=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4073=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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. 
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` 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.
>> 
>> Update: the deprecation annotations 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:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` 
test in tier4. The test compares stderr output with a known value but we have a 
new warning written to stderr now. It's now using stdout instead. @prrace, 
Please confirm this is acceptable. Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is 
> divided into multiple commits for different areas (~~serviceability~~, 
> ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, 
> ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, 
> ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the 
> same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my 
> best to avoid putting too many tests into `core-libs`. If a file is covered 
> by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the 
> `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the 
> `rmi` commit.
> 4. One file not covered by any label -- 
> `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in 
> the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 
> 411, as the possible values of this system property was already defined long 
> time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of 
> `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it 
> was not `othervm` and we add one. Sometimes there's no `@run` at all and we 
> add the line.
> 
> There are several tests that launch another Java process that needs to call 
> the `System.setSecurityManager()` method, and the system property is added to 
> `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a 
> shell test).
> 
> 3 langtools tests are added into problem list due to 
> [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line 
> but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => 
> 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 pull request incrementally with one additional 
commit since the last revision:

  adjust order of VM options

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4071=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4071=00-01

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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 `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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 updated the pull request incrementally with one additional 
commit since the last revision:

  feedback from Sean, Phil and Alan

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4073=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4073=00-01

  Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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(PrivilegedExceptionAction 
>>> action,
>>> 877:  @SuppressWarnings("removal") 
>>> AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. 
>> There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:
@SuppressWarnings("removal") AccessControlContext context, Permission... perms) 
{
src/java.base/share/classes/java/security/AccessController.java:514:
@SuppressWarnings("removal") AccessControlContext context, Permission... perms) 
{
src/java.base/share/classes/java/security/AccessController.java:877:
 @SuppressWarnings("removal") AccessControlContext 
context, Permission... perms)

I'll fix them manually.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` 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.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875: @CallerSensitive
>> 876: public static  T doPrivileged(PrivilegedExceptionAction 
>> action,
>> 877:  @SuppressWarnings("removal") 
>> AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. 
> There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the 
insert position and the previous line does not end with a comma. In this case, 
unless I move `Permission... perms` onto a new line that an annotation on a new 
line looks like covering both `context` and `perms`.

-

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java
>  - the tests sets the system properties after -Xbootclasspath/a: but the 
> change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in 
> the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks 
good to group system property settings together. Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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 
>> `-Djava.security.manager=allow` when launched. This PR covers such changes 
>> for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is 
>> divided into multiple commits for different areas (~~serviceability~~, 
>> ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, 
>> hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, 
>> ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but 
>> there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my 
>> best to avoid putting too many tests into `core-libs`. If a file is covered 
>> by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the 
>> `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the 
>> `rmi` commit.
>> 4. One file not covered by any label -- 
>> `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in 
>> the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 
>> 411, as the possible values of this system property was already defined long 
>> time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of 
>> `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes 
>> it was not `othervm` and we add one. Sometimes there's no `@run` at all and 
>> we add the line.
>> 
>> There are several tests that launch another Java process that needs to call 
>> the `System.setSecurityManager()` method, and the system property is added 
>> to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test 
>> is a shell test).
>> 
>> 3 langtools tests are added into problem list due to 
>> [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line 
>> but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => 
>> 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.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java
>  line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls 
> `System.setProperty("java.security.policy", policyFile);` - even though it 
> doesn't call System.setSecurityManager(); Should the @run command line for 
> test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager 
is set? IIRC jtreg is able to restore system properties even in agentvm mode. 
So maybe this really doesn't matter. We just want to modify as little as 
possible in this PR.

-

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>  The essential change for this JEP, including the `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` 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.

The 3rd commit is the biggest one but it's all generated programmatically. All 
changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

= 2 
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
= 1 
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
= 1 
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
= 1 
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
= 1 
- @SuppressWarnings("unchecked") /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"}) /*To suppress warning from 
line 1374*/
= 1 
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

= 7 
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
= 4 
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
= 3 
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
= 3 
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
= 2 
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = 
AccessController.doPrivileged(pa)) {
= 2 
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... 
perms) {
= 2 
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) 
{
= 2 
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
= 2 
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
= 2 
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginE

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

[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 `@Deprecate` annotations and 
spec change. It also update the default value of the `java.security.manager` 
system property to "disallow", and necessary test change following this update.
2. 
https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 
Manual changes to several files so that the next commit can be generated 
programatically.
3. 
https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 
Automatic changes to other source files to avoid javac warnings on deprecation 
for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated 
programmatically, see the comment below for more details. If you are only 
interested in a portion of the 3rd commit and would like to review it as a 
separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for 
any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` 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.

-

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4073=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

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

[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 
tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is 
divided into multiple commits for different areas. Mostly the rule is the same 
as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my 
best to avoid putting too many tests into `core-libs`. If a file is covered by 
`core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the 
`xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the 
`rmi` commit.
4. One file not covered by any label -- 
`test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the 
`swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for 
all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 
411, as the possible values of this system property was already defined long 
time ago in JDK 9.

Most of the change in this PR is a simple adding of 
`-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it 
was not `othervm` and we add one. Sometimes there's no `@run` at all and we add 
the line.

There are several tests that launch another Java process that needs to call the 
`System.setSecurityManager()` method, and the system property is added to 
`ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a 
shell test).

3 langtools tests are added into problem list due to 
[JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line 
but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => 
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.

-

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4071=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

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

[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 to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

The other security-related code changes look good to me.

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 
49:

> 47: throws IOException
> 48: {
> 49: return is.readAllBytes();

This is also from Apache Santuario. It's better to keep it unchanged.

-

PR: https://git.openjdk.java.net/jdk/pull/1853

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5]

[Weijun Wang]

On Tue, 26 Jan 2021 18:42:02 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Revert harfbuzz changes, disable warnings for it

src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:

> 46: // Condition was copied from
> 47: // 
> Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || 
> defined(__i386__) || defined(__x86_64__))

So for macOS/AArch64, this `if` is no longer true?

-

PR: https://git.openjdk.java.net/jdk/pull/2200

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

[Weijun Wang]

> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie 
>  wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth

There is only one function to export and it already has JNIEXPORT, so you can 
just remove the new $(LIBJAAS_CFLAGS) [1].

Are you going to update your webrev?

Thanks
Max

[1] 
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html

Re: RFR: 8189102: All tools should support -?, -h and --help

[Weijun Wang]

Hi Goetz

I would just remove it.

Thanks
Max

> On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz <goetz.lindenma...@sap.com> 
> wrote:
> 
> Hi Max, 
> 
> while removing the comments from the k-tools, I saw this:
> 
> --- 
> a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java
>   Tue Oct 10 14:39:45 2017 +0200
> +++ 
> b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java
>   Tue Nov 21 13:09:17 2017 +0100
> @@ -356,7 +358,6 @@
> System.out.println("\t-t \t shows keytab entry timestamps");
> System.out.println("\t-K \t shows keytab entry key value");
> System.out.println("\t-e \t shows keytab entry key type");
> -System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
> -   "-help for help.");
> +System.out.println("\n-? -h --help print this help message and 
> exit");
> }
> }
> 
> I don't think the old comment is in the original program :) and anyways, -help
> is not supported by Klist.  It prints the usage called with the flag, but 
> just because
> it prints it on any wrong flag.
> 
> So should I replace the comment here?
> Or at least remove it?
> 
> Best regards,
>  Goetz
> 
>> -Original Message-
>> From: Weijun Wang [mailto:weijun.w...@oracle.com]
>> Sent: Monday, November 20, 2017 3:49 PM
>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
>> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
>> serviceability-dev (serviceability-dev@openjdk.java.net) > d...@openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> Hi Goetz
>> 
>> I understand your intention.
>> 
>> If the reason is that one day every tool will switch to this new style, 
>> please at
>> least do not include kinit, klist and ktab. These Windows-only commands are
>> meant to emulate MIT krb5 tools with the same names and we need to keep
>> the option (and maybe the help screen) as similar as possible.
>> 
>> I am OK with supporting the --help option undocumented.
>> 
>> Thanks
>> Max
>> 
>>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
>> <goetz.lindenma...@sap.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> I think there are so many tools mixing both kinds of
>>> options, that it's rather a gain if all at least document
>>> the same, up to date help message, than if the documentation
>>> is skipped for some.
>>> 
>>> After my change, all the help messages are quite similar.
>>> I updated them to use the same wording while trying to
>>> keep the sentence structure in accordance with the other
>>> documented flags, see below.
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -? -h --help   display this help message
>>> -? -h --help  display this help message
>>> -h, --help (Print this help message.)
>>> -?, --help   Print this help message
>>> -? -h --help Print this help message
>>> --help, -h, -?  Display command line options and exit
>>> -? -h --help Print this help message
>>> -h -? --help  Print this help message
>>> -? -h --help
>>> -? -h --help  : display this help message and exit
>>> -? -h --help   :  display this help message and exit
>>> -? -h --help  print this help message and exit
>>> -? | -h | --help to print this help message
>>> jmap -? -h --help  to print this help message
>>> usage: jps [-? -h --help]
>>> -? -h --help to print this help message
>>> -? -h --help  Prints this help message.
>>> -? -h --help print this help message
>>> -? -h --help  Print this synopsis of standard options and exit
>>> Use "keytool -? -h or --help" for all available commands
>>> --helpprint this help message to the output stream
>>> -?, -h, --help   Print this help message
>>> -h, --help, -?Print this help message
>>> -?, -h, --help   Print this help message
>>> -? -h --help Print this help message and exit
>>> -?, -h, --help  print this help message
>>> -?, -h, --helpprint this help message
>>> -? -h --help   Print this help message
>>

Re: RFR: 8189102: All tools should support -?, -h and --help

[Weijun Wang]

Hi Goetz

I understand your intention.

If the reason is that one day every tool will switch to this new style, please 
at least do not include kinit, klist and ktab. These Windows-only commands are 
meant to emulate MIT krb5 tools with the same names and we need to keep the 
option (and maybe the help screen) as similar as possible.

I am OK with supporting the --help option undocumented.

Thanks
Max

> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz <goetz.lindenma...@sap.com> 
> wrote:
> 
> Hi Max, 
> 
> I think there are so many tools mixing both kinds of
> options, that it's rather a gain if all at least document
> the same, up to date help message, than if the documentation 
> is skipped for some.
> 
> After my change, all the help messages are quite similar.
> I updated them to use the same wording while trying to
> keep the sentence structure in accordance with the other
> documented flags, see below.
> 
> Best regards,
>  Goetz.
> 
> 
> 
> -? -h --help   display this help message
> -? -h --help  display this help message
> -h, --help (Print this help message.)
> -?, --help   Print this help message
> -? -h --help Print this help message
> --help, -h, -?  Display command line options and exit
> -? -h --help Print this help message
> -h -? --help  Print this help message
> -? -h --help
> -? -h --help  : display this help message and exit
> -? -h --help   :  display this help message and exit
> -? -h --help  print this help message and exit
> -? | -h | --help to print this help message
> jmap -? -h --help  to print this help message
> usage: jps [-? -h --help]
> -? -h --help to print this help message
> -? -h --help  Prints this help message.
> -? -h --help print this help message
> -? -h --help  Print this synopsis of standard options and exit
> Use "keytool -? -h or --help" for all available commands
> --helpprint this help message to the output stream
> -?, -h, --help   Print this help message
> -h, --help, -?Print this help message
> -?, -h, --help   Print this help message
> -? -h --help Print this help message and exit
> -?, -h, --help  print this help message
> -?, -h, --helpprint this help message
> -? -h --help   Print this help message
> -?, -h, --help[:compat]Give this, or optionally the compatibility, help
> [-? -h --help]  Print this help message
> jstatd -?|-h|--help
> 
> 
>> -Original Message-
>> From: Weijun Wang [mailto:weijun.w...@oracle.com]
>> Sent: Sonntag, 19. November 2017 01:28
>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
>> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
>> serviceability-dev (serviceability-dev@openjdk.java.net) > d...@openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> I am OK with all commands supporting --help, but I am not sure if every tool
>> should show it on the help screen if the tools's other options are still 
>> using
>> the old single-"-" style. It looks like the tools are half-converted.
>> 
>> Is there a timetable to add "--" support to all tools?
>> 
>> Thanks
>> Max
>> 
>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
>> <goetz.lindenma...@sap.com> wrote:
>>> 
>>> Hi,
>>> 
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>> helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>> 
>>> See the webrev for a detailed description of the changes.
>>> 
>>> If required, I'll make break-out changes to be reviewed separately.
>>> 
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>> 
>>> Best regards,
>>> Goetz.
>>> 
> 

Re: RFR: 8189102: All tools should support -?, -h and --help

[Weijun Wang]

I am OK with all commands supporting --help, but I am not sure if every tool 
should show it on the help screen if the tools's other options are still using 
the old single-"-" style. It looks like the tools are half-converted.

Is there a timetable to add "--" support to all tools?

Thanks
Max

> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz  
> wrote:
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to 
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
> 
> Best regards,
>  Goetz.
> 

Re: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group

[Weijun Wang]

The com/sun/jarsigner line should be added to jdk_security3.

Roughly, the categories mean:

1: public APIs
2: JCE
3: implementation and private APIs
4: JGSS/krb5

Thanks
Max

On 03/27/2017 11:06 AM, Amy Lu wrote:

jdk/internal/loader
jdk/internal/util
com/sun/jarsigner
jdk/internal/agent

Somehow these are missed in TEST.group.

Please review this patch to update TEST.group

Tested on all platforms, TestVersionedStream.java fails on Windows, put
it in ProblemList.txt for now.

bug: https://bugs.openjdk.java.net/browse/JDK-8177638
webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/

Thanks,
Amy


--- old/test/ProblemList.txt2017-03-27 10:57:36.0 +0800
+++ new/test/ProblemList.txt2017-03-27 10:57:36.0 +0800
@@ -286,6 +286,7 @@

 java/util/BitSet/BitSetStreamTest.java  8079538 
generic-all

+jdk/internal/util/jar/TestVersionedStream.java  8177640 
windows-all

 

--- old/test/TEST.groups2017-03-27 10:57:38.0 +0800
+++ new/test/TEST.groups2017-03-27 10:57:38.0 +0800
@@ -70,6 +70,7 @@
 sun/reflect \
 jdk/internal/reflect \
 jdk/lambda \
+jdk/internal/loader \
 jdk/internal/misc \
 jdk/internal/ref \
 jdk/internal/jimage \
@@ -87,6 +88,7 @@
 jdk_util_other = \
 java/util \
 sun/util \
+jdk/internal/util \
 -:jdk_collections \
 -:jdk_concurrent \
 -:jdk_stream
@@ -189,6 +191,7 @@
 lib/security

 jdk_security4 = \
+com/sun/jarsigner \
 com/sun/security/jgss \
 javax/security/auth/kerberos \
 sun/security/krb5 \
@@ -207,7 +210,8 @@
 jdk_management = \
 java/lang/management \
 com/sun/management \
-sun/management
+sun/management \
+jdk/internal/agent

 jdk_instrument = \
 java/lang/instrument

Re: RFR 8160913: [TEST_BUG] javax/management/security/SecurityTest.java fails due to missing keyStore file

[Weijun Wang]

Looks fine to me.

Thanks
Max

On 8/16/2016 14:19, Mallikarjuna Avaluri wrote:

Hi,

Reminder,  please help me with this review.


Regards,

Mallikarjuna Avaluri


On 8/9/2016 11:11 AM, Mallikarjuna Avaluri wrote:

Hi all,

Could you please review fix for following issue.

Bug id: https://bugs.openjdk.java.net/browse/JDK-8160913

Summary: [TEST_BUG] javax/management/security/SecurityTest.java fails
due to missing keyStore file

Solution:  Following files keystoreAgent, keystoreClient,
truststoreAgent and truststoreClient were created under
jdk/test/javax/management/ folder,
while test expects them under jdk/test/javax/management/security/
path. Moved the files to correct folder.

Webrev:
http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/




Thanks,
Mallikarjuna Avaluri

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

[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/sun/security/tools/jarsigner/EntriesOrder.java

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

[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.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/LoginNoPass.java

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

[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

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

[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

Re: RFR: 8027765 Make exit codes and stdout/stderr printing from jmap/jinfo/jstack/jps consistent

[Weijun Wang]

But it's changing from stdout to stderr in the webrev. At least GNU 
believes [1] it should go to stdout. It make the output more'able.


Also, I am not sure if

  int exit = arg1.equals(-help) || arg1.equals(-h) ? 0 : 1;

really does what it intends to. Cannot remember the precedence order of 
all these operators. I would add parentheses.


Thanks
Max

[1] http://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html

On 11/14/13, 17:38, Alan Bateman wrote:

On 14/11/2013 07:34, Staffan Larsen wrote:

Still looking for an official Review of this change.

This looks okay to me (I surprised we hadn't noticed the usage message
going to stderr before). Slightly different styles for if-the-else in
JStack but not too interesting. I guess we could use strings-in-switch
here if there are more options added.

-Alan

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

[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
+ test/sun/security/tools/jarsigner/CertChainUnclosed.java

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

[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 leif.samuels...@oracle.com

! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/tools/policytool/Resources.java

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

[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/TimeZoneDatePermissionCheck.sh
! test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/tools/jarsigner/checkusage.sh
! test/sun/security/tools/jarsigner/collator.sh
! test/sun/security/tools/jarsigner/crl.sh
! test/sun/security/tools/jarsigner/jvindex.sh
! test/sun/security/tools/jarsigner/newsize7.sh
! test/sun/security/tools/jarsigner/onlymanifest.sh
! test/sun/security/tools/jarsigner/passtype.sh
! test/sun/security/tools/jarsigner/samename.sh
! test/sun/security/tools/jarsigner/ts.sh
! test/sun/security/tools/keytool/CloseFile.java
! test/sun/security/tools/keytool/ListKeychainStore.sh
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/tools/keytool/UnknownAndUnparseable.java
! test/sun/security/tools/keytool/emptysubject.sh
! test/sun/security/tools/keytool/importreadall.sh
! test/sun/security/tools/keytool/p12importks.sh
! test/sun/security/tools/keytool/readjar.sh
! test/sun/security/tools/keytool/selfissued.sh
! test/sun/security/tools/keytool/trystore.sh
! test/sun/security/validator/certreplace.sh
! test/sun/security/validator/samedn.sh

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

[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/tools/keytool/autotest.sh

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

[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 leif.samuels...@oracle.com

! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/tools/policytool/Resources.java
! test/sun/security/tools/policytool/Alias.html
! test/sun/security/tools/policytool/OpenPolicy.html
! test/sun/security/tools/policytool/UpdatePermissions.html

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

[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.java
! src/share/classes/sun/security/krb5/KrbCred.java

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

[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: 8012615: Realm.getRealmsList returns realms list in wrong

[weijun . wang]

Changeset: ee8b292ee568
Author:weijun
Date:  2013-09-18 18:22 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee8b292ee568

8012615: Realm.getRealmsList returns realms list in wrong
Reviewed-by: valeriep, xuelei

! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! test/sun/security/krb5/ParseCAPaths.java
! test/sun/security/krb5/krb5-capaths.conf

hg: jdk8/tl/jdk: 8011402: Move blacklisting certificate logic from hard code to data

[weijun . wang]

Changeset: 07d73060e0da
Author:weijun
Date:  2013-09-18 21:37 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07d73060e0da

8011402: Move blacklisting certificate logic from hard code to data
Reviewed-by: erikj, mullan

! make/java/security/Makefile
! makefiles/CopyFiles.gmk
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/sun/security/util/UntrustedCertificates.java
! src/share/classes/sun/security/x509/X509CertImpl.java
+ src/share/lib/security/BlacklistedCertsConverter.java
+ src/share/lib/security/blacklisted.certs
+ src/share/lib/security/blacklisted.certs.pem
+ test/lib/security/CheckBlacklistedCerts.java

hg: jdk8/tl/jdk: 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc*

[weijun . wang]

Changeset: 6bfabb71ae1e
Author:weijun
Date:  2013-09-09 11:08 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bfabb71ae1e

8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded 
linux-ppc*
Reviewed-by: xuelei

! test/sun/security/krb5/runNameEquals.sh

hg: jdk8/tl/jdk: 2 new changesets

[weijun . wang]

Changeset: ca53110f1c74
Author:weijun
Date:  2013-08-27 17:50 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca53110f1c74

8015669: KerberosPrincipal::equals should ignore name-type
Reviewed-by: mullan

! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
+ test/sun/security/krb5/auto/KPEquals.java

Changeset: 4bddc344848e
Author:weijun
Date:  2013-08-27 17:50 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bddc344848e

8022761: regression: SecurityException is NOT thrown while trying to pack a 
wrongly signed Indexed Jar file
Reviewed-by: sherman

! src/share/classes/java/util/jar/JarVerifier.java
+ test/sun/security/tools/jarsigner/jvindex.sh

hg: jdk8/tl/jdk: 8016594: Native Windows ccache still reads DES tickets

[weijun . wang]

Changeset: b7d594716f86
Author:weijun
Date:  2013-08-08 21:13 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7d594716f86

8016594: Native Windows ccache still reads DES tickets
Reviewed-by: dsamersoff, xuelei

! src/share/classes/sun/security/krb5/Credentials.java
! src/share/native/sun/security/krb5/nativeccache.c
! src/windows/native/sun/security/krb5/NativeCreds.c

hg: jdk8/tl/jdk: 8021788: JarInputStream doesn't provide certificates for some file under META-INF

[weijun . wang]

Changeset: 758e3117899c
Author:weijun
Date:  2013-08-09 11:41 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c

8021788: JarInputStream doesn't provide certificates for some file under 
META-INF
Reviewed-by: chegar, sherman

! src/share/classes/java/util/jar/JarVerifier.java
+ test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java

hg: jdk8/tl/jdk: 7151062: [macosx] SCDynamicStore prints error messages to stderr

[weijun . wang]

Changeset: 906dd23334c1
Author:weijun
Date:  2013-08-07 19:06 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/906dd23334c1

7151062: [macosx] SCDynamicStore prints error messages to stderr
Reviewed-by: xuelei

! src/macosx/native/java/util/SCDynamicStoreConfig.m

hg: jdk8/tl/jdk: 8021789: jarsigner parses alias as command line option (depending on locale)

[weijun . wang]

Changeset: 29f153e11683
Author:weijun
Date:  2013-08-02 08:59 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f153e11683

8021789: jarsigner parses alias as command line option (depending on locale)
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/jarsigner/Main.java
+ test/sun/security/tools/jarsigner/collator.sh

hg: jdk8/tl/jdk: 8019410: sun/security/krb5/auto/ReplayCacheTestProc.java

[weijun . wang]

Changeset: 5f2a8db78aca
Author:weijun
Date:  2013-07-13 08:47 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f2a8db78aca

8019410: sun/security/krb5/auto/ReplayCacheTestProc.java
Reviewed-by: mullan

! test/sun/security/krb5/auto/ReplayCacheTestProc.java

hg: jdk8/tl/jdk: 8016051: Possible ClassCastException in KdcComm

[weijun . wang]

Changeset: 89631a384ee6
Author:weijun
Date:  2013-06-25 21:51 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89631a384ee6

8016051: Possible ClassCastException in KdcComm
Reviewed-by: weijun
Contributed-by: Artem Smotrakov artem.smotra...@oracle.com

! src/share/classes/sun/security/krb5/KdcComm.java

hg: jdk8/tl/jdk: 8017453: ReplayCache tests fail on multiple platforms

[weijun . wang]

Changeset: 1bf060029a5d
Author:weijun
Date:  2013-06-24 16:25 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1bf060029a5d

8017453: ReplayCache tests fail on multiple platforms
Reviewed-by: xuelei

! test/sun/security/krb5/auto/ReplayCacheExpunge.java
! test/sun/security/krb5/auto/ReplayCacheTestProc.java

hg: jdk8/tl/jdk: 8001326: Improve Kerberos caching

[weijun . wang]

Changeset: 4503e04141f7
Author:weijun
Date:  2013-06-21 18:26 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4503e04141f7

8001326: Improve Kerberos caching
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/KrbApRep.java
! src/share/classes/sun/security/krb5/KrbApReq.java
+ src/share/classes/sun/security/krb5/internal/ReplayCache.java
+ src/share/classes/sun/security/krb5/internal/rcache/AuthList.java
! src/share/classes/sun/security/krb5/internal/rcache/AuthTime.java
+ src/share/classes/sun/security/krb5/internal/rcache/AuthTimeWithHash.java
- src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
+ src/share/classes/sun/security/krb5/internal/rcache/DflCache.java
+ src/share/classes/sun/security/krb5/internal/rcache/MemoryCache.java
- src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
+ test/java/security/testlibrary/Proc.java
! test/sun/security/krb5/auto/AcceptorSubKey.java
+ test/sun/security/krb5/auto/BasicProc.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/NoneReplayCacheTest.java
- test/sun/security/krb5/auto/ReplayCache.java
+ test/sun/security/krb5/auto/ReplayCacheExpunge.java
+ test/sun/security/krb5/auto/ReplayCachePrecise.java
+ test/sun/security/krb5/auto/ReplayCacheTest.java
+ test/sun/security/krb5/auto/ReplayCacheTestProc.java
! test/sun/security/krb5/ccache/EmptyCC.java

hg: jdk8/tl/jdk: 2 new changesets

[weijun . wang]

Changeset: 021fdd093cd9
Author:weijun
Date:  2013-06-13 09:59 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/021fdd093cd9

8014310: JAAS/Krb5LoginModule using des encytypes failure with NPE after 
JDK-8012679
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/OneKDC.java
+ test/sun/security/krb5/auto/OnlyDesLogin.java

Changeset: e9c5ad10fa4b
Author:weijun
Date:  2013-06-13 10:00 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9c5ad10fa4b

8015274: TEST_BUG: Step2: After selecting 'View Warning Log', it is empty 
instead of FileNotFound.
8015276: TEST_BUG: The 'ptool.test' can't be saved in the 'tmp' folder.
8016158: Instruction is not clear on how to use keytool to create JKS store in 
case
Reviewed-by: mullan

! test/sun/security/tools/policytool/Alias.sh
! test/sun/security/tools/policytool/ChangeUI.html
! test/sun/security/tools/policytool/ChangeUI.sh
! test/sun/security/tools/policytool/OpenPolicy.sh
! test/sun/security/tools/policytool/SaveAs.sh
! test/sun/security/tools/policytool/UpdatePermissions.html
! test/sun/security/tools/policytool/UpdatePermissions.sh
! test/sun/security/tools/policytool/UsePolicy.sh
! test/sun/security/tools/policytool/i18n.html
! test/sun/security/tools/policytool/i18n.sh

hg: jdk8/tl/jdk: 8012261: update policytool to support java.net.HttpURLPermission

[weijun . wang]

Changeset: 0f7aaabed25f
Author:weijun
Date:  2013-05-18 10:15 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f7aaabed25f

8012261: update policytool to support java.net.HttpURLPermission
Reviewed-by: mullan

! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/tools/policytool/Resources.java

hg: jdk8/tl/jdk: 8010192: Enable native JGSS provider on Mac

[weijun . wang]

Changeset: 814dcc08df52
Author:weijun
Date:  2013-05-07 12:30 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/814dcc08df52

8010192: Enable native JGSS provider on Mac
Reviewed-by: valeriep

! make/sun/security/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/share/classes/sun/security/jgss/GSSManagerImpl.java
! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
! src/share/native/sun/security/jgss/wrapper/gssapi.h
! test/sun/security/krb5/runNameEquals.sh

hg: jdk8/tl/jdk: 8013855: DigestMD5Client has not checked RealmChoiceCallback value

[weijun . wang]

Changeset: 81be41c7323f
Author:weijun
Date:  2013-05-03 10:43 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81be41c7323f

8013855: DigestMD5Client has not checked RealmChoiceCallback value
Reviewed-by: xuelei, mullan

! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java
+ test/com/sun/security/sasl/digest/AuthRealmChoices.java

hg: jdk8/tl/jdk: 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt

[weijun . wang]

Changeset: ae4a82e69da2
Author:weijun
Date:  2013-05-01 21:05 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae4a82e69da2

8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to 
unencrypt
Reviewed-by: vinnie

! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
+ test/sun/security/krb5/auto/SaslGSS.java

hg: jdk8/tl/jdk: 8005527: [TEST_BUG] console.sh failed Automatically with exit code 1.

[weijun . wang]

Changeset: 22a27dfd0510
Author:weijun
Date:  2013-04-22 11:39 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22a27dfd0510

8005527: [TEST_BUG] console.sh failed Automatically with exit code 1.
Reviewed-by: xuelei

! test/sun/security/tools/keytool/console.sh

hg: jdk8/tl/jdk: 8009636: JARSigner including TimeStamp PolicyID (TSAPolicyID) as defined in RFC3161

[weijun . wang]

Changeset: 778b16225d85
Author:weijun
Date:  2013-04-19 15:41 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/778b16225d85

8009636: JARSigner including TimeStamp PolicyID (TSAPolicyID) as defined in 
RFC3161
Reviewed-by: mullan

! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/timestamp/TSRequest.java
! src/share/classes/sun/security/timestamp/TimestampToken.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/tools/jarsigner/Resources.java
! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/tools/jarsigner/ts.sh

hg: jdk8/tl/jdk: 8011124: Make KerberosTime immutable

[weijun . wang]

Changeset: a3cc4b8e217a
Author:weijun
Date:  2013-04-17 10:15 +0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3cc4b8e217a

8011124: Make KerberosTime immutable
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbAppMessage.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java
! src/share/classes/sun/security/krb5/internal/LastReqEntry.java
! src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java
! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java
! test/sun/security/krb5/MicroTime.java