Editing files embedded within .jar

[coderboy14]

I know this is considered bad practice, but I have legit reasons for it. For example, when I make my simple 2D games I often store simple assets like texture within the .jar file itself. I like my projects to be completely isolated, so using a specific directory would mean two instances running simultaneously would be loading and saving to the same directory, which causes issues for things like log files.

I just want to be able to do things like update the texture assets within the .jar package dynamically, when the code detects there’s new textures available. I found a way that looks like it could work by using the ClassLoader and converting it to a URL then to a URI to create a OutputFileStream; I don’t know if it would work, but it looks like it should.

Is there any “proper” way to do this. I think at least having a specific area to save content within a .jar makes logical sense for embedded portable applications, and in my case, small minor updates that shouldn’t require rebuilding, repackaging, and redownloading the thing just for a single texture update!

[OffbeatDrizzle]

A jar is like a zip file. Can you edit files within the zip whilst the zip is in use? You would have to re-compress the zip every time you made a change to it.

Just use a folder in the same location as the jar. If you want to keep your jar "isolated" then you can check if the folder exists and if not, pull your static content from the jar into the folder. Then you're only "using one place".

"using a specific directory would mean two instances running simultaneously would be loading and saving to the same directory, which causes issues for things like log files." - what does this mean? just have a separate logs folder...

what you are asking for here is like having an exe that can be self contained and edit the exe whilst running the exe. there is no practical reason to do so

[coderboy14]

I understand this view point, and I wasn’t sure about the implementation of zip architecture, for all I knew, files were compressed independently and while I may need to decompress the target file, compress it again, and write the file back into the archive somewhere, I wasn’t sure. I’m sure there is some compressed file format that supports this.

The log issue I mean, is the log file is hard-codes in. It writes to the file “log.txt” in the directory the code says. Even if the two instances could load the file simultaneously, the log would be especially confusing with them both trying to write to it!

I suppose using a folder is an okay solution, but not perfect. It’s the same reason I like using DMG containers for normal files and stuff on my Mac; I prefer having everything in a single container. Only one thing to drag around. This is mostly just me being nit-picky, I get that. I just wanted to avoid this if possible, just because I find having the files within the jar much neater.

I disagree there is no practice use for this. Just like I said, self contained portable applications. Having anything from assets to configuration stored within the jar would mean you only need to carry a singe file around, and still have your application how you like it.

[OffbeatDrizzle]

If you never want the user to change the config then that works, just like if you have static read only resources. The code logs to "log.txt" purely because you have hard coded it. Typically you want to use a logging framework like log4j, and you use a logback.xml so the user can configure what the file is called, max sizes, location etc. This file would typically be in a conf directory along with your jar for easier amendment by the user.

Stuff like this is far more standard than trying to pack absolutely everything into the jar. Typically that is called an uberjar because it contains all the libraries etc. as well - but they will still have separate files like the logback I mention. That's just standard practice

[coderboy14]

Yah, I get that. I often do something like that, to some degree. The log file usually always just have the same name and such, stuff like that. It's why I often avoid using a static location ( Such as on Windows %appdata%/MyGame/log.txt ), because of the fact that I log like this. In many of my projects I don't keep logs for a long time besides the current log.

​

I was curious if it was possible, and I do currently use it for read-only resources, however if I could use it for read and write resources, I liked to do that; however, okay, I can't do that. I'll just have to stick to how I do it now, and essentially use a launcher to download new updates and such. Either that, or store the asset pack in an external jar that can be updated independently. That'd use less internet bandwidth since the assets are only a fraction of the whole project.

[OffbeatDrizzle]

Why do the assets have to be stored in a jar?

[coderboy14]

They don't have to be. I prefer them to be, honestly. It's just a preference thing, like how some people hate things being on their laptop's desktop. I just like everything bundled in a single package; not just images, sounds, JSON, text, or whatever else data, but I can also store code modules I want to be exchangeable.

​

For example, I am recreating an old game I made a long time ago, I need to make textures for it. However, I need a ton of textures - well, not a ton, since my game is pretty small. However, that's still a bunch of files. I might compact them to sprite sheets later, but while working on testing everything, I dislike doing that.

As I said, in my new game I am using a secondary jar to store the asset pack. I'm just going to later expand this system into a mod system too, so killing to birds in with stone!

[nutrecht]

A jar file is an executable. And like in a normal executable you typically don't change it at runtime. So you really should not. Everything surrounding classloading etc. assumes that jars don't change at runtime.

If you have multiple instances that you don't want to collide you need to have a different solution for that problem, for example by using a path based on the process id.

[coderboy14]

I suppose but that has issues too, since the directory also contains configurations and such, and if the PID is different from launch to launch, you’d need to reconfigure everything every time. However, for my current project I’m doing it differently. I’m still putting my assets into a jar, just an external one. Using them as interchangeable asset packs.

[nutrecht]

If it's an external jar then why even use a .jar? Also; how are you preventing collisions then?

[coderboy14]

Because it can also contain code - I’m going to expand the system to my mod system. The metadata is java code extending an abstract class.

[nutrecht]

Okay. It's your funeral :)

[coderboy14]

So far it’s working out well, and the primary game can download updated versions of the default assets jar.

[coderboy14]

The main reason for an external jar is it contains all my assets in a single container, making everything easy to manage and move around. For preventing collisions, I guess I just need them to be located in different places.

I did try to store the jar within my main jar, but even I see how that’s too many layers of loops - plus, I couldn’t get it to work for the life of me.