Minie - bulletjme.dll issue

Hello Stephen,
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

1 Like

I was pretty sure that os.arch is supposed to give architecture of the JRE and not the OS.

Googling seems to agree with me though there are mixed responses.

You should look and see what it actually is for that JRE.

java -XshowSettings:properties

I have my doubts, re: the googling because mine says “amd64” and I don’t know how that could be anything other than the OS. So this could have changed over time maybe.


So maybe we should find a more reliable way to detect the JRE architecture… I found this:

public static final boolean is64Bit() {
    String model = System.getProperty("",
    if (model != null) {
        return "64".equals(model);
    if ("x86-64".equals(ARCH)
        || "ia64".equals(ARCH)
        || "ppc64".equals(ARCH) || "ppc64le".equals(ARCH)
        || "sparcv9".equals(ARCH)
        || "mips64".equals(ARCH) || "mips64el".equals(ARCH)
        || "amd64".equals(ARCH)
        || "aarch64".equals(ARCH)) {
        return true;
    return Native.POINTER_SIZE == 8;

where ARCH is fetched from the os.arch

ARCH = getCanonicalArchitecture(System.getProperty("os.arch"), osType);
1 Like


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" );

Hope this helps someone.


That’s weird because on desktop it should always be returning false. Only Android, IOS, and Java applets seems to set that to true.

Is your application a JME desktop application?

1 Like

Thanks for the hint!

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" Failed to extract native library to: E:\ ... \Game\lwjgl64.dll

Caused by: E:\ ... \Game\lwjgl64.dll

It’s telling me the process can not access the file because it is used by another process or something (freely translated from the German error message).

So yeah there is something blocking the files, I’m going to check my anti virus, dropbox, or other suspicious processes…


It happened again on a new student’s machine. I’ll talk with the operators and try to collect all the data we can in order to understand why it didn’t find the bulletjme.dll

1 Like


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

1 Like

will previous versions of Minie & Heart will work with the current version of jme-vehicles lib? Rolling back to jayfella’s version is not an option for me…

1 Like

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.

For a summary of the changes in each version, see Minie’s release log.

Short answer: yes!

Edit: I’ve successfully built and run the latest jme-vehicles with Minie v1.7.0.

1 Like