RFR: Export InitializeEncoding for JVM access

[Roger Riggs]

Hi Andrew,

ok,  it turns out the prototype in jni_util.h also needs to be updated 
to be consistent for Windows and Solaris.
And no surprise, there are no test failures.

I put an updated webrev in:
   http://cr.openjdk.java.net/~rriggs/webrev-encoding-8201246/

If there are no more comments, I'll commit tomorrow.

Regards, Roger


On 4/9/2018 8:57 AM, Andrew Leonard wrote:
> Thanks for the feedback Roger,
> Yes, exporting the InitializeEncoding entry point would make sense, 
> keeping it consistent with Canonicalize(). I have attached the new 
> patch below:
> Many thanks
> Andrew
>
>
> diff --git a/src/java.base/share/native/libjava/jni_util.c 
> b/src/java.base/share/native/libjava/jni_util.c
> --- a/src/java.base/share/native/libjava/jni_util.c
> +++ b/src/java.base/share/native/libjava/jni_util.c
> @@ -774,8 +774,10 @@
>  return newSizedStringJava(env, str, len);
>  }
>
> -/* Initialize the fast encoding from the encoding name. */
> -void
> +/* Initialize the fast encoding from the encoding name.
> + * Export InitializeEncoding so that the VM can initialize it if 
> required.
> + */
> +JNIEXPORT void
>  InitializeEncoding(JNIEnv *env, const char *encname)
>  {
>  jclass strClazz = NULL;
>
>
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From: Roger Riggs <Roger.Riggs at Oracle.com>
> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 06/04/2018 15:39
> Subject: Re: RFR: Export InitializeEncoding for JVM access
> ------------------------------------------------------------------------
>
>
>
> Hi Andrew,
>
> Would it be sufficient to export the InitializeEncoding entry point?
>
> Introducing a JNU_xx name may imply a level of support that is 
> unwarranted since
> it is part of system initialization and may change as needed by the 
> implementation.
> Simply exporting it would put it on par with Canonicalize.
>
> Thanks, Roger
>
> p.s. Tracking issue: 
> _https://bugs.openjdk.java.net/browse/JDK-8201246_ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201246&d=DwMD-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=p_fQLlNXJvoVJa69tdD-jWziIgb70BegiqN-SuPhUPk&s=Jvw6DlMaepuFnlUKt1l04hqhMaetcEE4PwHYD_9pnrE&e=>
>
> On 4/5/2018 5:49 AM, Andrew Leonard wrote:
> Hi Roger,
> The OpenJ9 VM implementation provides its own java.lang.System, which 
> performs similar type early-on VM initialization to the OpenJDK core 
> library classes. The basic reason for invoking the method is to 
> initialize the platform encoding either called from a related core 
> library method, eg.initProperties(), or from the VM in the early 
> stages of initialization.
>
> My suggested comparison with canonicalize was based on it's indicated 
> usage:
> /*
>  * Export the platform dependent path canonicalization so that
>  * VM can find it when loading system classes.
>  * This function is also used by the instrumentation agent.
>  */
> extern int canonicalize(char *path, const char *out, int len);
>
> JNIEXPORT int
> Canonicalize(JNIEnv *unused, char *orig, char *out, int len)
> {
>     /* canonicalize an already natived path */
>     return canonicalize(orig, out, len);
> }
>
>
> Many thanks,
> Andrew
>
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: _andrew_m_leonard at uk.ibm.com_ 
> <mailto:andrew_m_leonard at uk.ibm.com>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU