<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <title>Java Application Stub</title>
  <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1" />
  <meta http-equiv="Content-Language" content="en-us" />
  <meta name="ROBOTS" content="ALL" />
  <link href="styles.css" rel="stylesheet" media="all" type="text/css" />
</head>

<body>


<h2>JarBundler - Java Application Stub</h2>


<p>The Java Launching stub file  is located inside of your application bundle in the 
subdirectory "<tt>Contents/MacOS/</tt>". The default name for this file is "<tt>JavaApplicationStub</tt>".
It is used by the Mac OS X system  read the
applications plist and then launch the Java VM with the appropriate properties such as the
classpath and main class name.  


<p>When run on OS X system, the JarBundler ANT task uses the current copy of the <tt>JavaApplicationStub</tt>
from the developer's disk.  Starting with JarBundler 1.8 the attribute <tt>stubfile</tt> can be used to 
set the name of the <tt>JavaApplicationStub</tt> file copied from the system framework. If the
stub file referenced by the <tt>stubfile</tt> attribute exists, that file will be used along with
it's filename.

<p>When the JarBundler ANT task is used under Windows or Linux, a copy of the <tt>JavaApplicationStub</tt>
must be supplied by the developer. This cannot be built from source but must be obtained from
a Mac OS X system.


<h3>Java Launching Stub as a Symbolic Link</h3>

<p>Creating a bundle with the your current copy of Java Launching Stub
could lead to a future situation where the <tt>JavaApplicationStub</tt> file
could become incompatible with a future OS X update.  

<p>Under Mac OS X one
could replace the "<tt>JavaApplicationStub</tt>" file with a symbolic link to the user's current
copy.  This <em>should</em> guarentee that
the end user would always be using a current copy of the stub file.  I have used this technique on
several versions of OS X and have not have had any reported problems with its use.


<p>Obviously, if you have used a stub file name which is different than the one shown in the
example below you will have to make changes to both the delete and the symbolic link commands.

<p>This is not yet an option of the JarBundler task but can be accomplished with the following lines
of ANT code after building the bundle. <strong>NB:</strong> This will not work when building under
Windows and is untested under Linux.


<pre style="padding-left:3em;">
   .
   .
   .
  &lt;/jarbundler&gt;
        
  &lt;!-- Delete the JavaApplicationStub and replace it with a symbolic link --&gt;
  &lt;!--   which should work on older and future versions of OS X           --&gt;
       
  &lt;delete file="${release}/${name}.app/Contents/MacOS/JavaApplicationStub"/&gt;
  &lt;exec executable="ln"&gt;
    &lt;arg line="-s /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub"/&gt;
    &lt;arg value="${release}/${name}.app/Contents/MacOS/JavaApplicationStub"/&gt;
  &lt;/exec&gt;

&lt;/target&gt;
       
</pre>

<h3>A Known problem with Java launching stub</h3>

<p>In early 2006 an Apple upgrade to Quicktime (7.0.4) caused 
older versions of "<tt>JavaApplicationStub</tt>" to fail to start up.  These old copies came from developers 
who first created the application bundle as a directory and then created new applications by 
replacing the JAR files within the bundle and not replacing "<tt>JavaApplicationStub</tt>" with a more current
copy.



</body>
</html>