It is not always the case that the entire program code is loaded into memory

Oh really? Why is this so?

The executable itself along with all the associated libraries required less than 45MB, or just under 2% of the total size.

That is strange. My game is quite small in content. But the executable alone is 85.4 MB! Should I not be putting my assets(audio, art, game logic in the exe)? I know these files are there because when I extracted the executable java jar file, the folder that contains the mentioned assets appear.

So I must be doing something wrong, if the executable jar file is so big even for a game with small content(2 minutes of doing everything)!

It is not always the case that the entire program code is loaded into memory

Oh really? Why is this so?

Because the OS has the ability to do memory mapping.

http://en.wikipedia.org/wiki/Memory-mapped_file

This way it can intelligently load the parts that are actually used, while setting aside the memory addresses for the whole thing if needed.

Do all OS from all brands of computers have this? What happens if a programmer coded the game to load the data for map 1 even when the player is at map 0? Asumming the section of the map are traveled linearly in a numerical order. Would the memory mapping still kick in or follow the code the programmer has written for the game?

JARs don't really work like normal executables. They're more zip files that include the executable files along with other stuff. Not sure if it's accepted practice to put your assets in there.

Oh Interesting. The strange thing is that I seen people make java games and their games have more assets than mine. But their jar file is super small not even hitting the 10 MB mark and their game boots up by clicking the exe while I actually have to extract a folder from the jar rename it to a folder called "src" and then have the game read that folder which makes the file size containing the exe and the folder equal to roughly twice the size of the jar file.

It is not always the case that the entire program code is loaded into memory

Oh really? Why is this so?

Because the OS has the ability to do memory mapping.
http://en.wikipedia.org/wiki/Memory-mapped_file
This way it can intelligently load the parts that are actually used, while setting aside the memory addresses for the whole thing if needed.

Do all OS from all brands of computers have this? What happens if a programmer coded the game to load the data for map 1 even when the player is at map 0? Asumming the section of the map are traveled linearly in a numerical order. Would the memory mapping still kick in or follow the code the programmer has written for the game?

Memory mapped files are a feature that has to be explicitly coded to use. So it works however the programmer write it to work.

For automatic swapping between harddisk and memory, a swap/page file is used, which depending on the OS can be a special file or a hard drive partition. Yes, all Operating Systems have paging, modern and not so modern. It isn't aware of what "map" the player is on, but it tries to swap out the least recently accessed memory first, with some intelligence to achieve application fairness. With modern physical memory sizes, paging isn't called for as much, although the same infrastructure is used to initially load application memory.

For Java, if you are looking for a better comparison, there are tools that compile into a native executable rather than into .class files.

Normally the .class files are basically re-compiled on the fly into the real executable through JIT. There are a few free tools to do it, like GCJ (part of the GNU compiler collection, just like their c or c++ compiler, but instead for java), but most tools appear to be non-free. There are pros and cons to doing this, one big benefit is that you can get more aggressive optimization for faster runtime results, but at the cost of tying it to a specific architecture and you lose the run-anywhere aspect for PC, Mac, Linux, and other systems.



When you talk of executable size, it is different from the size of a .jar file that has all the assets embedded in it. As you probably know, a Java Archive (.jar) file is just a .zip format archive file that requires some specific files to be first. You can use almost any compression tool to make the archive and add any data you want, but for convenience just rename it to .jar when you are done. Executable jars are a tiny executable wrapper that have the archive file attached to it.

In Java 6 and before you could use any valid 32-bit zip file, meaning up to 16-bits (65535) individual files with a maximum size of 32-bits (4GB). So if your modern game would ship on a 4GB DVD you could just stuff everything into a giant .jar file and run it. Starting in Java 7 the 64-bit zip format is used, so you can store up to 16 exabytes in your archive assuming you can distribute it.

So yes, "jar size" and "executable size" are very different, even when you have an executable jar.

I actually have to extract a folder from the jar rename it to a folder called "src" and then have the game read that folder which makes the file size containing the exe and the folder equal to roughly twice the size of the jar file.

You can use the JarFile class to open your own file, search through the file listings for the right JarEntry, and then open it as an input stream decompressing it as you stream the data out the same way any .zip decompression library works. For some resources this can happen automatically. No need to decode the file out to disk unless you have some disk-based need.

I actually have to extract a folder from the jar rename it to a folder called "src" and then have the game read that folder which makes the file size containing the exe and the folder equal to roughly twice the size of the jar file.

You can use the JarFile class to open your own file, search through the file listings for the right JarEntry, and then open it as an input stream decompressing it as you stream the data out the same way any .zip decompression library works. For some resources this can happen automatically. No need to decode the file out to disk unless you have some disk-based need.

It turns out the JarEntry is another Java class built in to the Java Standard Library. So with the above mentioned Java classes, the jar will just read the files embedded in the jar exe?

One thing I should mentioned is that I am using FileInputStream. Here is my Java game code for reading the art assets.

image = ImageIO.read(new FileInputStream(new File(animations[i])));

Does the above code being FileInputStream have any effect on when my java jar exe not running when I double click on it (unless I extracted the folder from the jar exe)?