The options and arguments used in this command are: The c option indicates that you want to create a JAR file.; The f option indicates that you want the output to go to a file rather than to stdout.; jar-file is the name that you want the resulting JAR file to have. You can use any filename for a JAR file. By convention, JAR filenames are given a.jar extension, though this is not required. To get this file looking like a java file and opening with java by default, simply right click on the jar file and select open with, then click on choose another app. Here select Java Platform SE Binary, the check the box where it says always use this app to open.jar file.
These documentation pages are no longer current. They remain available for archival purposes. Please visit
https://docs.oracle.com/javase for the most up-to-date documentation.
This page shows you, step by step, how to convert a simple Java application to a version you can distribute on a Mac. To follow along, download the ButtonDemo (.zip) example from the Java Tutorial. This example was created using NetBeans which uses the Ant utility. You can run all necessary tools and make all necessary edits from the command line, without launching NetBeans. The Ant tool is required.
You have created a Java application and want to bundle it for deployment. This requires the following steps:
Create a JAR File
This step creates the ButtonDemo.jar file.
Execute ant jar in the high-level project directory to create the dist/ButtonDemo.jar file. This jar file is used to create the .app package.
Bundle the JAR File into an App Package
To create the ButtonDemo.app package, use the appbundler tool. The appbundler is not shipped with the 7u6 version of the Oracle JDK for the Mac. You can download it from the Java Application Bundler project on java.net. There is also AppBundler Documentation available.
As of this writing, the most recent version is appbundler-1.0.jar, which is used by this document. Download the latest version available and substitute the file name accordingly.
- Install the appbundler-1.0.jar file. In this case, create a lib directory in the high-level project directory and add the appbundler-1.0.jar file.
- Modify the build.xml file in the high-level project directory as follows. (The added code is shown in bold.)
- Invoke the appbundler by typing ant bundle-buttonDemo from the high-level project directory. This creates the ButtonDemo.app package in the dist directory.
- You should now be able to launch the application by double clicking ButtonDemo.app in the Finder, or by typing open ButtonDemo.app at the command line.
Bundle the JRE with the App Package
In order to distribute a Java application, you want to avoid dependencies on third party software. Your app package should include the Java Runtime Environment, or JRE. In fact, the Apple Store requires the use of an embedded JRE as a prerequisite for Mac App Store distribution. The runtime sub-element of the <bundleapp> task specifies the root of the JRE that will be included in the app package.
In this example, the location of the JRE is defined using the JAVA_HOME environment variable. However, you might choose to bundle a JRE that is not the same as the one you are using for development. For example you might be developing on 7u6, but you need to bundle the app with 7u4. You will define runtime accordingly.
Since this example defines the runtime sub-element using JAVA_HOME, make sure it is configured correctly for your environment. For example, in your .bashrc file, define JAVA_HOME as follows:
Use the following steps to modify the build.xml file at the top of the project directory: Must haves software for macs 2017.
- Specify an environment property, named env:
- In the target that creates the bundle, specify the location of the JRE on your system, using the env property:
The resulting build.xml file should look like the following. (The new lines are shown in bold.)
Open Jar File Java
Create a fresh version of ButtonDemo.app, using the ant bundle-buttonDemo command. The resulting version includes the JRE in the app package. You can confirm this by examining the Contents/PlugIns directory inside of the app package.
Sign the App
The Gatekeeper feature, introduced in Mountain Lion (OS X 10.8), allows users to set the level of security for downloaded applications. By default, Gatekeeper is set to allow only OS X App Store and Developer ID signed applications. Unless your app is signed with a Developer ID certificate provided by Apple, your application will not launch on a system with Gatekeeper's default settings.
For information on the signing certificates available, see Code Signing Tasks on developer.apple.com.
The signing certificate contains a field called Common Name. Use the string from the Common Name field to sign your application.
Sign your app using the codesign(1) tool, as shown in the following example:
To verify that the app is signed, the following command provides information about the signing status of the app:
To check whether an application can be launched when Gatekeeper is enabled, use the spctl command:
If you leave off the --verbose tag, and it does not print any output, indicates 'success'.
For more information, see Distributing Outside the Mac App Store on developer.apple.com.
Submitting an App to the Mac App Store
Packaging an app for the Mac App Store is similar to packaging for regular distribution up until the step of signing the app. Signing the app for the Mac App Store requires a few more steps, and a different kind of certificate.
You will need to create an application ID and then obtain a distribution certificate for that application ID. Submit your app using Application Loader. For more information, see the following links (on developer.apple.com):
The basic format of the command for creating a JAR file is:
The options and arguments used in this command are:
- The c option indicates that you want to create a JAR file.
- The f option indicates that you want the output to go to a file rather than to stdout.
- jar-file is the name that you want the resulting JAR file to have. You can use any filename for a JAR file. By convention, JAR filenames are given a .jar extension, though this is not required.
- The input-file(s) argument is a space-separated list of one or more files that you want to include in your JAR file. The input-file(s) argument can contain the wildcard * symbol. If any of the 'input-files' are directories, the contents of those directories are added to the JAR archive recursively.
The c and f options can appear in either order, but there must not be any space between them.
This command will generate a compressed JAR file and place it in the current directory. The command will also generate a default manifest file for the JAR archive.Note:
The metadata in the JAR file, such as the entry names, comments, and contents of the manifest, must be encoded in UTF8.
You can add any of these additional options to the cf options of the basic command:
|v||Produces verbose output on stdout while the JAR file is being built. The verbose output tells you the name of each file as it's added to the JAR file.|
|0 (zero)||Indicates that you don't want the JAR file to be compressed.|
|M||Indicates that the default manifest file should not be produced.|
|m||Used to include manifest information from an existing manifest file. The format for using this option is:See Modifying a Manifest File for more information about this option.|
Warning: The manifest must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return.
|-C||To change directories during execution of the command. See below for an example.|
When you create a JAR file, the time of creation is stored in the JAR file. Therefore, even if the contents of the JAR file do not change, when you create a JAR file multiple times, the resulting files are not exactly identical. You should be aware of this when you are using JAR files in a build environment. It is recommended that you use versioning information in the manifest file, rather than creation time, to control versions of a JAR file. See the Setting Package Version Information section.
Let us look at an example. A simple TicTacToe applet. You can see the source code of this applet by downloading the JDK Demos and Samples bundle from Java SE Downloads. This demo contains class files, audio files, and images having this structure:
The audio and images subdirectories contain sound files and GIF images used by the applet.
Convert Jar To Java File
You can obtain all these files from jar/examples directory when you download the entire Tutorial online. To package this demo into a single JAR file named TicTacToe.jar, you would run this command from inside the TicTacToe directory:
The audio and images arguments represent directories, so the Jar tool will recursively place them and their contents in the JAR file. The generated JAR file TicTacToe.jar will be placed in the current directory. Because the command used the v option for verbose output, you would see something similar to this output when you run the command:
You can see from this output that the JAR file TicTacToe.jar is compressed. The Jar tool compresses files by default. You can turn off the compression feature by using the 0 (zero) option, so that the command would look like:
You might want to avoid compression, for example, to increase the speed with which a JAR file could be loaded by a browser. Uncompressed JAR files can generally be loaded more quickly than compressed files because the need to decompress the files during loading is eliminated. However, there is a tradeoff in that download time over a network may be longer for larger, uncompressed files.
The Jar tool will accept arguments that use the wildcard * symbol. As long as there weren't any unwanted files in the TicTacToe directory, you could have used this alternative command to construct the JAR file:
Though the verbose output doesn't indicate it, the Jar tool automatically adds a manifest file to the JAR archive with path name META-INF/MANIFEST.MF. See the Working with Manifest Files: The Basics section for information about manifest files.
In the above example, the files in the archive retained their relative path names and directory structure. The Jar tool provides the -C option that you can use to create a JAR file in which the relative paths of the archived files are not preserved. It's modeled after TAR's -C option.
As an example, suppose you wanted to put audio files and gif images used by the TicTacToe demo into a JAR file, and that you wanted all the files to be on the top level, with no directory hierarchy. You could accomplish that by issuing this command from the parent directory of the images and audio directories:
The -C images part of this command directs the Jar tool to go to the images directory, and the . following -C images directs the Jar tool to archive all the contents of that directory. The -C audio . part of the command then does the same with the audio directory. The resulting JAR file would have this table of contents:
How To Create A Jar File Java
By contrast, suppose that you used a command that did not employ the -C option:
Java How To Run Jar
The resulting JAR file would have this table of contents: