I have a question related to Minie & bulletjme.dll
I can see that upon startup bulletjme.dll is automatically created and I know that it is done by Minie lib.
Yesterday a student of mine with a Win64 OS and Java 32 installation had a problem - bulletjme.dll was not created upon startup. When we rolled back to a previous versions of my product with earlier version of Minie it worked fine.
So I believe that something regarding the extraction of bulletjme.dll has changed in the last version of Minie.
What do you think? The student didn’t want to change the Java installation to 64Bit so it’s kind of a weird setup but the fact is it worked with prev. Minie but not with the new version.
Should I consider it a limitation and state that Win64 OS with Java 32bit is not supported?
Extraction of native libraries is performed by jMonkeyEngine. It’s something Minie has little or no control over. On desktop systems, the NativeLibraryLoader in jme3-desktop does most of the work.
There are several conditions that could prevent the native library ('bulletjme.dll" on Windows) being written to the working folder. For instance, if there’s already a file “bulletjme.dll” in the working folder, and its last-modified date is recent enough, JME might load the existing file instead of extracting a new copy. And if the working folder is unwritable, JME should instead extract the library to “AppData\Local\jme3\bulletjme.dll” under the user’s home folder.
So before concluding that the version of Minie makes a difference, please test both versions in a clean, writable folder.
NativeLibraryLoader chooses between the 32-bit and 64-bit versions of the native library based on the value of System.getProperty("os.arch"). I haven’t tested a 32-bit JVM running on 64-bit Windows. If NativeLibraryLoader extracts the wrong version of “bulletjme.dll”, System.load() might report “No such file” even though the file exists in the working folder.
So, if the NativeLibraryLoader uses “os.arch” a 64bit version of bulletjme.dll will be extracted and JVM32 will not be able to run the application. I think this is the case. As for the bulletjme.dll not being extracted , I will try to test it and report back.
What made me think its related to Minie is that while upgrading to the latest jme-vehicles I had to also upgrade to the latest Minie + Heart libs. I didn’t change any of the other JME libs.
I will test & report
just wanted to add something related here, which occured to me just a day ago:
I tried to add the latest Minie + Heart to a fresh JME SDK 3.3.2 project and always got this: Exception in thread "jME3 Main" java.lang.UnsatisfiedLinkError: 'long com.jme3.bullet.PhysicsSpace.createPhysicsSpace(float, float, float, float, float, float, int)'
So the DLL wasn’t loaded and linked. After following this thread I then tried to load the Bullet DLL manually using NativeLibraryLoader.loadNativeLibrary( "bulletjme", true );
But that resulted in this: java.lang.UnsupportedOperationException: JVM is running under reduced permissions. Cannot load native libraries.
After inspecting the source of that function I found out that it doesn’t load anything because JmeSystem.isLowPermissions() always returns true. I then tried to run the SDK (and the JVM) in admin mode (running Windows 10 64-bit), disabling my anti virus, manually extracting or removing the dll file, but nothing worked. The project was always running on low permissions.
The solution for me then was just to call this manually: System.load( System.getProperty( "user.dir" ) + "/bulletjme.dll" );
Well I think it should be a normal desktop application. I checked every Properties page but there is nothing hinting at other platforms.
For now I’m sticking to the mentioned System.load( ... ) solution.
OK so I found something. For some (stupid?) reason I was calling JmeSystem.setLowPermissions( true ) at the top of my main function before starting the app. If I remove that line I get this (which was the reason I set low permissions in the first place):
Exception in thread "jME3 Main" java.io.UncheckedIOException: Failed to extract native library to: E:\ ... \Game\lwjgl64.dll
This happened to me after grabbing the source from git instead of downloading manually jars I had to put it where minie would find it, it didn’t automatically extract this has not happen the previous time I polled from git also assets that the DAC test reference don’t appear to be downloaded, this one I have seen before then got fixed, then happened again, TestDac crashes due to missing assets, didn’t kick a fuss because I know the test did previously
just some info to say that this is not an uncommon occurrence…not inserting myself
When rolling back to older versions of Minie, you may encounter bugs that were fixed in later versions. Documented bugs that affect vehicles include issue 13 (fixed in v3.1.0) and issue 14 (fixed in v4.0.0).
As the release numbering suggests, there was a breaking API change in Minie between v3.1.0 and v4.0.0. However, it was in a seldom-used part of the library, so it shouldn’t affect your application.