[macosx] "No Java runtime present, requesting install" when creating VM from JNI

[dbarganski]

As described in java JDK-7131356

On some Mac OS machines, if one tries to create Java VM from native executable using JNI, they will get "No Java runtime present, requesting install." message and the program will simply exit. In graphical session, there will be a popup "To open JavaApplication, you need a Java runtime. Would you like to install one now?" "Not now" "Install".

Workaround here: https://github.com/openjdk/jdk/blob/a20c31865d82a71c946d93da30a1e7e8b2970273/test/hotspot/gtest/gtestMain.cpp#L226

Further evidence here: https://github.com/s-u/rJava/issues/37#issuecomment-130458755

My dirty code fix confirmed to solve the bug (w/o error handling and resource free)

// preload libjli
    libname := filepath.Dir(jvmLibPath)+"/../jli/libjli.dylib"
    u := C.CString(libname)
    handle := C.dlopen((*C.char)(u), C.RTLD_NOW|C.RTLD_GLOBAL)
//load jvm
    jnigi.LoadJVMLib(config.jvmLibPath)

[timob]

Nice 🔎, I can't find any documentation on that. Not sure how JNIGI should handle this. Maybe best to mention it in the godoc for CreateJVM. Maybe provide a function that can be called by an app explicitly... not sure.

I will test this out on a Macbook.

[dbarganski]

I've already tested the workaround on macos within jngi context and it works. I can prepare a PR but would prefer first a discussion how to implement it structurally. Problem is widely reported on internet and presents if no system wide java is installed.

Once this is solved, there is another issue with AWT hang on macos which will be a non-trivial solution.

[timob]

I do remember having to mess around with the system wide Java thing on MacOS along time ago. Having JNIGI "just work" on MacOS would be great. So that would mean updating LoadJVMLib in darwin.go. Is that what you were thinking too? I guess my only concern is if there are some corner cases I'm not thinking about, then maybe it should be left up to the app to decide when to load that lib. But I am happy to make changes later if needed.

The AWT problems sounds 👻 scary... I've not used AWT at all with JNIGI but I do use SWT alot, so hopefully I can help with that.

[dbarganski]

I have solved AWT/Swing issue on mac and following days will submit PR.

[dbarganski]

Proposed PR-36

[dbarganski]

@timob : I believe I am hitting a blocking issue with go test.. I will need to execute following come which does not fit at all with tool operational model:

func TestAll(t *testing.T) {
    // Lock main thread (Are we in main thread at all with go test??)
    runtime.LockOSThread()

    go func() {
        PTestInit(t)
        PTestBasic(t)
        PTestObjectArrays(t)
        PTestInstanceOf(t)
        PTestByteArray(t)
        PTestAttach(t)
        PTestGetJVM(t)
        PTestDestroy(t)
        os.Exit(0)
    }()
    // A blocking call which will never return
    RunJVMGUILoop()
    // We should never reach here
}

[timob]

Maybe RumJVMGUILoop code for working with AWT/Swing could be includeded in a sub pacakge, then you could have tests there.

[dbarganski]

I do not see any real way to test this function with go facilities as call itself is a blocking one. Sub package changes nothing in this context. In reality calling subroutine is only needed on macOS and only if you need AWT/Swing. That's an additional functionality that does not affect rest of library in any way. Library libjli preload test is already provided as part of base tests. So I will ask you to accept PR as is since I have no way to provide an automatic test on gui loop.

[timob]

Let's talk over on on the PR: https://github.com/timob/jnigi/pull/36

[timob]

Is this still an issue?

[timob]

Close for now please open new issue if the GUI stuff is still a problem.