I am running Windows 8.1, Netbeans and Java 7. I have a jar file sitting in the dist directory, on the "C:" drive. (Netbeans automatically creates a "dist" directory to store the jar files it deploys.) When I run the jar and specify the "dist" as a target directory, my program is able to create files in "dist" using "createNewFile". (My program can also read from and write to the new created files).
My problem is that my program does not seem to be able to create files elsewhere on
the C: drive, under Windows 8.1 (It is able to do so under Windows XP.) To be more specific, createNewFile does not create a file, does not throw an exception, and a System.out.println ("Message") statement placed directly after the createNewFile statement does not execute. No errors are reported anywhere. I have tried to deactivate User Account Controls but no avail.
Does anyone know directories in Windows 8.1, outside of "dist", to which my program could
successively write files and this without having to call upon administrative privileges? Thank you.
Related
I try to make a setup with Inno Setup for my program.
I have installed more file XML in the same folder as the .exe. The install work well, but when I run the program and modify the XML, the file is saved in another place, not the folder of the .exe and I can't find it. I think the file is stored in the PC because the program can open it without problems.
I also try to make the same setup with InstallAware Express 7 and it works well. Io I think it's not a problem in my exe but in Inno Setup.
Thanks
I think you are a victim of Windows File virtualization.
You probably install data files to Program Files folder.
That folder is not writable (unless your program runs with elevated privileges). If your program does not have application manifest, Windows considers it a legacy application that is not aware of its inability to write to Program Files and enables file virtualization. So, when your application tries to write the data/XML files, Windows redirects the write (and future reads) to a virtual store (C:\Users\username\AppData\Local\VirtualStore). The actual files in the Program Files are not modified.
It's difficult to answer, why it works with the InstallAware Express. If you tried it after the Inno Setup, the results can be affected by an existence of the file in the virtual store.
Anyway, the root cause is that your application tries to write the files in the Program Files. That's just wrong. No application should write to Program Files.
See also Application does not work when installed with Inno Setup.
I’m doing a little Java project that deals with files (ppt files ), and I want to incorporate this files in the program (jar) so that those file can be open on every computer without having to add them all the time.
I have try adding them to the source file but it doesn't work they don't open.
It's there a way so that once I create the jar of the project I can run it always (with the file in the jar ) ?
I wrote a program in Java and packaged it up as a Mac App using Netbeans. It has the typical Java, MacOS, Resources, and Plugins folders and works just fine. The problem is that my program has a save feature which, whenever used, saves files to the computer's User directory instead of the directory in which the program itself is running—the Java folder.
In the past I got around this with a custom executable containing the lines
# Set the working directory
DIR=$(cd "$(dirname "$0")"; pwd)
cd $DIR
But since Netbeans creates the executable now and encodes it in some unreadable way, that's not an option. I would use the old one but Netbeans adds the benefit of bundling a JRE with the program so I'm stuck having to choose between saving in the right spot or bundling the JRE.
Does anyone know how to change the working directory of a packaged program?
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
EDIT:
I took Tyler's advice and decided to find the directory I wanted within the program itself instead of trying to change the PWD with scripts.
Say you're running a Jar file by double clicking it or using terminal/cmd (This only works by directly running, not through ANT or an IDE). This will give you the directory that your Jar is in:
String path1 = MyClass.class.getProtectionDomain().getCodeSource().getLocation().getPath();
String path2 = (new File(path1)).getParentFile().getPath();
String PWD = URLDecoder.decode(path2, "UTF-8");
The first line gets the path to your Jar file.
The second line
removes the name of the Jar from the end, leaving you with the
directory it's in.
The third line accounts for special characters
like spaces.
I'd use something like
System.getenv("HOME");
to find the user's home directory instead of changing Java's working directory.
I have a program that I want to publish that was built using Java. At the moment, the program creates folders / files in the directory:
"C:\Users\Steve\Documents\myProgram"
This obviously won't work unless the users have the exact same folder structure. How do I direct the program to a folder on the desktop? As the path "C:\Users\Steve\Desktop" wouldn't work.
Publishing the program using NetBeans creates a .jar. As I want the program to be used by many people, is it possible to create a batch file that using commands:
Creates a folder onto the desktop (that stores the program files created through the program)
Then launch the .jar
I could then get a converter and change the .bat to .exe. I'm not sure if this is the correct way about it.
On a side note, I'm pretty sure this wouldn't work as the user would still need Java installed to run the program. I'm not 100% sure, hence me asking.
How do I direct the program to a folder on the desktop?
File desktopDir = new File(System.getProperty("user.home"), "Desktop");
File myFile = new File(desktopDir, "myFile.txt");
I have created an executable java Swing .jar application. It works fine on Windows. The application hierarchy is :
application.jar
images(Folder) .......... Contains all images the application uses.
libraries(Folder) ....... Contains all external jar libraries the application uses.
bundles(Folder) ......... Contains all bundle files the application uses.
database(Folder) ........ Contains the database files the application uses.
All the above folders exist outside the jar file. Now i am trying to create a Mac executable file (.app) from "application.jar" to run it on Mac so i used the "Jar Bundler" as specified here but when i run the output application.app file nothing happens, nothing runs and i can't even debug it.
I think the main reason is that it can't see the external folders. So is it impossible to create a .app file if the application has external folders ?
And is there a way to debug the .app file to see what's going on ?
Nothing runs, and i can't even debug it.
Diagnostic output from the launch process may be obtained as follows:
$ export JAVA_LAUNCHER_VERBOSE
$ ./YourApplication.app/Contents/MacOS/JavaApplicationStub
There's a related example here.
Most likely the problem is your working directory.
When you run an executable JAR file by double-clicking it, the working directory is the parent directory of the JAR file.
By default, the working directory of an application bundle is its parent directory. If you package the external folders into the application bundle they will be located under $APP_PACKAGE/Contents/Resources.
So the assumption about the working directory that you make for an executable JAR file does not hold for an application bundle.
In order to set the working directory to the resources directory, add
<key>WorkingDirectory</key>
<string>$APP_PACKAGE/Contents/Resources</string>
to the Info.plist file of your bundle.
In case you know nothing about application bundles, please read this document.
This might help: AppBundler by Josh Marinacci
I am not sure about your exact directory hierarchy. But on a Mac with Xcode installed is an application called "Jar Bundler". It exist for exact that purpose you are asking for.
BTW, Mac application use the suffix .app, that is right. But they are not files. Thery are directories.