RFR: jsr166 openjdk9 integration

Martin Buchholz martinrb at google.com
Wed Sep 23 22:22:11 UTC 2015


On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On 23 Sep 2015, at 21:33, Martin Buchholz <martinrb at google.com> wrote:
>
>
>>
>> In Helpers:
>>
>>  121     private static String newStringUnsafe(char[] chars) {
>>  122         // If porting to a JDK where sun.misc.SharedSecrets is not
>>  123         // available, modify the code below to simply:
>>  124         // return new String(chars);
>>  125         // TODO: Can we do this more portably?
>>  126         return
>> sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>>  127     }
>>
>> Yes, you can do this more portably *and* safely by not using it! :-)
>>
>> Do we really really need to use SharedSecrets? IMO this unsafe dependency
>> should be removed in the JDK patch.
>
>
> Of course, this is "just" a (relatively unimportant) performance
> optimization.
>
>
> Keeping focus, i think the first question to be asked is whether for a
> particular use-case unsafe String construction is really necessary, and in
> this case i strongly suspect the answer is no.
>
>
We're maintaining a low-level library, with great attention to
performance.  You never know if there's a user who's printing/logging bound.

Anyways, you feel  strongly about this, so ... they're gone!  Webrevs
updated.



More information about the core-libs-dev mailing list