If you want to spend your life in reinventing the wheel, I won’t waste mine to convince you not to do so.
Why not contacting the contributors of LibGDX? Why not asking them to extract the math and their bullet binding into a separate sub-project?
It seems to me that you lack of knowledge about the current Java ecosystem.
In the reality, it’s not so simple, especially with Bullet 3 and I read somewhere that Bullet 2 already offloads a bit some computations on the GPU but I’ve never checked in the source code if it’s really the case.
It doesn’t make sense because you can’t write that you don’t want to bloat your classpath with useless classes and that you accept using 2 math libraries, it’s not logical. Secondly, do you realize that the source code of Bullet is quite big? Do you really imagine that numerous developers would modify entirely an API in order to use the same math library?
Maybe it would be better to make the right choice now.
Why not posting a poll here before launching a crowd-funding campaign?
Finally, can you explain to us (without using your favourite search engine) what mean “tunneling”, “continuous collision detection”, “discrete collision detection”, “sweep and prune”, “broad phase”, “multisampling” (in the context of physics), “soft body”, “framerate independence”, “joint”, “Minkowski addition”, “contact”, “Gilbert-Johnson-Keerthi”, “Expanding Polytope Algorithm” and “Voronoi Simplex Solver”? If you can’t, please don’t even plan to make a pure Java port of Bullet 3.