On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz <paul.san...@oracle.com> wrote:
> On 23 Sep 2015, at 21:33, Martin Buchholz <marti...@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.
