Initialization timing issue for static variable

[KyongSik-Yoon]

currentPlatform variable initialized in static block of this class.
But it's also accessed via constructor for validate unsupported environment.
This variable possible not initialized yet when access make a instance use constructor.
I'm already met this kind of issue when I run unit test use this library.
I think one more variable init checking required, at least If constructor want to check unsupported or not.

[coveralls]

Coverage remained the same at 85.764% when pulling 3bb54b7 on KyongSik-Yoon:master into 7364882 on oshi:master.

[dbwiddis]

It is my understanding that the order of operations in Java executes static variable initialization first (in source code order) followed by instance variable initialization, and only after that, the constructor. So I don't see where there's a problem with the existing code.

Your change introduces lazy instantiation which is known to be not thread safe, so the suggestion as-is makes things worse. If lazy instantiation were needed using the Memoizer class would be preferred.

But I don't see a need to do that for a static final variable. Am I mistaken?

[KyongSik-Yoon]

@dbwiddis It's occured only our CI process in gitlab.
When I run single unit test. There is no problem.
If possible I will take thread dump in this case.

I'm using 5.2.3 version. And this problem appeared after upgrade to latest version.
In this situation error message displayed like below.
Operating system not supported: JNA Platform type
When I logging getCurrentPlatform() result is UNKNOWN.
A difference with 5.2.3 and lastest version is checking for unsupported platform in consturctor.
So I assumed invalid state of currentPlatform variable.

[mprins]

Odd problem, can you show us your code?

The JNA stuff is pure java and according to the java spec any acces to a static class member will be preceded by execution of the static initializers unless a class instance has aready been created in which case the static initilizers are executed before the constructor.
So I think the existing code is correct.

[dbwiddis]

The error message "Operating system not supported: JNA Platform type" should have been followed by a number.

The currentPlatform value you note was returned as UNKNOWN is a final variable and cannot change. So it was initialized once as UNKNOWN based entirely on calls to JNA's Platform class. The result is based on static final variables in that class as well.

Please check that you have the latest version of JNA (and JNA-platform) as a dependency, although that shouldn't matter here If you are using a supported operating system, then the bug is in JNA properly identifying it, which it does with JVM properties. Can you answer a few more questions:

• What number is reported in the exception after "JNA Platform type [this value]"
• What operating system are you using?
• What JDK are you using (vendor and version)?
• What is the contents of System.getProperty("os.name") ?

[KyongSik-Yoon]

@dbwiddis What number is reported in the exception after "JNA Platform type [this value]"
==> Mesage was displayed with number 2. At that time currentPlatform is UNKNOWN

What operating system are you using?
==> Windows 10

What JDK are you using (vendor and version)?
==> openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

What is the contents of System.getProperty("os.name") ?
==> "Windows 10"

[KyongSik-Yoon]

@mprins Here is my code.

class StorageOnSystemSpec : FunSpec({
    test("display as string") {
        println(StorageOnSystem(SystemInfo()).diskAndPartition())
    }
})

Error occured when call a constructor SystemInfo()

[dbwiddis]

displayed with number 2. At that time currentPlatform is UNKNOWN

Well, this is very interesting because 2 is indeed Windows.

From JNA's Platform class (as expected):

    public static final int WINDOWS = 2;

    private static final int osType;

    static {
        String osName = System.getProperty("os.name");
        if (osName.startsWith("Linux")) {
    ...
        }
        else if (osName.startsWith("Windows")) {
            osType = WINDOWS;
        }

and

    public static final boolean isWindows() {
        return osType == WINDOWS || osType == WINDOWSCE;
    }

called by OSHI

    private static final PlatformEnum currentPlatform;

    static {
        if (Platform.isWindows()) {
            currentPlatform = WINDOWS;
        } else if (Platform.isLinux()) {
    ...
    }

So the Platform.isWindows() call is apparently returning false during OSHI initialization, but would be true if called later.

It looks like you're calling this from Kotlin code. I wonder if there's some subtle difference there.

I'm baffled as to how this can occur.

[dbwiddis]

Could you point us to the CI log for the case where this is failing?

[dbwiddis]

This StackOverflow post may be related. Or not.

[dbwiddis]

It has been suggested that using a static method rather than a static initialization block may fix this.

Please update this PR to do something like:

private static final PlatformEnum currentPlatform = queryCurrentPlatform();

and then define

private static PlatformEnum queryCurrentPlatform() {
   // code from the static initialization block, but return instead of setting variable value
}

[KyongSik-Yoon]

ok, I will do that.

[KyongSik-Yoon]

I updated this PR.
I will comment whether it is effect to me or not.

[dbwiddis]

Thanks! I went ahead and merged this. It should be in SNAPSHOT shortly to aid your testing. I may tweak the class ordering later (to move the method below the constructor) but that shouldn't change the behavior.