Re: RFR: 8272805: Avoid looking up standard charsets

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

Re: RFR: 8272805: Avoid looking up standard charsets

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

Re: RFR: 8272805: Avoid looking up standard charsets

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

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

2021-08-22 Thread Sergey Bylokhov
> 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.StandardCharse

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

2021-08-22 Thread Naoto Sato
On Sun, 22 Aug 2021 23:02:06 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 t

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-22 Thread Jaikiran Pai
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-22 Thread Jaikiran Pai
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-22 Thread David Holmes
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-22 Thread Alan Bateman
On 23/08/2021 05:45, David Holmes wrote: : @wangweij there are many tests that can call setSecurityManager() and will presumably need to be fixed before this switch can be applied. And all testing will need to be updated to require jtreg 6.1 (which no longer uses the SM) once it is released.

System.exit(...) without SecurityManager - implications for Apache Ant project

2021-08-22 Thread Jaikiran Pai
(resending from the correct subscribed email address) I see that System.setSecurityManager(...) will start throwing exception by default starting Java 18[1]. I have been following the JEP 411, mostly in context of the Apache Ant project. I think we (Ant) are in a OK shape for Java 17 when it c