Firstly i'm 99% certain my path isn't wrong since it's the copied qualified path of the font file. I have no clue why java can't find the file, please help?
Picture of the error code and my code to load up the font
http://i.imgur.com/uEcAIxd.png
The problem is likely that the 1game project isn't on the classpath for your Eclipse run configuration.
Since you're using Eclipse: Click on the little triangle next to the debug symbol or run circle. Then click on Debug Configurations/Run Configurations. Select the run configuration you've been using. Go to Classpath, select User Entries, and then click Advanced. Add folders, then select the root folder for your project (1game). Try running the run configuration again.
It should be noted that this is only a solution to get your code to run provided that the folder where the file in question exists will also exist at the same path after you've deployed your code. Since you've hard-coded the path in, I'm assuming this is the case. However, you might want to confirm. If the resources will be packaged in the jar with the rest of your code, you'll want to use Assets.class.getResourceAsStream instead of a File (Thanks to MadProgrammer for pointing this out).
Related
The file’s getAbsolutePath has the tendency that if a relative path or just the file name is provided in the file constructor, then it will resolve the absolute path by prefixing the current working directory.
The definition of current working directory is the directory where we run our Java Program.
In my example, my java program resides inside D:\my-app\src\App.java
When I do a System.out.println(System.getProperty("user.dir"));
Then it should ideally print D:\my-app\src
But it is actually printing D:\my-app
Why is it so?
When you start an application from IntelliJ, its working directory is set according to what's set in "Working directory" in the "Run/Debug Configurations" dialog.
There, you can set the working directory to a fixed value such as D:\my-app\src. Another option is to use a path variable. The list of variables that are available apparently can depend on many things - open the dialog and see what's available. One option that I see is $FileDir$ which I imagine would be the directory of the source code file.
I think I found the solution. Intellij was actually causing the issue by implicitly setting the src folder as the source folder. I found it by going to the module setting within Intellij.
When I ran the same from a command prompt, the correct working directory i.e. D:\my-app\src\ is selected.
I'm a little confused by this error. I'm new to Java and the error seems pretty self explanatory, but I've checked my paths (even defined my own) and it still fails to find this library. Is there something I'm doing wrong? See directory screenshot and error screenshot below:
UPDATE
UPDATE 2
If I create a new NetBeans project this works fine. Same code and everything. If I create new IntelliJ project I get this error above. I must be missing something in IntelliJ
UPDATE 3
Found the solution. Adding dependencies is a bit different in IntelliJ. Thanks all for the help.
http://www.jetbrains.com/idea/webhelp/configuring-module-dependencies-and-libraries.html
Obidisc4j is a .jar file. You just dont see its extension in the explorer.
Regular jar files are not loaded by System.loadLibrary. They are automatically loaded by the JVM's classLoader.
You are using a native library. It doen't matter if that library is in the classpath. There are 4 ways you can make the Java runtime load your shared library at runtime:
Call System.load to load the .so from an explicitly specified absolute path.
Copy the shared library to one of the paths already listed in java.library.path
Modify the LD_LIBRARY_PATH environment variable to include the directory where the shared library is located.
Specify the java.library.path on the command line by using the -D option.
Seems like your application is trying to find out a obidisc4j.dll (for Windows) or obidisc4j.so (for Linux). The file must be present on the PATH (but not the classpath). If you are not sure what PATH is your Java application searching in, you can write the following statement, before the point where the exception takes place, to find out the PATH.
System.out.println(System.getProperty("java.library.path"));
This will tell you about the paths where your DLL or SO file should be placed. You just need to place the file in ONE of those N-paths.
I know this question has been asked many times before, but none of the proposed solutions resolve my issue (or I'm not implementing them correctly).
I'm developing a plugin for OpenFire, and when I set a breakpoint in my plugin source Eclipse reports "Source not found". The JAR is built separate from the build of the OpenFire server. I've tried adding the JAR and specifying the source code directory, but no dice.
Here's the process I'm following: When I hit my breakpoint I'm clicking "Edit Source Lookup Path", clicking "Add", Java Library, User Library, click User Libraries, adding my library (tried both "Add JARs" and "Add External JARs"), and then specifying the folder that contains the source code. I've also tried:
Adding the source by selecting "File System Directory" instead of "Java Library"
Adding it by selecting "Workspace Folder"
In the Project Explorer, adding the source for my plugin to the Java Build Path
In the Project Explorer, adding my JAR as a Library and specifying the Source attachment
Thanks in advance for any suggestions.
Personally, I have no good experience in Eclipse JDT, when adding a source folder at the time it hits a break point. What I always prefer to do, is adding the source folder before debugging:
Select Project/Properties/Libraries
Select your library and "edit..." the source attachment
Select either the corresponding source folder or the zip/jar containing the package
After that, you should be able to open the source files in the virtual "Referenced Libraries" folder (directly below the "JRE System Library" folder inside the project), or when opening a reference to a linked class file from within the JDT editor. If you are able to access the source, then you should also be able to at least stop at the break point and see the corresponding source.
Else, you will have to check again, if the source folder is really valid: The source folder or source archive must contain the folder with the name of the root package of the library (e.g. the default Java "src.zip" inside the JDK folder also includes a corresponding "java" folder at its root). When in doubt, extract the archive and select the parent folder of the package you are interested in - sometimes source archives might be a mess or incompatible to JDT.
If this has been assured and it still doesn't work, chances are, that your linked source folder does not correspond to the compiled version of the library. Usually JDT will handle such inconsistencies fine, but if you try to open a source file, that is entirely different than the corresponding class file, you will encounter problems. In this case I would suggest either downloading the correct source version of the library, or recompiling the library from the source, if all else fails.
If opening a referenced source file from withing the JDT editor does work fine, and you are still unable to open the source files when a break point is entered during debugging, then most likely the class files are missing the line numbers of the corresponding source file. Again, you will have to recompile the library from the source in this case.
Finally, it is also possible to overwrite the default source lookup by specifying source folders or archives in the source tab of the launch configuration. But you should normally not need to do this, when your build path is configured correctly. From the Eclipse Help:
The Source tab defines the location of source files used to display source when debugging a Java application. By default, these settings are derived from the associated project's build path. You may override these settings here.
I had this very annoying problem for a long time but was finally able to solve it. In my case, a null pointer exception was being thrown somewhere in Java's Transformer.IsRuntimeCode(ProtectionDomain) function.
I didn't really need to know about this since the exception was being caught and handled, but eclipse would pause debugging every time this happened and tell me that the source wasn't available. As a result, I constantly had to keep pressing the button to continue code execution.
In order to prevent this from happening, I:
1. Clicked on the "Breakpoints" window at the bottom of the debugging
screen
2. Right clicked "NullPointerException"
3. Unchecked "Caught"
This prevented the debugger from pausing program flow during a caught NullPointerException.alt text
(source: SharpDetail.com)
And this another one as:
Eclipse doesn't crash. You're trying to step into a method, where eclipse doesn't know where to find the source (*.java) files and informs you about this. Here is how to tell eclipse where to look. Go to
Window->Preferences->Java->Installed JREs,select the JRE you are using and click Edit.
There, select all of the jar files in the list you see and and click Source Attachment....
In the window that shows up, select the fille src.zip, which is in your JDK folder (if you didn't uncheck it while installing the JDK). On the machine I'm on right now, that is
C:\Program Files\Java\jdk1.7.0_07\src.zip.
Save all your changes (possibly restart eclipse) and you won't see that error again.
Well it turns out the solution was anticlimactic. When Balder's recommendations did not work I tried debugging one of the stock OpenFire plugins and it worked just fine. I then created a new plugin from scratch, and by doing nothing other than adding the source to the project (Right-click on the project -> New -> Source Folder) it also worked just fine. I have no idea why Eclipse refuses to see the source for my original plugin, but I moved all my code and libraries over to the new plugin and debugging is working as expected.
Many times you put jar files in eclipse IDE as referenced libraries when binary version of application was downloaded. Usually done so by configuring the build path. But the binary does not have the source files. You have Binary version and source version of application.
One simple way is to download the source libraries that you also use maven to build the project.
Keep somehwere, may be inside your project workspace.
Now while seeing the class file (from eclipse, jar exploded) you may see the source not found, fine.... there is a button below and click on that, a new window opens and there select add external folder.
Reference it to the src folder of the source you downloaded(not the binary one) and kept somewhere as said above and it will show the class details from that.
I fixed this issue with doing the following:
Click at the menu Window - Preferences - Debug - Step Filtering And check all the packages like the following image.
(Step Filtering)
Then, debug again your project and thats it.
Best regards,
In my case, I had a breakpoint in the class declaration. I mean in the next line.
public class GenerateInterface implements JavaCall {
So, the debugger stopped in that line and showed the following message:
Source not found
I think unconsciously activate the breakpoint in that line.
This is a really common error, because there are tons of threads about it, but I'm not sure if since my situation is slightly different from all of them the solutions don't work?
Basically, I'm in eclipse. I have a source folder called src, then I have a package that goes down three folders, then the class in question. The class uses the code:
BufferedImage im = ImageIO.read(Thread.currentThread().getContextClassLoader().getResourceAsStream(filenames[x].concat(extension)));
surrounded by a try/catch. filenames is an array of all the file names I am loading (this code is run multiple times in a for loop) and extension is ".PNG". The pictures are located in another source folder called EngineTextures.
Running this program works fine in Eclipse! All textures are loaded and all my other code runs! However, I export it as a runnable jar and run it in command prompt to recieve input == null errors on all of them, pointing to the line that has ImageIO.read(Thread.currentThread() in it.
The kicker is this whole thing worked in a separate project before, and when I even tried re-exporting that project, I recieve the same errors on completely unchanged code. This leads me to believe I have some obscure Eclipse setting changed wrongly.
Opening the jar, my MANIFEST.MF has a version of 1.0 and a classpath of just plain ., which I thought was correct for this kind of thing? The Main-Class points to the right place, and all my pictures are right there next to the META-INF folder.
Solutions I've looked at unsuccessfully:
getResourceAsStream working in eclipse, but not when run as applet in browser
Why does getResourceAsStream() work in the IDE but not the JAR?
Java IDE - Eclipse, Importing resources
Audio file in jar made by Eclipse IDE
getResourceAsStream() returning null in jar but fine in eclipse
Additionally, I completely deleted the workspace and recopied my pictures and code into the same state, thinking maybe some .metadata thing was wrong, to no avail.
Thank you, in advance, for any and all help. I hate to make a repeat like this but no solutions have worked thus far. Please let me know if I have not given any crucial information.
Opening the jar, my MANIFEST.MF has a version of 1.0 and a classpath of just plain ., which I thought was correct for this kind of thing?
No. The Class-Path entry in a JAR file names other JAR files, relative to the location of this jar file. It doesn't name directories:
"The value of this attribute specifies the relative URLs of the extensions or libraries that this application or extension needs."
That in turn implies that resources to be loaded via getResourceAsStream() must be in JAR files.
I want to create a runnable JAR that include referenced libraries, namely jackson, in eclipse via the export. There used to be fat jar that seemed to be the goto solution before Eclipse offered to export to runnable JAR.
From this question, the first option would be what I'm looking for. Since it is for the moment a small project, it wouldn't be a problem to always have everything together (plus it's easier for me since I'm just starting with JARs, runnables and jnlp)
When I try to launch it, there's an alert window saying there was a problem and to try to find it in the console (which I can't get to open).
If I remove any use of this referenced library everything runs perfectly (except the part that it's not doing what I want at all). The window looks the way I designed it, but no functionality without the library.
I don't even have a stack trace to help with the problem. I've created other projects without any referenced libraries and everything is fine. So I've pretty much narrowed it down.
Since I let Eclipse handle the exporting and everything, I don't suppose you need the manifest to see if it is alright. Any questions you might have, I'll provide the informations you need. It goes without saying that the project runs directly from Eclipse.
Eclipse
Version: Indigo Service Release 2
Build id: 20120216-1857
Edit following Baqueta's answer
What happens when I do that is that I get a custom RuntimeException. I'm a bit baffled here. Here's a simple explanation of my code.
I have a utility class (UtilityJSON) that uses the referenced library (jackson). The constructor of that utility class instantiate an object defined in the referenced library, let's call it mapper.
A method of UtilityJSON uses a method of 'mapper'. At this point the exception is raised. Why I'm baffled is that 'mapper' is succesfully instantiated but using its method raises an exception. If the jar couldn't find the referenced library, it probably couldn't create the object 'mapper'. But running the project from Eclipse is all fine.
Is there any way to debug when running an executable jar? Maybe echo something in the console.
Edit 2
I may have found the error. My program reads a *.txt file in a folder inside the project. When exploring the content of the jar I see that this folder was not included, thus the exception. So the question now becomes: how do I include this folder? It's in the root folder of the project.
You could try the following:
In Eclipse, go to Project->Properties.
Select 'Java Build Path' from the column on the left.
Select the 'Order and Export' tab.
Find 'jackson' in the list and make sure it's checked.
EDIT
To answer your updated question:
In Eclipse, find the *.txt file in the Package Explorer. Right-click it and select Build Path->Add to Build Path. Then follow the instructions above to make sure the file gets included in the Jar. Finally, do a clean and rebuild.
If you're ever going to add more resources, it is common practice (and makes sense!) to have a resources folder (often called 'res'). You can then add the entire folder to the build path, so that all the resources in there get included in the Jar.
Enable the java console by writing
javaws -viewer
in a terminal. Close the Cache Viewer and click the advanced tab. There open Java-Console and click "enable console".