Develop Reference

Eclipse creates an html file on desktop, instead of in the workspace

I'm working on an application and I dynamically create an HTML file using Java in Eclipse. The problem is if I do not specify the path where the file will be created, eclipse creates it on desktop, instead of in the folder of my project in eclipse-workspace. Is there a way to save it in the folder without specifying the path? Thanks!
File f = new File("distance.html"); //creates a file on desktop

There mostly isn't; the concept of a 'workspace' is not going to be there when you run your application outside of eclipse, and eclipse is just where you write the software. It's not where you run it 'for real' - you may run it there, but only for the purposes of debugging.
However, in the run target (main menu > Run > Run Configurations...), find the run config you are using. You have the option for 'Working directoy', which is in the 'Arguments' tab.
The default is your workspace, you have either messed with this setting already, or something weird is going on. Set this back to your workspace (usually via ${workspace_loc:projectName} as a value, or just.. pick 'Default' again.
new File() does not create anything, it's just a simple pointer to a file. However, relative paths are resolved relative to 'current working directory', which you can set with that option.

How to make File class use relative paths?

I've been working on a project in java for a while now. I realized something terrible when trying to run a .jar of the project: It wasn't using relative paths anymore, instead it was searching in the "C:\Users\Username\..." directory for files.
I read that instead of using new File("..."); you should use getClass().getResourceAsStream("...");
In a lot of places I used things like new Sprite(new File("sprites\\sprite.png"));, so it would take a very long time to go in and replace all of them.
I was hoping that there was something else I could do instead.
Like, is there any way to change the behavior of the File class?
Any tips? Thanks.
EDIT:
I tried Duran Wesley Harris's idea of setting the user.dir property to the path of the folder with the .jar, which actually successfully changed where the files were being looked for. But the program still fails to load the files. I can actually copy the directory it's using into File Explorer and load the file that way, so it's mysterious to me why it can't load it in the program.
Note: The files are not inside the .jar, they are sitting next to it in the same folder. Also, the program works perfectly in the IDE (IntelliJ Idea).

Personally, I think you should take the time to refactor your code to use xx.getResourceAsStream() methods.
If you want to try and make a hacky solution you could try setting the "user.dir" property to the root of the jar with System.setProperty() or java -Duser.dir="" via command line.

Why can't I create a folder in %CATALINA_TMPDIR%?

This is the weirdest thing ever. I'm working on an app that I run using Tomcat though IntelliJ IDE. Part of this app creates a folder in the configured %CATALINA_TMPDIR%. For some reason no matter where I point %CATALINA_TMPDIR% to java can't create a folder there, but it can create a folder everywhere else.
For example, If
CATALINA_TMPDIR=C:\Users\dallend\.IntelliJIdea14\system\tomcat\Unnamed_datasite_7\temp then my app can't create a folder there, but can create it in C:\Temp, a folder I created.
Then if I change to CATALINA_TMPDIR=C:\Temp, the app won't be able to create a directory there but will be able to create one at C:\SomewhereElse.
From debugging through things it appears that java.io.File tries to create the directory but that the WinNTFileSystem.public native boolean createDirectory() method can't successfully create it.
Why might this happen? Could there be something I need to tweak with IntelliJ, or Java, or my OS? Has anyone encountered this before?
EDIT: I've tried running Tomcat stand-alone, and the problem persists.

Try to use forward slashes in your directory names. I've pulled out a lot of hair with backslashes actually escaping a path, e.g. C:\temp pointing to C:<tab>emp. I've completely given up on using backslashes even on Windows: Java will translate forward slashes just fine: C:/temp/

How does a JNI DLL search for its dependent native DLL?

Say I have JNI.dll. It depends on native.dll. Now my Java application calls System.loadLibrary("JNI").
Will the following folder layout work?
MainFolder
|--main.exe
|--SubFolder
|--JNI.dll
|--native.dll
My guess is, there are 2 levels of dependency resolution.
[Level 1]:
System.loadLibrary("JNI") uses JVM property java.library.path to locate JNI.dll.
[Level 2]:
JNI.dll relies on Windows system mechanism to locate native.dll.
Is this correct?
If I set %_JAVA_OPTIONS% as -Djava.library.path=MainFolder\SubFolder, I think it can cover the search for JNI.dll. But will it cover the search for native.dll, too?
ADD 1
It seems my guess of 2 levels got confirmed from here: How to add native library to "java.library.path" with Eclipse launch (instead of overriding it)
See comment by kevin cline. But the mentioned solution with LD_LIBRARY_PATH environment variable only applies to Linux.
ADD 2
I think I didn't make my question clear. Let me put it this way.
My confusion is: the JNI.dll depends on native.dll. Both of them are not in the main.exe's current working directory. Actually they are in a sub folder of CWD.
If I run main.exe directly, I just need to set the java.library.path = <other path>\MainFolder\SubFolder. Both DLL are found correctly.
But if I run my project from Eclipse, besides setting the java.library.path, I have to put the "\MainFolder\SubFolder" in the %PATH% environment variable.
I just don't know why Eclipse is so different.

1)It searches in the current Directory.
2)System folder typically C:\Windows\System32 (use CSIDL_SYSTEM with shgetspecialfolderpath() to get the rigth folder on the given system)
3)Windows folder (C:\Windows )(CSIDL_WINDOWS with shgetspecialfolderpath() to get the right folder on the given system)
4)All the folders listed under PAth environmnet variable

A similar link: Must I place all dependent DLLs into the JDK's bin folder?
Inspired by this thread:System versus user PATH environmental variable...winmerge works only if I add the path to the user PATH
I start to wonder maybe my User %Path% is too long. So I moved the folder path containing my dependent DLL from the end of User %PATH% to the beginning. It works now!
At first, I conclude that one who implemented the Windows' DLL lookup algorithm has some truncation issue. And I almost consider it as another annoying Windows Bug.
But I wrote another Windows application which has similar DLL dependencies to confirm my guess. That application works fine! So I have to review my conclusion.
I checked my User %PATH% entry one by one, and place the folder to each possible location. And finally, I find the root cause.
I have a C:\MinGW\bin entry in User %PATH%, which happens to contain a
libstdc++-6.dll (977KB) but unfortunately, which isn't compatible
with the one I need (825KB). It only works if I place my folder before MinGW.
Now this issue seems resolved. But another one comes up, do I need to switch back and forth if I want to use both my DLL and the MinGW?

Java App unexpected behavior when exported

I have a very strange problem, that I can't figure out, the thing is that my aplication runs perfectly on the IDE (Eclipse), but not when exported, when I run the jar (double click) the aplication start but some functionality is missing (loading from a template file, but this does not happend when loading from a normal file), when I try to run it from console (java - jar my.jar) in order to see any error message it turns out that my aplication works perfectly fine! :S ...
Some more info:
My app is running over windows 7
I start the task manager, and I noticed that when I start my aplication using double click its under the name java.exe *32, and when I do it from command line its under the name java.exe (without "*32"), as far as I know I programmed nothing related to a 32 or 64 bits functionallity.
"Solved"
Well I was not able to solve it the way I wanted, as far as I was able to find, i found that there were a problem between the 2 java versions I was running x32 & x64, I deleted the 32 bit version and it start working as a charm, but I'm still not sure about what happend, I give my thanks to #Sajal Dutta one of its comments help me to understand part of the problem, thanks to all of you anyway, I'll keep searching until I find the problem...

When you create a jar from Eclipse, your assets don't get copied over to jar or location is not preserved. Open the jar and check if you have your templates in the right location or you have it at all.
To have the exported jar include your assets/resources-
Right click on your project in Eclipse. Then New -> Source Folder.
Name the source folder anything. e.g. template_src.
Copy or drag the entire directory of your template to template_src. Then make the jar.

Since it works via the command line but not when double-clicking the jar, it is likely that the working directory is different (and that you're loading the template with a relative path). When you run an executable jar by double-clicking, on some operating systems, the working directory is the home directory whereas when you run from the command line, it's the directory you're currently in.

The "files" in the jar are not handled by File, but are resources;
URL url = getClass().getResource("...");
InputStream in = getClass().getResourceAsStream("...");
Then, the file paths inside a jar, or on a non-Windows platform are case-sensitive.
"Template_A.xml"
is not
"template_a.xml"
Also you might inspect the jar with 7zip or WinZip.