KNETCore fails to locate "libjvm.so" on *NIX based systems

[JeetCXX]

Describe the bug
KNETCore::CreateGlobalInstance() fails to locate the JVM on LINUX and other *NIX based systems.

To Reproduce

1. Set the JAVA_HOME environmental variable.
2. Invoke "KNetCore.CreateGlobalInstance()" from your code
3. Exception is thrown: jvm.so not found

Expected behavior
"KNetCore.CreateGlobalInstance()" should locate the JVM dynamic library (libjvm.so) correctly after browsing the entire folder structure. Currently, it only looks under $JAVA_HOME/bin/server. Also, the file to look for is libjvm.so and not jvm.so.

Works fine on WINDOWS with a standard OPENJDK installation and correctly set JAVA_HOME environment variable.

A possible workaround: Set a symbolic link under $JAVA_HOME/bin to $JAVA_HOME/lib/server/libjvm.so. Name the link as server/jvm.so.
Should be fine for DEV machines.

Screenshots
Not applicable.

Desktop (please complete the following information):

• OS: [e.g. iOS]: Red Hat Enterprise LINUX
• Version [e.g. 22]: 9

Additional context
See email to Support.

[masesdevelopers]

@JeetCXX On *nix systems: JCOBridge try to find an incorrect library name and location if JAVA_HOME points out to the JRE folder, this is an open issue. The common way of work is to use the command-line switch JVMPath. JCOBridge has multiple command-line switches and one of them is dedicated to set the JVM library location. Use JVMPath in any shell (Windows, bash, etc) to set-up the JVM library location:

--JVMPath:<full-path-to jvm.dll or libjvm.so>

other options under https://www.jcobridge.com/net-examples/command-line-options/.

If the developer/user cannot use the command-line switch, another way to overcome this behavior is to override the property JVMPath with a snippet like the following:

    class MyKNetCore : KNetCore
    {
        public override string JVMPath
        {
            get
            {
                string pathToJVM = "Set here the path to JVM library or use your own search method";
                return pathToJVM;
            }
        }
    }

#110 will cover an enhancement about usage and environment set-up.

[JeetCXX]

I think I will use the symbolic link for now, because it does not require the C# developer using KNet to bother about JAVA infrastructure details. Of course, this is a matter of individual developer preference.

Thanks.

[masesdevelopers]

We delayed an answer due to JCOBridge porting finalization after official release of .NET 7.
The open issue related to *nix library load will be covered partially with JCOBridge 2.5.0, anyway still remain open the point related to path discovery. There is also a thread in https://stackoverflow.com/questions/6493856/how-to-programatically-get-all-java-jvm-installed-not-default-one-using-java which discuss this topic.

If you look at Dockerfile, KNet deploys a container which has everything it needs to run. The predefined ENTRYPOINT starts the KNet CLI, but you can override the container behavior with any program which use KNet.