About resource path problems when packaging a jar file (ii)

When it comes to the problem of resource path issues encountered in packaging jar files (i), and the resource path code when the resource is detached from the executable jar, I later think about why the Java core Technology Volume One Can the jar files in program 10-1, ResourceTest, be executed anywhere?

Figure: Put the jar that was originally put in the table of contents on the desktop, click still can execute

So I unzipped the jar and found that there are still resources in the package, which means that the package should be in its own jar when it is executed out of the original directory, depending on the resource path. (as to whether the jar is in the original directory based on the resources in its own package or the resources in the directory, I'm not sure, because the resources in the same directory can be interpreted as a URL, as described in the resource path problem encountered in packaging the jar file.)

After decompression:------>

The next question is how to package resources together into a jar package.

method (i): use the jar CVF *.class *.gif in cmd or the wildcard format of the other resource type later, and then use Java-jar Xxx.jar.

Method (b): How to use the Eclipse mode:

Method: Place the resource or file directory containing the resource in a folder in the project folder, and there are two ways to put it:

first of all, note that the package can only be packaged in the SRC folder under the project file, and other places cannot be packaged into the jar package even under the project.

second , the Project Explorer of Eclipse is refreshed every time a new resource is placed in order to properly package

finally , the following two methods will be error at eclipse compile time, but packaged out to run , this is the previous article on the packaging of the jar files encountered in the resource path problem (a) the biggest difference.

================================ body start Split line =================================================

Mode one: Placed under the src file, which is the same as any other package in the SRC directory, this way requires the use of absolute resource location (first add "/"):

For example, in the Imageviewerproject project, the palette.gif is placed in the SRC directory, the same directory as the image package, the package is the main program

Figure: Placing the palette.gif in the SRC directory

Figure: Refresh in Project Explorer blank space in eclipse

Figure: After the refresh you will see that the Palette.gif resource will appear in the SRC directory

The program must use the absolute resource path:

Chooser.setaccessory (newthis. getclass (). GetResource ("/palette.gif");

At this point, the program is exported to a jar package, no need to add resources to the directory where the jar package, you can run directly:

Unzip this jar package to see that Palette.gif is in it, and that the image package is in the same directory:

But it's still a step away from the example shown in Java core Technology, because the sample code uses a relative resource path, so how to do it, the answer is in mode two.

=========================================================================

Method Two: Place the resource in the package where the program is located, and the package is still a variety of. java files before it is packaged:

For example, in the Imageviewerproject project, the palette.gif is placed in the image package in the SRC directory, which is the main program, which means that the resources and source code are put together:

Figure: Put Palette.gif in the source package directory, and the source program put together

To refresh Eclipse:

In this way, the absolute resource path may not necessarily be used in the program, and the relative resource path can be used, and the code can become:

Chooser.setaccessory (newthis. getclass (). GetResource ("Palette.gif");

Now, using Eclipse to package the program, you can run it directly without needing to add resources to the directory where the jar package is located:

This jar is still decompressed to look inside, and in a different way, this time the resource is in the extracted directory, but in the class file in the same package, and bytecode files together:

Open Image Package------->

=============================================================================================================== ==

So you can use these two ways to package the resources together with the code into the jar package, the two ways do not say which good which bad, from the location of the resources can be seen, so the specific situation of specific analysis.

Similarly, both this blog post and the previous article on the resource path issues encountered when packaging jar files (i), these methods must be selected according to the actual situation:

If the resources need to be modified frequently, then you can use the "about the package jar file encountered in the resource path problem (a)" described in the method, the executable jar package and the resource separation, so easy to change, without the need to unzip the jar package after the recovery;

If some resources do not need to be modified, then you can use the method in this article to package the resources and bytecode files into the jar package, which makes it easy to move the application.

Of course, if we combine these two methods, we can achieve better results by classifying fixed resources and frequently modified resources.

About resource path problems when packaging a jar file (ii)