We Keep Coding

Should I put my images inside the JAR or leave them out of it ? (Inno Setup)

So I have made a simple game using Java. I have my Jar file and inside it I am keeping my pictures. It's like a lot of pictures going on there. Like 140+ pictures at around 9 MB (mostly icons) (Not worried about efficiency, game already runs pretty smoothly). Now I wrapped my jar file into an .exe and then used Inno Setup to make a setup file. The thing is I am creating a folder in Program Files that only has a the application.exe file and the uninstallation file. This looks a bit vague to me and unprofessional. Though I've seen great games having all of their icons outside of the executable of course, just wondering would it be a good practice to keep the images inside or out ?
Suggestions are welcomed :D

I prefer to keep images and other resources inside the JAR file. You don't want the user to change any of them, same as for the program classes. So I don't see why you should have a different storage for images compared to classes.
The most robust and simple (and that should be the meaning of "professional") setup is to have the whole program with all its prerequisites in just one file - either it's there and works, or it's missing, and you'll see that immediately. No need to check for existence and accessibility of dozens of subdirectories and files.
And as you're asking the question, you surely managed to read the images from the classpath, thus allowing to store them together with the class files, e.g. in a JAR.
Regarding wrapping in an EXE, that shouldn't make a difference: if the ClassLoader finds the classes, it'll surely find the images the same way. And even Ahead-Of-Time-Compilers support getResourceAsStream() (we've done that with Excelsior Jet).

Is writing into class resources a good way to save files?

When we want to load a static file e.g. a picture, a sound file, a file containing information about a game map,... we can store them as resources in jar file and use getClass.getResource("images/splash.png") (also getResourceAsStream) to load and use them. But when we want to read and write into a file like settings file, I don't think using resources is a good way, because i think resources are designed to store read/only files that are not supposed to change, like splash screen image or a game's background music; These are my reasons to think this way:
That is why return value of getResourceAsStream is an instance of InputStream and we don't have a similar function which gives us an OutputStream, because we're not supposed to alter resource files.
Writing into resources changes program .jar file and i guess it's not a good thing at all; Because if we do so: we can't use check-sums to verify file, if we are a limited user and system administrator doesn't give us write permission we can't make changes into main .jar file, user-specific preferences are hard or impossible to implement,...
So, my questions are:
Which parts of my thoughts and assumptions are right or wrong?
If they're right what is the best(I mean short and portable between OSs and Computers) way to store files like that? (Application setting/preferences, A game save file, ...)
(#Some user who may wants to mark this as duplicate: I don't think my question is a duplicate, i searched in the site, I admit it has some common parts with some questions but it's not duplicate!)

Your three observations in #2 above are valid reasons not to store settings in a resource file, regardless of the APIs provided.
There are a variety of ways to save settings in Java, including:
The Java system property "user.home" provides the user's home directory, to which the user should have write access. You can create an application-specific subdirectory underneath it.
Java provides a Preferences API. This may store settings in a directory or (on Windows) in the registry.
OSGI provides a preferences API.
If you're using the Eclipse RCP, you can write to the configuration directory using a ConfigurationScope. See the Eclipse FAQ "What is a preference scope").

How to get the icon for a file extension or filetype without creating a temp file?

I list some filenames with their icons (like the ones in the Windows Explorer) in a JTable. I know the two ways to get the icon if I have a File object from the local file system:
javax.swing.filechooser.FileSystemView.getFileSystemView().getSystemIcon( file )
for a 16x16 icon or for a bigger one:
sun.awt.shell.ShellFolder.getShellFolder( file ).getIcon( true ) )
Since my files are stored in a database, I don't have the File object. My workaround is to create a temp file with the specific filename extension, use one of the two methods above and cache the icon to display it in a CellRenderer.
I searched for a solution without temporary files and found two I don't like either:
org.eclipse.swt.program.Program.findProgram(String extension).getImageData(), but I don't want to use SWT
org.jdesktop.jdic.icons.IconService from the Incubator of the JDIC project. The last changes on the IconService are 6 years ago, on JDIC 2 years ago and I can't find a downloadable jar.
Is there another solution?

Looks like you already discovered the way to do it, unless you want to dive into native libraries etc.
FileSystemView uses Win32ShellFolder internally so they are basically the same.
I also dug up the Source for org.eclipse.swt.program.Program and with it org.eclipse.swt.internal.win32.OS. The OS class then uses a native call for the Icon. At this point unless you really really cannot create a Temp File i would not go down that path.
For JDIC i only found http://kickjava.com/src/org/jdesktop/jdic/tray/internal/impl/WinTrayIconService.java.htm with a little bit of digging(may not be related but does icony things :D). Also calls native.

Do you really need the temporary file to use the first option? A File does not have to denote a file that actually exists...

Can Java access the search file system feature in the operating system?

In the recent versions of windows, you can hit the start menu and start typing to search for files across the filesystem. Is there a way to do that programmatically in Java?
My specific purpose is to allow the user to choose a file or directory. The user could start typing a file name directly inside the application and it could start showing suggestions. Much easier than navigating directories in a typical file chooser.

This post details a way to do this in Windows, by accessing the native functionality:
Query Windows Search from Java
And this one details how you can do something similar (using mdfind) under Mac OS:
http://lists.apple.com/archives/Java-dev/2006/Oct/msg00224.html

What you're asking for in the second part of your question could be done with a simple:
File dir = new File( "/path/to/dir" );
String[] contents = dir.listFiles();
The first part is a bit harder, but it could be accomplished inside Java using the same technique called recursively. (for(String fl: contents){ /* do the above */ })
You don't want to worry about supporting wrappers around command line calls here. That is anti-platform independent.

you could write JNI code to wrap+expose any windows native functionality.
If it's just for autocomplete style behavior in a file dialog, you don't need to wrap the native functionality, you can just use standard stuff in java.io.

Sounds unlikely ti be a part of Java, since Java is supposed to be platform-independent. Such searches should require some sort of index over all files, to be efficient, also.

IzPack equivalent to NSIS ReadCustomerData?

I want to personalize (customize, preconfigure etc) each copy of the installer I give out. But, of course, I do not want to recompile the installer every time.
NSIS has a solution where you append the data to the executable. Can you suggest a solution with IzPack?
One idea I had, is to add data post installation to the installer JAR file, but I can't figure where and how to read it...
Thanks

A JAR stores its headers at the end of the file, this means your custom data must be added to the beginning of the file (A combined GIF and JAR is known as a GIFAR and has been used for some exploits in the past, so just make sure you don't start your custom data with something that looks like a GIF (or other image format) header to avoid AV false positives)