Deploying madness w/ applets

Well I’m clueless as to why it is getting closed. The good thing is that getResourceAsStream(String) doesn’t return null, which means the resource was found. Now this hiccup is quite puzzling :S

BufferedInputStream will throw an IOException with message “Stream closed” if you pass it null as its constructor argument. Looks like under the covers, Slick is using BufferedInputStream, likely on the stream you pass it, so I’m still betting you’re giving the wrong path to your resource and thus getting a null value for the stream.

Pretty sure I’m not. It works when initializing an image passing the same path. Tried both as applet, and in my environment. Neither works - they both close :clue: anything I could try?

Grab the Slick source and run in a debugger?

BufferdInputStream.getInIfOpen() throws that Exception when the wrapped InputStream is null, so I’m still not convinced you’re giving it the right path. :slight_smile: What is printed when you do this?


System.out.println(Thread.currentThread().getContextClassLoader().getResourceAsStream("/res/tileset.png"));

Nothing is printed :persecutioncomplex:

This is getting a little… meh… Just checked out kevglass’ Fizzy Bricks, and he loads


this.cols[0] = new Image("res/blue.png");

and the file-system in his jar looks identical to mine. However, when I try to run something that just loads this one picture, using the way above, it still does not work :o

Can you run Fizzy Bricks without an error?

[edit] and wouldn’t the beginning “/” denote the root of the file system instead of the directory where the applet is?

Yes. Not my build though, but I can look inside whats going on.
I tried both with and without the front slash - none work.

If it was null, “null” would be printed. If it wasn’t null, you would get java.io.InputStream@.

It did not print anything at all. Im definite that the block is executed, but it doesnt print. Can I show you, in some way? I can upload the applet, and you can look at errors/source for yourself if you would like :slight_smile:

Sure!

“Stream Closed” means “Resource does not exist”. The path is wrong or the resource is not, in fact, present in your jars.

Cas :slight_smile:

If it didn’t exist, the method would return null.

Regardless of what you think, I am right :smiley:

Cas :slight_smile:

  1. I have my own opinion too! The resource is present, where it should be, and the stream gets closed.
    Here’s what happens:
    http://javadaemon.com/games/skrollr/

Here’s the same thing, loading differently:
http://javadaemon.com/games/skrollr/test1/

This is a reproducion of the original problem, so it’s easier to read. Please take a look inside of it!

The stream doesn’t “get” closed - it never opens, because the resource doesn’t exist. Try changing the resource name to something you know doesn’t exist like “xyzzy” and note the same error message.

Cas :slight_smile:

Try it without the initial / in the resource path.

Cas :slight_smile:

I see. Can you please take a peek though, because it is definitely where it should be.
javadaemon.com/games/skrollr/test1/test.jar

That’s what I did. Same error anyway though.

I can see it’s there - have a go using “res/tileset.png” instead of “/res/tileset.png”…
Ok, was just checking. Looks like it may be a slick issue then. Can you read the input stream yourself using that piece of code (instead of passing it off to Slick)?

Cas :slight_smile:

Locally, no. However, I can do a "new Image(“res/tileset.png”); and it will work, locally.
Fizzy Bricks (the physics game Kevin Glass wrote in two evenings to introduce the Fizzy overlay of box2d), initializes it’s resources this way, in the applet: new Image(“res/whatevs.png”); and it works in the applet as well.
Jar structure looks the same to me, of the two.

What if you are accessing the wrong file perhaps :wink:


java.security.AccessControlException: access denied ("java.io.FilePermission" ".\res\background.png" "read")

Where’s background.png? :wink: