File initialization fails outside of Netbeans

[Adam Nadeau]

I've built a custom fantasy football draft application that I will be using in a few days. I have all of the logic working and the GUI close to pinned down, so I thought I would try to make life easier by packaging the player data file with the program. I changed this code:

JFileChooser fc = new JFileChooser();
fc.showOpenDialog(null);
playerSource = fc.getSelectedFile();

to this:

playerSource = new File(MingyaValleyDraft.class.getResource("/data/playerlist.txt").toURI());

and it worked great. Until I closed NetBeans and tried to run the .jar file directly. The .jar file runs fine with the JFileChooser code (I tested it on two computers, Mac and Windows). With the getResource code, the app fails to launch completely. In NetBeans, my project tree shows
MingyaValleyDraft
    v Source Packages
        v data
            playerlist.txt
        > mingyavalleydraft
    >Libraries
Are there additional steps that the IDE takes to include the file that aren't necessarily taken when the .jar is built?

[Mike. J. Thompson]

In order to be available as a resource "/data/playerlist.txt" needs to be available on the classpath, either by being contained inside the jar or being stored outside of the jar somewhere on the classpath.

So, where is that file when you are running your application? What are the contents of your jar file? And finally, exactly what command do you use to run the application?

[Adam Nadeau]

Honestly, I stuck the file in a folder ("data") under the "src" folder in the NetBeans project folder assuming that NetBeans would include the file in the .jar file automatically. The fact that the new code worked when run from the IDE gave me some hope for a minute there. Is there a process that needs to be followed to make NetBeans include the file in the build?

[Mike. J. Thompson]

I'm afraid I don't know how to get netbeans to do that because I do not use netbeans. You can check whether the files were added to the jar simply by opening it. It's a zip file so any of the standard zip utilities should be able to display its contents.

You may also want to step back from netbeans and manually create the jar. This will help you understand what is going on under the hood and help you be able to identify what is wrong when things like this happen.

[Adam Nadeau]

Okay, I opened the .jar file and found three folders in it: "mingyavalleydraft", which holds all of the class files, "META-INF" with the MANIFEST.MF file, and "data", which has my playerlist.txt file in it. I was assuming that the .jar file is the root of the package, which means that /data/playerlist.txt would or should be a valid reference, but clearly there's an error in this logic. What bothers me most is that the class.getResource() call works fine from the IDE, but the whole program fails when I run the .jar file. In reality, I can live with the JFileChooser call; I only need to open one file, and I'll only be running the app once (for now). I just figured that the automatic retrieval would save me the steps of digging through my hard drive to get the file (it's buried pretty deep in the directory tree), especially while I'm testing things and running the code over and over again. I may try a few more things to see if I can make it work, but I have more important logic to tweak in the next two days, so I'll probably just end up putting on the back burner until I upgrade the app for next year. Thanks for helping.

[Knute Snortum]

Using this pattern helped me open a file from the IDE and running a .jar file: (I am using Maven)

File in src/main/resources

InputStream in = getClass().getResourceAsStream("/myDataFile.txt");
try (BufferedReader br = new BufferedReader(new InputStreamReader(in))) {
...

[Adam Nadeau]

As I learned late last night, the magic bullet is getResourceAsStream(). The getResource() method was failing because the path only exists in a single .jar file, not in the file system, so the OS can't resolve it. I wrapped the right code in a Scanner and everything works now.