I am making a Cluedo boardgame in java and I cannot get my images to show up when converting it to a .jar file.I am adding the images on top of one another so I used JLabels(new ImagIcon ("..")) like so.To add the images and now the images can't be seen when I create a .jar file. Just wondering if there is any way to do without editing my code a significant amount. I have read all stackoverflow answers on this issue and none of them solves this particular problem. Here is what the board game looks like when I run it in Eclipse.
When I convert it to .jar file it no longer displays the board or any of the players.
ImageIcon(String) expects that the String value is "file" reference to the image residing on disk.
If you have externalised your resources then you need to ensure that the path you are using is correct. Remember, the "working directory" in which the Jar is executed isn't always the same as the directory that the Jar is stored in.
To this end, it's generally recommend to "embedded" the images (and other resources) within the Jar itself. This way you can simply perform a lookup for the resource regardless of where it's installed.
The means by which you embedded resources is slightly different for each IDE, but it basically requires that the images are included in the Jar and a specific location/package.
An important note, when embedded in the Jar, the resources can no longer be referenced as if they "files", because they're not, they are part of the Jar/Zip archive and need to be referenced in a different manner.
To load embedded resources you need to use Class#getResource, which returns a URL or Class#getResourceAsStream which returns a InputStream.
In most case, the first is enough. While ImageIcon does take a URL, it is generally recommended to use ImageIO.read, have a read through Reading/Loading images for more details.
The advantage of this is two fold:
It blocks until the image is read, meaning the image is fully realised when the method returns
It throws an IOException when the image can't be read, which is way more meaningful, as ImageIcon fails silently
So, all that would accumulated down to something like...
new JLabel(new ImageIcon(ImageIO.read(instanceOfMyAwesomeGameObject.getResource("/path/to/resource/ResourceName.png"))));
I think it comes from the path to your images. The image path for sources is probably not the same as for .jar
Related
I've been trying to make jar application that can read a csv file in the same directory as it. This is, however, proving difficult as my means for accessing the file currently is:
InputStream is = getClass().getClassLoader().getResourceAsStream(filename);
Which works for my program running in the IDE and for my tests but doesn't work when I run the program from the compiled jar file. I have no idea how to get it to work for both. I seriously can't understand this path stuff, it seems like there are a million ways to do it and only one of them work for only one specific scenario.
I've been trying to make jar application that can read a csv file in the same directory as it.
Ah, there's your problem. That just isn't a thing.
There are only 2 types of files:
Application Resources
These are read only, and are as much part of your app as your class files are. It is not in any way relevant to think about 'editing' them - that's not the kind of thing they are. It is reasonable to assume that if this resource is somehow missing, the app is as corrupt / misinstalled as it would be if class files are missing.
For this, you use .getResource and .getResourceAsStream. And note that getClass().getClassLoader() is wrong, you want MyClass.class.getResource and then add a slash if you want to go from root (because getClass() potentially breaks when you subclass, and going via classloader is [A] just typing for no reason, and [B] breaks in bootload scenarios. MyOwnClassName.class.getResource never breaks, so, always use that).
This asks java to look in the same place class files are and nowhere else. Your class files are inside the jar files, and not next to them, therefore, it won't find a text file that is sitting next to jar files.
it does not make sense that it does work during development: That means you shoved a file inside the resources folder, which is equivalent to having a CSV file inside the jar file. You must have gone out of your way to tell your build system to do weird things. Don't do that.
If that CSV file is not intended to be user editable it should be inside the jar file and not next to it: That makes it an application resource. Examples of application resources:
You have a GUI, and you need to store the icon files and splash screen art and such someplace.
You ship static data with your app, such as a table of all US states along with the zipcodes they use (could be a text or csv file for example).
Templates of config files. Not config files themselves.
DLLs and the like that you need to unpack (because windows/linux/mac isn't going to look inside jars for them).
You're a webapp and you want to ship the HTML static files along with your webapp.
If this is what your CSV file is, the fix is to put it in the jar, not next to it, then load it with MyClass.class.getResource(name).
Config files and project files
For example:
For a rich text editor (like, say, LibreOffice Writer), the .odt files representing your writings.
Save games for a game.
A config file, which can be edited by the user, or is edited by your own app in a 'preferences' dialog. This stores for example whether to open the app full screen or not, or authentication info for a third party API you're using.
These should not be in the jar, should not be loaded with .getResource at all, and should not be in src/main/resources in the first place.
They also should not be next to your jar! That's an outdated and insecure model (the idea that editable files sit in the same place the app itself sits): A proper OS configuration means that an app cannot write to itself which is most easily accomplished by having it be incapable of writing to its directory. Some OSes (notably, windows) did this wrong for a while.
For example on windows, your app lives in C:\Program Files\MakorisAwesomeApp\makori.jar, and the data files for it live somewhere in C:\Users\UserThatInstalledIt\Documents\MakorisAwesomeApp.
oh linux, your app might be /usr/bin/makori and the data lives somewhere in the home dir. Config data might live in /etc/.
You don't "ship" your config files, you instead make installers that create them. You can do this part in-app by detecting that the relevant config file does not exist, load in a template (that is a resource, shipped inside your jar, loaded with getResource), and write it out, and tell the user to go look at it and edit it.
I really want a CSV file next to my jars!
Well, that's wrong, so, there are no libraries that make this easy. When you want to do silly things its good that APIs don't make that easy, right?
There are really hacky ways to do this. You can use .getResource to get a URL and then 'parse' this. This breaks the classloader abstraction concept (because in java, you can write your own classloaders and they can load from anywhere, not just files or entries in jars), but you can ask for 'yourself' (MyClass.class.getResource("MyClass.class")), pull the URL apart and figure out what's happening - does it start with file://? Then it is a file, so turn it into a j.i.File object, and go from there. Does it start with jar://? find the !, substring out the jar part, and now you know the jar. Make that a java.io.File, ask for the parent dir, and look there for the CSV.
You have to write all this. It's complicated code that is hard to test. You should not do this.
I've mostly only created application for personal use and the rare occasions where I have distributed my code have been in the form of uploading my source code on GitHub. I'm currently finishing up a project and plan on using launch4j to package it up as an exe. However, my application has a handful of png files that I coded in with the unique filepath of my computer. Obviously if my code were to run on any other computer in the world, those files would not be found.
I'm vaguely aware that java does not require the full filepath for a file (ie C:\Users...\file_name.ext) but I've never gotten a program to run correctly unless I write out the filepath like that, so that's been my default up until this point.
The resource system. Think about it: What's the difference between the many class files that comprise your application, and those png files, from an application distribution perspective?
The answer is, essentially, nothing. They are file-like concepts, they might prefer to be shipped in a packaged-up file (a jar file) instead of separately. They must be found at some point halfway through your app's existence (java does not pre-load all classes. It just loads your main class, and then loads whatever is needed the first time you mention any class).
You don't have to hardcode the absolute path to those class files in your app, so they clearly don't suffer from this 'coding filepaths' issue.
Thus, the answer is somewhat obvious: Simply stick those PNG files in the exact same place as your class files, and ask the VM to provide you with the data in them using whatever mechanism it is using itself, as it is doing that exact same job (find resource, obtain data in the resource) all the time, on your class files.
But, how?
You have 2 different methods, and these 2 methods take the same kind of argument, which comes in 2 forms: A grand total of 4 'modes' to choose from.
Pick a method
If the API you have that needs an image file so happens to have an overload that accepts a URL, this is very simple (ImageIcon is one such resource, that's probably what you're passing these PNG files to, so that's great):
URL loadIcon = ContextClass.class.getResource("/icons/load.png");
new ImageIcon(loadIcon);
Quite simple. Sometimes you want to read it yourself directly, and a URL object is rather unwieldy. Sometimes, you want to pass it to an API which does not have a URL overload, but it does have an InputStream overload. Then, you can fetch an InputStream. Given that this is a resource, like all resources, you must safely close it, thus, let's use try-with:
byte[] pngData;
try (var in = ContextClass.class.getResourceAsStream("/icons/load.png")) {
pngData = in.readAllBytes();
}
ContextClass.class is a somewhat exotic java syntax feature: It is an expression that resolves to the java.lang.Class instance of the so-named class. For example, Class<?> c = String.class; is legal java and gives you the class object that represents the class concept of all java.lang.String objects. The class object itself has these getResource methods. Thus, substitute some relevant class that you wrote as context here. Presumably, if you want to load an image in source file MyStatusWindow.java, you'd just use that class: MyStatusWindow.class.getResource.
These methods will look in the same location that the class itself was loaded from. If ContextClass is loaded from a jar, then the system will fetch PNGs from within that jar. If it's loaded from a build dir during development/debug, the png is loaded from there. If you've got some fancypants module system that is loading classes straight from the network, then the PNG will also be loaded from there.
resourceKey
A resourcekey is simply a path. It's not really a path, just - a string with slashes. You can't use .., for example, it's not really a path. You also, weirdly, can't use filenames that include more than a single dot in the name, for historic (read: silly) reasons.
You have 2 variants - classpackage relative and absolute.
.getResource("/icons/load.png") is absolute. .getResource("icons/load.png") is relative. The leading slash is the difference.
If you have:
package com.foo;
public class MyStatusWindow {
...
MyStatusWindow.class.getResource("icons/load.png");
}
And this is all in a jar file (i.e. /com/foo/MyStatusWindow.class is one of the entries listed if you execute jar tvf myapp.jar on the command line), then the above would look in that jar for /com/foo/icons/load.png - the relative form takes the context-class's package and sticks it in front. The absolute form would just look in /icons/load.png, still in the jar (so it's never C:\ - never the root of your disk - it's the root of the classpath entry).
Build systems
Maven, Gradle, and just about every other build system has a proscribed directory structure. The above example should go in src/main/java/com/foo/MyStatusWindow.java, relative to some 'root project dir'. Only java source files are supposed to go there. There's also a resources: src/main/resources/com/foo/icons/load.png, that's where your icon file would go. Then MyStatusWindow.getResource("icons/load.png") will just work, in your build system, and in your IDE, and when you ship it all as a jar file. If it doesn't, you've misconfigured your IDE or have a broken build configuration - and you should fix that. Out of the box, this just works.
This question already has answers here:
Add image to JAR Java
(7 answers)
Closed 9 years ago.
I would like for the user to be able to choose from my pre-selected images within the program. I believe it would be similar to a text file within the program, however, as of right now it will only work with an image saved on to my computer. To specify, if I were to send my program to somebody, it would not function properly because they do not have the same photo I am using. I need the photos saved within the program. How would I go about dong this? Would jar files be the way to go?
Thanks!
Yes, jar files could work great for this. But if you use jar files, just remember that the images are not present as Files but rather as resources since Java doesn't see files within a jar. So don't try to read the image into the program via new File(...) but rather SomeClass.getResourceAsStream(...)
i.e.
BufferedImage myImg = ImageIO.read(getClass()
.getResourceAsStream("/images/myImage.jpg"));
Yes, a .jar is what you need. It contains all your files in a runnable form.
http://docs.oracle.com/javase/tutorial/deployment/jar/
You could either package the file into the program, which could be accomplished with a jar file as you mentioned. Jar files are archives that can hold classes, metadata, resources (such as images) and anything else you want.
An alternate way to go would be to upload the images to a site/server which you could then provide a URL to, such as your own personal site/server or an image hosting site. I'd go with a jar file though, as this approach would require an internet connection to function.
I am currently working on a program to make sitting charts for my teacher's classroom. I have put all of the data files in the jar. These are read in and put in to a table. After running the main function of the program, it updates the files to match what the tables values are. I know I need to explode the jar and then rejar it during excution in order to edit the files, but I can't find any explination on how to rejar during excution. Does anyone have any ideas?
Short answer:
Put data files outside of the binary and ship together with JAR in a separate folder.
Long one:
It seems like you are approaching the problem from the wrong direction. JAR file is something like an executable (.exe) on Windows platform - a read only binary containing code.
You can (although it is a bad practice) put some resources like data files, multimedia, etc. inside JAR (like you can inside .exe). But a better solution would be to place these resources outside of the binary so you can switch them without recompiling/rebuilding.
If you need to modify the resources on-the-fly while the application is running, you basically have no choice. The data files have to be outside the binary. Once again, you'll never see a Windows .exe file modifying itself while running.
Tomasz is right that the following is bad practice, but it is possible.
The contents of the classpath are read into memory during bootstrapping, however the files are modifiable but their changes will not be reflected after initialisation. I would recommend putting the data into another file, separate to your class files, but if you insist on keeping them together, you could look at:
JarInputStream or ZipInputStream to read the contents of the JAR file
Get the JarEntry for the appropriate file
Read and modify the contents as you desire
JarOutputStream or ZipOutputStream to write the contents back out
Make sure you're not reading the resource through the classpath and that it's coming from a file on disk / network.
I'm new to Java. I'm simply trying to build a .jar file of my applet so I can run it from my browser. This is what my directory structure looks like:
C:\java\pacman\src
contains all of the .java class files.
C:\java\pacman\assets
contains about 4-5 images and audio files.
If I try to use the following code:
Image someFile=getCodeBase().toString() + "file.png";
The result of getCodeBase() is
file:/C:/java/pacman/bin/
However the following code fails to load:
img=new ImgHelper(getCodeBase().toString() + "assets/");
ImageIO.read(new File(img.getPath("pacman.png")));
Moving my 'assets' folder to the 'bin' folder didn't fix this either. It tries loading:
file:/C:/java/pacman/bin/assets/pacman.png
saying:
Can't read input file!
But the url it gave opens fine if I paste it into run and hit enter:
So to avoid myself a lot of headache i commented out the code in my ImgHelper class and did this:
public ImgHelper(String dir)
{
//this.imgDir=dir;
imgDir="C:\\java\\pacman\\assets\\";
}
Which works perfectly. But I want to put this on a web server, and I have no idea how/what I should do to make all the images and sounds work. Any ideas?
Thanks...
Why not put it all in a JAR file and then call Class.getResourceAsStream?
A JAR file is better as it is a single HTTP connection rather than one HTTP connection per file. It is also much more flexible to use a Stream than a File.
getResourceAsStream will work when the files are not in a JAR as well, they need to be relative to the class file.
EDIT:
Another thing, the File method won't work if the applet is on a server as it will be trying to open the file from the local machine (I think, I haven't tried it) rather then from the server. Even if it tried to create a file path to the server that won't work.
I agree with tofubeer about the JAR, but if you want to put the image on your server, see the tutorial on Applet images here. The codebase will be whatever location your applet is on the server, and you can put images relative to that on the server as well. Use a media tracker along with the Applet.getImage() method to retrive the url. From the example:
my_gif = getImage(getDocumentBase(),"imageExample.gif");
There are two possible solutions that would work:
The images could be present outside the applet JAR. The applet could then be initialized with the location of the directory where the images are present. Once you have that information you could then load images from the server. The Sun Java tutorial provides an example usage of the applet parameter to pass the image source directory.
The applet class loader could be utilized to load the images from the applet's JAR, using the getResourceAsStream() method.
PS: It would be helpful if you referred to the section in the Java tutorials to load icons for your application. The same section discusses a lot of the points brought forth by TofuBeer and John.
EDIT : The usage of the File API is not recommended because it ends up reading off the local file system. That is unacceptable for most users on the internet.