Latest Nifty - incompatible types in SoundDeviceJme

Troubleshooting gui
1

Since last Nifty’s snapshot was introduced a couple of days ago I’m getting the following error. (Red squiggly line)



I get the errors in SoundDeviceJme.java at lines 55 and 59 (both return statements):



[java]

public SoundHandle loadSound(SoundSystem soundSystem, String filename) {

AudioNode an = new AudioNode(ar, assetManager, filename, false);

an.setPositional(false);

return new SoundHandleJme(ar, an);

}



public SoundHandle loadMusic(SoundSystem soundSystem, String filename) {

return new SoundHandleJme(ar, assetManager, filename);

}

[/java]



The entire error message reads:



incompatible types
required: de.lessvoid.nifty.spi.sound.SoundHandle
found: com.jme3.niftygui.SoundHandleJme
2

Sometimes the thing that generates the red squiggly lines gets confused in these cases. Does it otherwise compile if you do a full build?

3

It does compile but I can’t run the game.



I get:

[java]

java.lang.RuntimeException: Uncompilable source code - incompatible types

required: de.lessvoid.nifty.spi.sound.SoundHandle

found: com.jme3.niftygui.SoundHandleJme

at com.jme3.niftygui.SoundDeviceJme.loadSound(SoundDeviceJme.java:55)

at de.lessvoid.nifty.sound.SoundSystem.addSound(SoundSystem.java:45)

at de.lessvoid.nifty.loaderv2.types.RegisterSoundType.materialize(RegisterSoundType.java:12)

at de.lessvoid.nifty.loaderv2.types.NiftyType.create(NiftyType.java:109)

at de.lessvoid.nifty.Nifty.loadFromFile(Nifty.java:497)

at de.lessvoid.nifty.Nifty.fromXmlWithoutStartScreen(Nifty.java:408)

[…]

[/java]

when I try to.



EDIT: For now I just return a null from those methods. Simpler that way. I don’t have sound in the GUI but I can live with that for now It’s not a big deal.

4

Is anyone looking into this?



If I try to force cast it [return (SoundHandle) new SoundHandleJme(ar, an);] I get the following:



[java]

java.lang.ClassCastException: com.jme3.niftygui.SoundHandleJme cannot be cast to de.lessvoid.nifty.spi.sound.SoundHandle

at com.jme3.niftygui.SoundDeviceJme.loadSound(SoundDeviceJme.java:55)

at de.lessvoid.nifty.sound.SoundSystem.addSound(SoundSystem.java:45)

at de.lessvoid.nifty.loaderv2.types.RegisterSoundType.materialize(RegisterSoundType.java:12)

at de.lessvoid.nifty.loaderv2.types.NiftyType.create(NiftyType.java:109)

at de.lessvoid.nifty.Nifty.loadFromFile(Nifty.java:497)

at de.lessvoid.nifty.Nifty.fromXmlWithoutStartScreen(Nifty.java:408)

at com.madjack.games.sc.MenuUpdater.loadStartMenu(MenuUpdater.java:285)

at com.madjack.games.sc.MenuUpdater.doCommand(MenuUpdater.java:206)

at com.madjack.games.sc.MenuUpdater.doCommand(MenuUpdater.java:130)

at com.madjack.games.sc.Base.loadGUI(Base.java:136)

at com.madjack.games.sc.Base.simpleInitApp(Base.java:117)

at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:223)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:123)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:199)

at java.lang.Thread.run(Thread.java:662)

[/java]



Something must have changed in Nifty’s new release… Or is it just me having that?

5

I haven’t tried to compile recently but I also can’t spot the issue.



According to the Nifty 1.3 Javadocs online, there is still an interface:

de.lessvoid.nifty.spi.sound.SoundHandle

http://nifty-gui.sourceforge.net/nifty/apidocs/de/lessvoid/nifty/spi/sound/SoundHandle.html



And according to JME, SoundHandleJme implements this interface:

[java]public class SoundHandleJme

extends java.lang.Object

implements de.lessvoid.nifty.spi.sound.SoundHandle[/java]



And while I’m not looking at the latest code from SVN, I am looking at JME’s online Javadoc.



I try to only update JME when I have time to do some extensive regression and performance testing or I’d try it myself. But you should be able to use JMP to see if SoundHandleJme implements that interface and that the interface exists. If you try to view the source, JMP will generate fake source for classes it knows about but doesn’t have source for.

6

Everything looks fine on my end too. :confused: So not exactly sure why it does that. Just for kicks I compiled the game and ran it from outside the SDK and sure enough, it failed.

7

Ok… Again, weirded out.



Behavior is the same as in that thread I started: http://hub.jmonkeyengine.org/groups/gui/forum/topic/renderdevicejme-java-wont-compile/



This time to “fix” it, I had to add a space after “implements SoundHandle” in SoundHandleJme.java, deleted it then save. No more complain.



Now, the FUNNIEST is, I reverted that change and still no complain. :o Wut? lol



Sound is back. Quirky jMP. :stuck_out_tongue:

8

I don’t know how you build but that sounds precisely like what I was talking about: JMP will occasionally report things as errors that are not… especially when it comes to attempting to refer to an object by one of its implemented interfaces. Sometimes there is a way (as you’ve discovered) to get it to update its cache and make it work.



But in ALL cases that I’ve had that happen, doing a “clean build” will allow me to run the application… even though the JMP still shows the file as red and won’t compile it properly. ANT gets it right even when JMP doesn’t because it’s using javac.

9

I actually do nothing lol. These error (two up to now) have cropped up after updating jME’s Subversion.



The space thing is the only way I can get rid of the error. Clean & Rebuild doesn’t do anything except the obvious rebuilding.



If I had to take a guess, I would say that somehow, for some reason, that space between the implemented class name and the “{” gets bugged, maybe becomes a non-printable character that is seen as a white space, but that’s so far-fetched that I don’t really believe that.



It has also happened in the past that I had a corrupted or two updates from googlecode…



In the end, as long as that fix works, it’s good. At the point where it won’t I’ll probably post it here.

10

When a space fixes it for me it’s just a matter of getting the file to be different so it recompiles in the IDE… so that it recaches the info for the file that is actually having a problem with it.