[SOLVED] Running Examples from command line (Gradle) - missing bulletjme

I’ve been trying to make sure that JME is working as expected on my system (Arch Linux - VirtualBox guest on a Windows 10 host - tried with multiple different jdks)

using gradle run will get me the test selector (yay!) and selecting a test will pop the resolution/graphics settings splash (when the test uses it)

However, when selecting continue on any test that requires bullet, I get:

java.lang.UnsatisfiedLinkError: The required native library 'bulletjme' was not found in the classpath via 'native/linux/x86_64/libbulletjme.so'. Error message: no bulletjme in java.library.path

this, even though at the beginning of the gradle run, it claims:

Use natives snapshot: https://dl.bintray.com/jmonkeyengine/files/a4c694ba36258af5c6ce7823f4bdacc424988557/jme3-natives.zip

I’ve checked, and that URL is legitimate. (I can download with a browser, and it has the correct .so included)

Any idea why the gradle scripts are not making sure the correct library is on the path?

1 Like

i were using JME Tests via SDK (Ant not Gradle), but gradle should run fine too i think. Or you mean wiki examples?

do you use(it have) in gradle build file both wrapper lib and physics lib?

for example:

compile "org.jmonkeyengine:jme3-bullet:$jmeVersion

this is wrapper lib, but it still require “implementation lib” like:

compile "org.jmonkeyengine:jme3-bullet-native:$jmeVersion (or java version jBullet that is outdated)

im not sure how gradle JME Tests Project build work(i thought its only Ant), because i use Ant JME Tests, but using gradle Project for game and im sure it need “both bullet wrapper + native/implementation lib” to work.

For me libbulletjme.so were working on Ubuntu, Windows 8.1 and Centos 8 without issues(if builded properly). so i dont think it’s system related.

I would also suggest you to “clean and build” project - it might help too.

What about:
gradlew run

…note the ‘w’

Same error (and prequel message). This was with a “clean” before the “run,” just in case.

BTW, gradlew downloads a fairly old version of gradle (4.1, whereas my current system version is 5.6!)

I’m actually talking about running the jmonkeyengine repository build, not my own project. Not a big fan of SDKs in general, they seem to tend to do “magic” under the surface that I then have to reverse-engineer for my own, independent builds.

Yes, because as I recall some of our native build stuff only works with the older gradle… which is why it’s important to run with gradlew.

For example, last time I did gradle run in the jme directory it didn’t work for me either… but gradlew run does.

Well, in either case, I cannot build native either. I’ve tried to force the bullet Linux shared library target, and the builds fail, complaining that it can’t find jni.h

File definitely exists, I even went as far as hard-coding the location in jme3-bullet-natives/build.gradle instead of relying on the auto- detection. Still claims it does not exist. Wierd.

If the Gradle builds don’t work, how is the engine built for release?

Because the gradle builds work when we make releases?


complaining that it can’t find jni.h

Based on my experience(Using Centos 7), some OpenJDK builds had broken link to jni.h that required /include before it(or remove it, i dont remember now). Anyway it might be system related.

Have you tried run ANY OTHER JNI based app?

Fair enough. I was a bit frustrated when I wrote that. Back to trying to figure out why it’s not working for me

…on second thought, I think that the java build portions are working for me. Just, not the natives/connecting to the binaries to run examples.

1 Like

A possible workaround: edit jme3-examples/build.gradle to use JBullet instead of native Bullet:

    // EITHER use jme3-bullet + jme3-bullet-native OR ELSE jme3-jbullet
//    compile project(':jme3-bullet')
//    compile project(':jme3-bullet-native')
    compile project(':jme3-jbullet')

I’ve reproduced the reported issue using Windows 7, master-branch JME, and gradlew.

I believe it is related to recent changes in the master branch. After I rolled my repo back to 9 October (hash=b1db497a0027ae7f142be5c5f2852539196a1d70) I was able to run physics examples from TestChooser just fine.

I opened an issue at GitHub:
no bulletjme in java.library.path · Issue #1208 · jMonkeyEngine/jmonkeyengine · GitHub

@RiccardoBlb please investigate.


It should be fixed now. Pull the master and try

gradle build #this will download the prebuilt natives 
gradle run

Gradle or Gradlew or any?

It should work with both.

Thank you very much! I appreciate the response.

The downloaded natives seem to work fine now.

(I didn’t get a chance to try @sgold’s workaround - fix had been posted before I had some time to work on programming stuff. I do appreciate the effort, though!)

I’m running into other issues that seem to be more OS/virtualbox related. Maybe time to switch to VMWare? Really did not want to have to re-build my dev setup from scratch.

It’s usually not a good idea to develop opengl code with a virtual gpu. So, unless you can do gpu passthrough, you should probably avoid VMs.

1 Like