NoSuchMethodError AnimComposer.makeLayer()

[stephengold]

The MavDemo1 application in my jme-vehicles project uses v1.1.1 of the JmePower library, which was compiled for JME v3.6.0-stable.

When I build MavDemo1 with JME v3.8.0-alpha3, initialization of the app fails with the following diagnostic messages on the console:

> Task :MavDemo1:run
Feb 17, 2025 2:28:59 PM com.jayfella.jme.vehicle.lemurdemo.MavDemo1 main
WARNING: Assertions are enabled.
Feb 17, 2025 2:29:03 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NoSuchMethodError: 'void com.jme3.anim.AnimComposer.makeLayer(java.lang.String, com.jme3.anim.AnimationMask)'
	at com.github.stephengold.jmepower.JmeLoadingState.setupCinematic(JmeLoadingState.java:409)
	at com.github.stephengold.jmepower.JmeLoadingState.startCinematic(JmeLoadingState.java:557)
	at com.github.stephengold.jmepower.JmeLoadingState.update(JmeLoadingState.java:319)
	at com.jme3.app.state.AppStateManager.update(AppStateManager.java:371)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:260)
	at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:707)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:797)
	at java.base/java.lang.Thread.run(Thread.java:840)

Exception in thread "Thread-3" java.lang.NullPointerException: Cannot invoke "com.jme3.input.InputManager.addRawInputListener(com.jme3.input.RawInputListener)" because the return value of "com.jme3.app.Application.getInputManager()" is null
	at com.simsilica.lemur.event.KeyInterceptState.<init>(KeyInterceptState.java:65)
	at com.simsilica.lemur.GuiGlobals.<init>(GuiGlobals.java:157)
	at com.simsilica.lemur.GuiGlobals.initialize(GuiGlobals.java:125)
	at com.jayfella.jme.vehicle.lemurdemo.LemurLoadingState.initializeLemur(LemurLoadingState.java:100)
	at com.jayfella.jme.vehicle.lemurdemo.LemurLoadingState.access$000(LemurLoadingState.java:43)
	at com.jayfella.jme.vehicle.lemurdemo.LemurLoadingState$1.run(LemurLoadingState.java:83)

Testing shows this regression occurred between v3.7.0-stable and v3.8.0-alpha1 .
Probably it can be solved be rebuilding JmePower for JME 3.8, but I think this should be investigated.

[yaRnMcDonuts]

If I recall correctly, some recent PR allowed for the saving of ArmatureMasks, so it could be that there is now an issue in 3.8 when you try to load a model with an armature armatureMask that was saved in 3.7?

I'm not having this issue in my project, however I take the approach of recreating my ArmatureMasks every time my app is launched. so i might not have much insight into this issue based on my experience.

Does this project throwing the exception load any models with armature masks?

[stephengold]

could be that there is now an issue in 3.8 when you try to load a model with an armature armatureMask that was saved in 3.7?

The loaded Model is "Jaime-new.j3o" from 2021, so probably saved using jMonkeyEngine 3.4.0-stable or thereabouts.

I expect a quick comparison of source code between 3.7 and 3.8 to clarify the root cause. That's my next step, anyway.

[stephengold]

Here's the failing invocation (JmeLoadingState.java:409): https://github.com/stephengold/JmePower/blob/bfe82293ecf767889dbe8ec9282c3cddcb910648/JmePowerLibrary/src/main/java/com/github/stephengold/jmepower/JmeLoadingState.java#L409

Here's the target method in JME v3.7.0-stable (AnimComposer.java:316):

jmonkeyengine/jme3-core/src/main/java/com/jme3/anim/AnimComposer.java

Lines 316 to 319 in bc6cdf5

	public void makeLayer(String name, AnimationMask mask) {
	AnimLayer l = new AnimLayer(this, name, mask);
	layers.put(name, l);
	}

In v3.8.0-alpha1, makeLayer() returns an AnimLayer instance instead of void. The change occurred at commit deef748, that is, PR #2231.

[stephengold]

As regressions go, this is a relatively minor one. If we're going to solve it, however, it should be in v3.8.0, else the incompatible API will become official.

I've decided to create a quick PR to solve it. Then @yaRnMcDonuts can decide if it's worth solving.

[yaRnMcDonuts]

I will wait for @capdevon to comment and give the PR some time before merging, but I'd say this looks like an appropriate solution to the compatibility issue.

This way we can benefit from the new methods without anyone having to go and rebuild old libraries with 3.8 in order to be compatible.