executable JAR file not showing resources - java

i created an executable JAR file using eclipse.. I have resources in the project folder that
does not appear when the frame is open..I mean when i double-click on the JAR file. More
so,After I try to delete the JAR file I get a warning that the JAR file is being used on the
Java Se platform .How can I eliminate this problem other than using a resource loader class?

Some times when we run a jar file the resources gets used by jvm and they are not released due to this we cant delete the jar file.So trying killing the processes from the task manager so that you can delete the jar file.For me killing explorer.exe worked.Try killing that process andf then try deleteing jar file.

Use ClassLoader to get the InputStream if your resources is in the source folder.
ClassLoader.getResourceAsStream(String name);
Close your application before you delete the JAR file. Or explicitly exit your application with the following code.
System.exit(0);

There can be a possibility that the resources are not exported at all. Sometimes it happens that you need to tick the check box against each resource name and then hit finish while exporting it with Eclipse.
Also, please check that there is no warnings when the export process is finished.
Kill all the java.exe and javaw.exe process from task manager and then try to delete.

Related

How to delete the Executable Jar File by it self?

I developed a simple java application ,is it possiblefor the application (Executable Jar File) to find its current path and delete it self from both the current place and from Recycle Bin after a certain time.
No, when java runtime starts and uses this jar file, windows prevents it from being deleted. In other operating systems like Linux you can delete files even if they are used.
There are already questions/answers that show you how to get the currently running jar file. Keep in mind, the methods aren't consistent across platforms:
How to get the path of a running JAR file?
Deleting a file in Java is fairly straight forward as well:
import java.io.File;
...
new File("c:\\path\\to\\whatever.jar").delete();
On an operating system that doesn't have file locking, you can simply delete the jar you're running from as it's already loaded into memory. On operating systems that lock files, this may not be possible if the JVM decides to lock the currently executing jar(s).
Windows strictly restricts you from doing this untill the jar is in use
It is something like this :
In Linux you can do it here is How to delete a executing jar file
In order to delete the jar file, I recommend:
Creating a bat/sh file
Run the file
Close the jar file with System.exit method
Within the bat/sh file:
Loop until success deletion
Delete the bat/sh file within itself(unlike the jar file bat/sh file can delete itself)

How to execute a program within a Jar file

Soo my problem is, that I made some kind of launcher and wrote a method that is being called if you click on the "play" button.
private void PlayButtonActionPerformed(java.awt.event.ActionEvent evt) {
try
{
new ProcessBuilder("src/calc.exe").start();
}
catch (IOException ex)
{
Logger.getLogger(Launcher.class.getName()).log(Level.SEVERE, null, ex);
}
}
The file that is being executed is just a copy of the calculator from Windows and
is in the src folder of my project. (Path is "src/calc.exe")
Everything works fine AS LONG as I don't compile my netbeans project file into a JAR file.
If I run the JAR file and click on the play button - nothing happens.
I really hope you can tell me how to fix this.
(P.S.: calc.exe is not always the name of the program to be run. The filename is determined by an .ini.
calc.exe is only used to test the program.)
First, some context:
A JAR file is an archive, a package (compressed or not) that contains Java bytecode and other resources that can be consumed from inside a JVM.
An EXE file is executable binary file that can only be understandable by Windows/MS-DOS family OSs.
When you run your program without packaging it into a JAR file, all resources (the class file and the executable) are accessible from the OS. Windows will launch the JVM and from inside there you, by means of the ProcessBuilder, instruct the OS to invoke an executable file accessible in a path which is relative to the class performing the execution instruction. Until there, everything is fine and as you said, it works.
However, when you pack your Java class and the executable file in a JAR and invoke the JAR, its contents are no longer accessible for the OS. What is happening is that the OS will launch the JVM and it will process the JAR file to find the executable class (the one in which you invoke the ProcessBuilder). From that class file you now instruct the OS to launch an executable which is in a path relative to the JAR file instead of being relative to the class file performing the invoke instruction. Since the EXE is inside the JAR file instead of being relative to it, execution fails because it can't find the executable.
This is that way because the OS won't look inside the JAR file for a specific file, for the OS the JAR file is just that, a file, not a folder so it will ignore its contents.
So, the conclusion is that, since you are invoking the OS to perform a specific operation in another file, just must place that file outside the JAR and in a relative path to that JAR.
If for some reason you insist on packaging your EXE inside the JAR, then you need to extract it outside the JAR before invoking the ProcessBuilder to a temporary folder and invoke the ProcessBuilder using that new path.
This is sort of a touchy subject.
Whoever commented that JARs are not able to do this is wrong. To the contrary, it is applets that do not have such a permission unless they are signed and validated by the author through Oracle.
You said that it all works fine unless you put it in a JAR. That is probably because of your URI being relative to the Windows filesystem.
The way to usually get the file regardless of the packaging around the reference is to do something like this:
MainClass.class.getResourceAsStream(file);
The static getResourceAsStream will parse the available relative and absolute paths, and if you put your "src/calc.exe" here, it should work.
Another suggestion is to thread the process opening. If you have the program as a single thread, the Java program will hang until the external process is gone and cleaned up.

Why does a runnable JAR exported from Eclipse continue to use old configuration settings?

I am exporting a runnable JAR from Eclipse. When run, it reads in a configuration file and based on this configuration file opens other files also for configuration purposes. However, when I move this JAR to another location it continues to try to use the values in the old configuration file, even though a new configuration file is present. Why does it do this?
The problem may be that the file is included in the Eclipse build path, so when it gets exported that file is built with the JAR. Then, regardless of whatever path is given for the configuration file on the command line, the JAR will use the file that was already packaged inside of itself. (This was my problem. Removing it from the build path resolved the issue.)

why doesn't my jar file run outside netbeans?

I built a jar file that can run perfectly within netbeans when I click run,
but when I try to run the jar file by double clicking it it does not run, nothing happens..
Double-clicking the jar starts it, but unless you have a GUI application that opens a new window (in a different thread), it most likely finishes and closes before you can see anything.
In these cases you normally run the jar from the console (java -jar ..) to see if there are any exceptions/errors.
Starting an application from the command line would let you debug the problem as Bozho said. But you need to check if you have all the files in dist folder that you need to run your program. For example if you are using a database file to get the data, you need to place this file in the dist folder after program is built. I think the jar file is using a relative path when looking for files.

Add files in jar during runtime

Project is to create exe file. If we run exe file it will open one admin page (designed in Swing) that page contains browse button, max install, max install sys, and create build, while click the browse button we need to select one exe file from system and that file need to save it inside one folder of jar file. The maxinstall, max install sys value is stored in SQL lite database. This admin page will open for first time only,to get condition from admin. Next if we run the exe file it must check maxinstall and all parameter and then install that selected exe file.
My problem is, I created jar from my java program. While running the jar each time, the admin page only opening (i.e) the database file is not updated inside jar, but its works fine in eclipse. After that I need to create jar to exe.
..it is possible to extract jar in runtime,addfile in the extracted jar and create a new jar in runtime..?
Most JREs will place a file lock on the Jars. Therefore they cannot be updated while the JRE is running. Check a sub-directory of user.home for an altered version of the resource. If it is not found, use the one in the Jar. If it is altered, save the changed data to the sub-dir.
Use a sub-directory based on the package name of the main class, to help avoid overwriting the resources of another app. (or other apps. over-writing your resources).
I think that I understand your problem. Your application stores its state into its own jar file. the fact that you are using SQLite etc. does not matter. It works from Eclipse because in this case the class files and resources are not packaged into archive and your program changes files on file system easily.
The answer is: yes, you can change jar file programmatically. Jar is just a zip. You can use ZipInputStream, ZipOutputStream, JarInputStream, JarOutputStream to modify any zip including your own.
But it is very very not recommended for too many reasons. The right solution is to separate your data from your application. You have to store runtime data on file system, DB etc. For example you can create files in user home directory. It is platform independent. You can also use Preferences class that has portable implementations for all platforms.
Yet another reason to do this is your requirement to create exe. OK, you can change jar file but once you created exe file from your jar you cannot change it anymore.
Once an executable .jar is created it will be "locked". I you add more files to a locked .jar, those files will not be recognized internally by the .jar itself at runtime. So, the better approach is to extract your dependent .jar and then add it to a new, executible .jar containing the new file(s) that you need. Then moving forward you can run this new .jar.

Categories