I have googled at least a million times, and not found anything that works. I get this error:
Failed to load: java.io.BufferedInputStream@3227f076
From this line of code:
this.hurtSounds = AudioLoader.getAudio("WAV", ResourceLoader.getResourceAsStream("res/sounds/zhurt0.wav"));
What is going on?
EDIT:
hurtsound is an Audio
This is simply not being able to find the file. make sure you have “res” in your class path.
If I’m not mistaken, the InputStream is going to be looking in src/res/sounds/ for your audio, which clearly doesn’t exist. As ra4king said, putting res in your class path should allow the InputStream to search in res as well.
That, or you can place your res folder in src. That should work with the code you’ve written.
The classpath is whatever you define it to be but the default is the current directory: “src”. Since “res” is outside that, the JVM does not know where it exists.
You have two options:
I recommend the first option.
If you are using Eclipse, you can right-click the project, go to configure build path, and go to the source tab. There you’ll see the src folder because it’s in your class path. You can click the “Add Folder…” button to add your res folder.
It should be similar in other IDE’s. If you are using a regular text editor, I’m not really sure how you’d do it.
In the very first post, it looks to me like your code is using in the same folder as the one where the class AudioLoader sits as the base folder.
If ResourceLoader is in ‘src’ then the code is looking in src/res/… etc., which doesn’t exist. From your diagram, it looks like /res is a neighbor to /src. Yes?
Thus, maybe “…/res/sounds/zhurt0.wav” would work.
BUT it looks like you tried the valid alternative suggestion of putting res in the src folder and got a new error message. The new message mentions “input stream” which reminds me of an error which surfaced in Java 7 and caused me a fair bit of grief to figure out.
In Java7’s audio library (javax.sound.sampled.*), if you try to load a wav to an InputStream, and then load the InputStream to an AudioInputStream, you will likely generate a “Mark/Reset” error, because wav files are not usually markable and resetable (a requirement of InputStreams). Fortunately, Java Audio lets you load an AudioInputStream directly from a File or URL directly, rather than from an InputStream.
Since the error mentions being unable to read from the InputStream, I am wondering if the code is creating an intermediate “InputStream” that is generating the Mark/Reset error.
So, I do a quick search on “ResourceLoader Slick” and see that that the code you are using is standard Slick library stuff. Since this is a standard Slick usage example, scratch that idea. I would be really surprised if the coders of a well-used library like Slick hadn’t accounted for this known error. (I hope that little digression wasn’t too unhelpful.)
No no no the error is that OP did not read my post. I’ll re-paste it here:
By default, ResourceLoader looks in “src”. If you add “res” to the classpath, it also looks in “res”. When you specify path “res/sounds/zhurt0.wav”, it’s looking for a folder named “res” INSIDE of “src” and “res”, neither of which contain said folder. This is why you should have read option 2: put “res” on the classpath and remove “res/” from the file paths (notice the first forward slash is also included). However, I recommend the first option where you simply move the “res” folder and put it inside “src”, which will require no renaming of paths.
This might sound a bit pedantic, but I think we’re getting confused about where “src” fits into the classpath. Typically it isn’t part of the classpath at all. Normally it is a destination folder called “classes” where all the compiled classes end up.
Most IDEs also have the option of recognising other “source” folders. The contents of these folders (ig. “res” for your resources) are also copied to the destination “classes” folder.
The classloader used by ResourceLoader will most certainly be looking in this “classes” folder for the files. I would be checking there to see if the file exists. This is the reason why making a distinction between “src” and the classpath is important - depending on the type of file and your IDE, the contents of a source folder might not be getting copied to the destination classes folder. It may also be getting put in a folder in classes that does not necessarily mirror the structure in src.
To make debugging this a lot easier I would suggest breaking up the line loading the resource into two. Perhaps even add some additional checking. For example:
String resourcePath = "res/sounds/zhurt0.wav";
InputStream in = ResourceLoader.getResourceAsStream(resourcePath);
if (in == null) {
throw new IOException("The resource " + resourcePath + " does not exist at the expected location");
}
this.hurtSounds = AudioLoader.getAudio("WAV", in);
It would have more convenient had the ResourceLoader class performed this checking for you an raised an appropriate exception. I’m not too keen on code that just returns a null on failure. Exceptions do this job so much better.
@davidc - The discussion on class path and src is good. But the example you gave will very likely return the “Mark/Reset” error I brought up, won’t it? InputStreams are required to be markable and resetable, and wav files generally are not.
@r4king - I couldn’t tell for sure what the op meant by “I put it in and still the same error.” Aren’t pronouns great! I assumed he had followed your original suggestion of moving res into src (put ‘res’ into ‘src’) and then got the new error message.
I don’t have Slick installed. Can anyone verify that the code davidc posted works without causing the Java7 “mark/reset” error? I’m really curious to know for sure.
If the file is being found (which we still don’t know for sure either way), then the issue might indeed be the mark/reset issue. I’m actually thinking the assumption that this is a classpath issue might be a little off given the error message:
Failed to load: java.io.BufferedInputStream@3227f076
This seems to indicate that an input stream was instantiated.
This is the advantage of splitting the code up into separate lines rather than cramming it all together. It’s much easier to identify what exactly causes the problem, rather than making assumptions.