RFD: What do we do about programs which set sys_paths to null?

[Anton Kozlov]

Hi,

On 17.03.2020 19:49, Andrew Haley wrote:
> --- a/src/java.base/share/classes/java/lang/ClassLoader.java    Mon Feb 03 09:39:39 2020 +0100
> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java    Tue Mar 17 16:24:10 2020 +0000
> @@ -2562,7 +2562,7 @@
> 
>      // The paths searched for libraries
>      private static String usr_paths[];
> -    private static String sys_paths[];
> +    private static volatile String sys_paths[];
> 
>      private static String[] initializePath(String propName) {
>          String ldPath = System.getProperty(propName, "");
> @@ -2620,6 +2620,10 @@
>                              boolean isAbsolute) {
>          ClassLoader loader =
>              (fromClass == null) ? null : fromClass.getClassLoader();
> +        if (sys_paths == null) {
> +            usr_paths = initializePath("java.library.path");
> +            sys_paths = initializePath("sun.boot.library.path");
> +        }
>          assert sys_paths != null : "should be initialized at this point";
>          assert usr_paths != null : "should be initialized at this point";

The patch looks good to me

> I think we should do this for 8u and 11u. My justification is that even
> though this is an ugly hack, it satisfies a real need and we don't want
> to break users' programs in an update.

Agree

> I do not believe that this introduces a race when the user sets
> sys_paths to null because
> 
>    setProperty("java.library.path") happens before (write volatile sys_paths)  (Program order)
>    (write volatile sys_paths) synchronizes with (read volatile sys_paths)
>    (read volatile sys_paths) happens before getProperty("java.lbrary.path") (Program order)
> 

It's also worth to mention that usr_paths is never null. And once a thread re-initialized 
sys_paths and another thread sees new sys_paths, the another thread will see updated usr_paths
by the same reasoning with s/setProperty()/usr_paths = .../. So everything is good.

Thanks for addressing this!
-- Anton