Strange problem with OpenAL - checkALCError

[JoshuaD]

I'm developing a game in Eclipse using slick and I just added sound to it.  There are no problems when I launch it from Eclipse; sounds play perfectly.  However, when I export it as a Jar and try to run it there the sound doesn't work.  The game starts without sound and I get the following error:

Mon Jun 25 09:18:47 EDT 2007 INFO:Initialising sounds..
Mon Jun 25 09:18:47 EDT 2007 ERROR:Sound initialisation failure.
Mon Jun 25 09:18:47 EDT 2007 ERROR:Invalud Value
org.lwjgl.openal.OpenALException: Invalud Value
        at org.lwjgl.openal.Util.checkALCError(Util.java:50)
        at org.lwjgl.openal.ALC10.alcGetInteger(ALC10.java:189)
        at org.lwjgl.openal.ALC11.initialize(ALC11.java:158)
        at org.lwjgl.openal.AL.init(AL.java:180)
        at org.lwjgl.openal.AL.create(AL.java:140)
        at org.lwjgl.openal.AL.create(AL.java:104)
        at org.lwjgl.openal.AL.create(AL.java:191)
        at org.newdawn.slick.openal.SoundStore$1.run(SoundStore.java:238)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.newdawn.slick.openal.SoundStore.init(SoundStore.java:235)
        at org.newdawn.slick.Sound.<init>(Sound.java:54)
        at ConfigManager.loadSoundSystem(ConfigManager.java:116)
        at ConfigManager.loadMainConfig(ConfigManager.java:48)
        at Tetris.main(Tetris.java:13)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.simontuffs.onejar.Boot.run(Boot.java:243)
        at com.simontuffs.onejar.Boot.main(Boot.java:89)

I'm currently including all the .dll's in the current directory along with lwjgl.jar and slick.jar.

I've posted this up over at the slick forums, and we're all scratching our heads over there.  Does anyone have any idea what this error means or what's causing it?

Thanks. -Josh

[Fool Running]

This is the code causing the error:

ALC10.alcGetInteger(AL.getDevice(), ALC10.ALC_MAJOR_VERSION, ib);

My best guess is that AL.getDevice() (or the getDevice() call inside of ALC10.alcGetInteger()) is returning a null (zero).
No idea why that might happen, or how to check it (since its in the init of OpenAL), but there you go. Maybe someone else will know.

EDIT:
The code for ALC10.alcGetInteger() is:

public static void alcGetInteger(ALCdevice device, int pname, IntBuffer integerdata) {
	BufferChecks.checkDirect(integerdata);
	nalcGetIntegerv(getDevice(device), pname, integerdata.remaining(), integerdata, integerdata.position());
	Util.checkALCError();
}

static long getDevice(ALCdevice device) {
	if(device != null) {
		return device.device;
	}
	return 0L;
}

The getDevice() call there is the other call I was talking about.

[JoshuaD]

Thanks for the response.  I've isolated the problem:

In these examples the manifest is specifying the classpath.

If I have the .dll's in the current directory and try to run the game like so:

java -jar Game.jar

or

java -Djava.library.path="." -jar Game.jar

it doesn't work; we get the same error as above.  However, if I run the code like this:

java -Djava.library.path="C:\Documents and Settings\Josh\Desktop\Game" -jar Game.jar

it works perfectly.  What's even stranger is if I move the .dll's to ./lib and then run this it works:

java -Djava.library.path="lib" -jar Game.jar

So it seems to not like referencing the native libraries relative to the current directory only when they're in the current directory.

This wasn't a big deal in the end, I intend to wrap it with a script in a *nix environment and I'm using JSmooth in windows to wrap it with an exe.  In both I'm able to specify the java.library.path variable without requiring the user to think about it, but it would certainly be nicer to be able to make the .jar double-clickable with no knowledge requisite on the user's end.

Does anyone know why this is happening and whether it's expected behavior or a bug?