Whenever I try to load a ogg file on android, the app crashes with the following stack trace:
JNI DETECTED ERROR IN APPLICATION: JNI GetFieldID called with pending exception java.lang.NoSuchFieldError: no "Ljava/nio/ByteBuffer;" field "ovf" in class "Lcom/jme3/audio/plugins/NativeVorbisFile;" or its superclasses
at void com.jme3.audio.plugins.NativeVorbisFile.nativeInit() (NativeVorbisFile.java:-2)
at void com.jme3.audio.plugins.NativeVorbisFile.<clinit>() (NativeVorbisFile.java:19)
at com.jme3.audio.AudioStream com.jme3.audio.plugins.NativeVorbisLoader.loadStream(com.jme3.asset.AssetInfo) (NativeVorbisLoader.java:97)
at java.lang.Object com.jme3.audio.plugins.NativeVorbisLoader.load(com.jme3.asset.AssetInfo) (NativeVorbisLoader.java:128)
at java.lang.Object com.jme3.asset.DesktopAssetManager.loadLocatedAsset(com.jme3.asset.AssetKey, com.jme3.asset.AssetInfo, com.jme3.asset.AssetProcessor, com.jme3.asset.cache.AssetCache) (DesktopAssetManager.java:259)
at java.lang.Object com.jme3.asset.DesktopAssetManager.loadAsset(com.jme3.asset.AssetKey) (DesktopAssetManager.java:373)
at void com.jme3.audio.AudioNode.<init>(com.jme3.asset.AssetManager, java.lang.String, boolean, boolean) (AudioNode.java:163)
at void com.jme3.audio.AudioNode.<init>(com.jme3.asset.AssetManager, java.lang.String, com.jme3.audio.AudioData$DataType) (AudioNode.java:144)
Yes, I know it T.T, all seems to be fine, that’s the problem why I didn’t already fix it myself and that’s why I think Darkchaos suggested the removal of that class (java.nio.ByteBuffer) on the android version, the field is there so maybe the class isn’t?, I’m not much experienced on JNI.
Yeah it’s a fault on my side. I read that like “Field ovf of class ByteBuffer”… however I also did some research:
Oracle definitely wants to remove the Unsafe API in Java 9 but they will also delay that because it would break lots of internal code, so we still have some time until that happens.
If the class wasn’t there, you would most likely see a segfault or some other error “class handle invalid”, actually it pretty well knows the class.
That is really strange, actually many of the tests shouldn’t pass when the problem is inheritent with JmeSystem.
Something seems wierd in that setup actually.
Can someone different confirm he gets the same issue?
And maybe also ensuring that you delete the ~/.m2 folder or the jar’s inside at least, so you don’t pull them in.
implies you don’t have a proper delegate or the creation thereof failed. Is this now desktop or android?
Desktop, I’ve build the engine many times from different versions, this time is just failing (I though it was something about any last change and it would be fixed any time soon). I’ve just tried it moving the .m2 folder (I have many custom libraries there, but nothing that could interfere with the build, or should…) but it didn’t change anything.
Well using gradlew install would place the engine there.
And what you see is indeed a new test, I don’t know if you can’t skip the tests actually, but the issue seems to be failing to use the DesktopAssetManager.
Maybe this is an issue with the test though, since tests might not have a lwjgl window and as such maybe have a TestAssetManager? (But that’s just wildly guessing)