RFR 8198697: Simplify platform encoding initialization tweak

Roger Riggs Roger.Riggs at Oracle.com
Fri Mar 2 19:21:30 UTC 2018

Hi Claes, Sherman,

Thanks for the reviews:

I reordered as the suggested the checks for encoding type to put utf-8, 
most common first
in JNU_NewStringPlatform() and JNU_GetStringPlatformChars().

Webrev updated in place:

Thanks, Roger

On 3/2/2018 12:03 PM, Xueming Shen wrote:
> +1
> On 03/02/2018 07:49 AM, Roger Riggs wrote:
>> Please review...
>> On 2/28/2018 9:45 AM, Roger Riggs wrote:
>>> Hi,
>>> In an effort to untangle some of the issues with property 
>>> initialization I was looking
>>> at the platform encoding initialization and found a simplification.
>>> Currently, the initialization occurs as a side effect of the first 
>>> call to JNU_NewStringPlatform and
>>> involves a upcall to get sun.jnu.encoding from the system 
>>> properties.  The value is cached for later use.
>>> The native System.initProperties determines the platform specific 
>>> encoding via java_props_md.c and does an upcall to set the 
>>> sun.jnu.encoding system property, taking care to do it before the 
>>> first string that needs platform encoding.
>>> The change directly initializes the platform encoding fast path 
>>> before it is needed to encode platform strings.
>>> And moves the setting sun.jnu.encoding system property after the 
>>> command line arguments are inserted
>>> keeping it from being overridden by -D on the command line that can 
>>> only confuse confusion
>>> with code that later reads the property.
>>> Please review and comment.
>>> webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-simplify-jnu-8198697/
>>> Issue:
>>>    https://bugs.openjdk.java.net/browse/JDK-8198697
>>> Thanks, Roger

More information about the core-libs-dev mailing list