[rfc] Deprecate jme3-jbullet

[8Keep]

Open for discussion whether this is a good idea.

[gemini-code-assist]

Code Review

This pull request deprecates the jme3-jbullet module by adding @deprecated annotations to its classes, interfaces, and methods. The reviewer suggests including the @deprecated Javadoc tag to provide users with a clear reason for the deprecation and a recommended migration path to the jme3-bullet module.

[gemini-code-assist]

When using the @deprecated annotation, it is best practice to also include the @deprecated Javadoc tag. This allows you to explain the reason for deprecation and suggest a migration path (e.g., switching to the jme3-bullet module). This is recommended by common Java style guides such as the Google Java Style Guide.

 * @deprecated use the jme3-bullet module instead.
 */
@Deprecated

References

1. A class or member that is deprecated is annotated with the @deprecated annotation and its Javadoc must include the @deprecated tag. ^(link)
2. When identifying missing or incorrect Javadoc, provide a code suggestion to fix it directly.

[gemini-code-assist]

For method-level deprecation, providing a reason and an alternative in the Javadoc is particularly helpful for users to understand how to update their code, especially when the method signature involves external library types like javax.vecmath.

     * @deprecated use jme3-bullet instead.
     */
    @Deprecated

References

1. A class or member that is deprecated is annotated with the @deprecated annotation and its Javadoc must include the @deprecated tag. ^(link)
2. When identifying missing or incorrect Javadoc, provide a code suggestion to fix it directly.

[gemini-code-assist]

Consistent with other classes in this module, please add the @deprecated Javadoc tag to provide clear instructions to users encountering this deprecation.

 * @deprecated use jme3-bullet instead.
 */
@Deprecated

References

1. A class or member that is deprecated is annotated with the @deprecated annotation and its Javadoc must include the @deprecated tag. ^(link)
2. When identifying missing or incorrect Javadoc, provide a code suggestion to fix it directly.

[stephengold]

I have no objection.

When I proposed this in the past, I was told that a game engine without physics simulation wasn't much of a game engine. If you like, I can search for the exact comment.

[riccardobl]

we need a replacement

[8Keep]

I don't know the history because I've been out for a few years.

Would we want to support Minie and/or jme-jolt as the supported physics library for the engine? I'm glad the old native bullet is already gone, and I don't think there's any good reason to use jbullet, so I know I would support this.

[stephengold]

Would we want to support Minie and/or jme-jolt as the supported physics library for the engine?

jme3-jolt is still in early development. For now, I'd recommend Minie.

[8Keep]

That sounds good to me.

[riccardobl]

The problem is minie is native, so we are going to have to make sure everything is always tested in every platform.
That include also same platform with different dynamic libraries (eg. glibc versions)... so this is a bit of a pain.
We'd need something that is pure java, but afaik there is nothing.

[8Keep]

Let's break this down - for natives, we need to support every platform that we support with base jme.

1. we are removing 32 bit x86 support from the engine, so these are now irrelevant, don't need to care.
2. Need to support ios and Android. I have not tested and don't have a game for either, but reading the wiki, seems like minie is supported there. @stephengold can you confirm?
3. Linux is the odd platform to support. The only issue is always glibc, where you must link against an older version in order to have runtime support for that version and any later glibc version, due to how they do symbol versioning. It is always forwards compatible, but not backwards compatible.

How people solve this is usually either - build Linux natives on an older os, like Ubuntu 20 or 22 rather than the latest, or use a container or sysroot with modern compilers but slightly older glibc just for this.

I think we should match what lwjgl does, because we are dependent on that anyway. LWJGL/lwjgl3@dfd20ac
Spasi is on top of minimum glibc 2.28, from 2018. In my opinion this is an extremely conservative version and we could bump to just around 4-5 years old, but I don't have a strong opinion. See the linked GitHub actions yml for how spasi is building for Linux.

It's possible we might want one standard solution for natives building for Linux for the engine and any third party libs in the community, just to align everyone.

Of course, Linux is unique here, this is the only modern operating system where you need to build with an older lib to run on older versions of distros. For every other OS, you can build with the latest tools and produce a binary that can run on older versions of the OS.

4. We will want whatever physics solution we have to work on the web as well. @riccardobl were you successful getting Minie to work on web ever? It should be possible...

[riccardobl]

We'd need also the arm64 and ios builds.

For web, it is even more complex: if it is plain java it can compile mostly fine with teavm, but JNI natives are unsupported.

We'd need to build minie to wasm or with emscripten and then write custom wrappers for that. That is mostly what I did in NGE but using ammo.js as backend.

[stephengold]

For many years, Minie has supported Arm64 and Android but not iOS. At various times I've tested ARM64 and Android. I don't have a good way to test iOS. Other than testing, I don't know any impediment to adding iOS natives.

The Linux native libraries used by Minie are intentionally built using old versions of GCC. Equal or higher GLIBC versions should be available on most OSes that still receive support. I haven't compared the GLIBC versions with those of LWJGL, which of course has a similar issue.

I have no experience with Wasm or Emscripten, so I'd probably need some help there.