Some issues while switching from jbullet to native bullet

By the change log and by this post, jbullet is going to be dropped (in favor of native bullet) right? As I also found no jbullet.jar at jme3.1-beta1 zip file (that is a requirement for jme3-jbullet.jar that is still there), and I ended grabbing it from here: jmonkeyengine/lib at master · jMonkeyEngine/jmonkeyengine · GitHub, and my project works with that.

But trying to switch to native bullet, I can’t overcome this exception:

java.lang.NoClassDefFoundError: com/bulletphysics/collision/dispatch/CollisionObject
at com.jme3.bullet.BulletAppState.startPhysics(BulletAppState.java:164)
at com.jme3.bullet.BulletAppState.stateAttached(BulletAppState.java:211)
at com.jme3.app.state.AppStateManager.attach(AppStateManager.java:133)

The “class” expected is actually found at jbullet.jar, but (of course right?) I cannot use it…
I am on linux using eclipse. I set the jme3-bullet.jar native to point to where libbulletjme.so can be found, and this configuration is accepted as these 3 files are automatically copied to the path of my project: libbulletjme.so, liblwjgl64.so, libopenal64.so.
But, the expection still happens; I tried copying libbulletjme.so in many folders but it didnt help, and yes I unpacked the 64 bits one.

Now I am puzzled, any tip?

PS.: @pspeed I was looking for jme3.1-beta1 thread at development section…

EDIT: seems related to this thread: What jars are needed to use Bullet (either native or JBullet) with alpha 3? - #7 by Momoko_Fan

Fixed. It’s sad that the forum doesn’t make a poster pick a category… it’s easy to forget in the midst of 40 other things to get a release out.

1 Like

To switch to native bullet, you need to remove jme3-jbullet.jar from the classpath and then add jme3-bullet.jar. You cannot have both of them in the classpath because they have classes with the same names.

[read here 1st]

I had done that and it did not work.
Java seems to “try to help us” more than we may want…
But I found the solution!

For anyone else having this kind of problem, not being able to use the native bullet for example:

The problem is quite simple, jars not specified with -classpath are being found and loaded!!!

First of all, add this to your JVM run/debug argument -verbose:class.
That promptly showed here that jme3-jbullet.jar was being loaded despite not present at the -classpath parameter !!!

That was the reason it was throwing that ununderstandable exception here, because that jar was requesting for jbullet.jar that I had physically removed/deleted.

Add this code Thread.currentThread().getContextClassLoader() and read thru the returned object, it will show not required jars that got loaded and a lot of more interesting info.

LINUX only:

Well, continuing… so, I am using Linux, and it allows for symlinks.

It is clear that symlinks are getting resolved to their canonical real absolute file path.
So a symlink like:
/selectedLibs/jme3-bullet.jar -> /fullLibsStorage/jme3-bullet.jar
was being resolved to
/fullLibsStorage/jme3-bullet.jar,
and all jars at /fullLibsStorage/ (and also recursively because jars on sub-dirs were being loaded too) were being added even if not specified at -classpath !!!

To exemplify:

cd "/home/$USER/temp/tstjava"

There is the compiled class for this source code here: ./tests/BulletTest.java
java -verbose:class -classpath ./:jME3.1-beta1/jMonkeyEngine3.jar tests.BulletTest

The file jme3-jbullet.jar was present at ./jME3.1-beta1/lib/ but not specified at the -classpath above!

This unwanted jar showed at the console output:
[Loaded com.jme3.bullet.PhysicsSpace from file:/home/$USER/temp/tstjava/jME3.1-beta1/lib/jme3-jbullet.jar]

!!!

Final tip:

Make it sure to physically remove non required or conflicting jars.
Alternatively their extension can be simply renamed.

PS.: could this be some configuration at my environment, or for Linux, that allows/requests for searching for jars not specified with -classpath? or is this behavior widely spread, happening also at Windows and Mac?

Useful link: http://stackoverflow.com/questions/2548384/java-get-a-list-of-all-classes-loaded-in-the-jvm

Which -classpath? The one you pass to your app or something provided by the SDK?

Note: jars can have a classpath in their manifest. I think this is only done for apps built by the SDK, though. The JME libs shouldn’t have it themselves.

The classpath I use to run my app, I actually ran several tests on the command line, outside of eclipse and outside of my project, to have a thin test case that resulted in this line java -verbose:class -classpath ./:jME3.1-beta1/jMonkeyEngine3.jar tests.BulletTest.

so, my assumptions were incorrect as jMonkeyEngine3.jar has a manifest clearly pointing to lib/jme3-jbullet.jar? :scream:

Some of the tests use physics hence they need to reference jme3-jbullet as a dependency. However if we decided to use native bullet as the primary implementation for physics we should probably switch the examples project to use it…

1 Like

Yeah… I thought you were running your own app. Instead you were running an app built to work with the non-native version of bullet.

As momoko says, we should probably change that. Still, it has nothing to do with a real user app as that would use whatever dependency you selected for your project.

I actually had this problem on my own project.

Yes, my project was using jbullet because long ago I had the same problem but didnt try to understand why that was happening, I just needed to implement things fast and jbullet was readily working.

I created that small test just to narrow the source of the problem and try to fix it.

If is that what you meant of course :slight_smile:

Well, we didn’t see that. I only saw you trying to run the JME test jar: jMonkeyEngine3.jar… which is built to run against jbullet I guess.

If your own SDK-based app was referring to the other bullet jars then it would have been built with the proper classpath and this wouldn’t have been an issue. Maybe other issues, but not this one.

Oh, no no, I created my class and named it BulletTest, I ran that test from the command line terminal on linux.
jMonkeyEngine3.jar is the vanilla from the zip package of beta1, that I also use on my project on eclipse.

I was thinking, why dont you just strip off all these manifest “hidden” packages dependencies and let us deal with it? :slight_smile: May be, create a tiny almost empty package just to store these dependencies for the JME tests, call it like JMonkeyTestsDeps.jar.

I dont get it, you mean the jMonkeyEngine3.jar manifest would be modified to not contain jme3-jbullet.jar? The beta1 zip package only have that file, with that manifest, at its base path.

So, I use eclipse to manage my project that I created a long time ago, may be I could try to create a new project just to see how the SDK configures it relatively to native bullet, sounds interesting.

jMonkeyEngine3.jar is the test launcher app. If you are not launching the test launcher then you shouldn’t be using that jar. If you are running your own app… then you shouldn’t be trying to use the test launcher jar. That could be the source of all of your issues.

When one makes an executable jar (which the test launcher jar is), one generally wants to include a relative classpath reference to the jars it will need to avoid having a 9000 character long command line in some script somewhere. It’s just easier for everyone trying to run it.

The SDK will do this for your own apps. (Or it used to at least.) And in that case, it includes only the jars that are dependencies of your project.

So my guess is that you were using the test launcher jar to run your app. Which is wrong. Don’t do that.

1 Like

oh! uh…, never checked that!!! the name is so clear and whole “jMonkeyEngine3”.jar that I saw it as the corest of the core jars, thx on explaining that. For what you described, I was expecting see the word “test” on it like jMonkeyEngine3Tests.jar

But indeed, lib folder is for libs…, outside of it is not libs of course…

Problem solved indeed! thx!

Yeah, it’s not obvious… and I guess us ‘grey beards’ sometimes forget that file is even there.