RFR 8198697: Simplify platform encoding initialization tweak

[Claes Redestad]

Hi,

looks good to me, although part of me can't help wonder if we'd profit 
ever so little from rearranging if statements so that we test for UTF8 
first and move the should-be-asserts tests for NO_ENCODING_YET down.

/Claes

On 2018-02-28 15:45, 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
>
>
>
>