anchor.diff:  
   ### <a id='memory'></a>Allocate Sufficient Memory ###
   
  -If you do not allocate sufficient memory to a Java application when you deploy it, it may fail to start, or <%=vars.product_short%> may terminate it. You must allocate enough memory to allow for the following:
  +If you do not allocate sufficient memory to a Java application when you deploy
  +it, it may fail to start, or <%=vars.product_short%> may terminate it.
  +You must allocate enough memory to allow for the following:
   
   * Java heap
   * Metaspace, if using Java 8
  
positive.code: Java applications can be packaged as Servlet applications.
  
  ### <a id='servlet-maven'></a>Maven ###
  A Maven build can create a Servlet WAR. To build and deploy the WAR, run the following:
  
  <pre class="terminal">
  $ mvn package
  $ cf push &lt;application-name&gt; -p target/&lt;application-name&gt;-&lt;application-version&gt;.war
  </pre>
  
  
  ### <a id='servlet-gradle'></a>Gradle ###
  A Gradle build can create a Servlet WAR. To build and deploy the JAR, run the following:
  
  <pre class="terminal">
  $ gradle build
  
negative.code: unnecessary files, in addition to the WAR.
  When you push a Java application, specify the path to the WAR:
  
      <pre class="terminal">
      $ cf push MY-APP -p /Path/To/WAR/file
      </pre>
  
      You can determine whether or not the path was specified for a previously
      pushed application by looking at the application deployment manifest,
  	`manifest.yml`.
  	If the `path` attribute specifies the current directory, the manifest will
  	include a line like this:
  
      ```
      path: .
      ```
      To re-push just the WAR, either:
  
      * Delete `manifest.yml` and push again, specifying the location of the WAR
  	using the `-p` flag, or
   	* Edit the `path` argument in `manifest.yml` to point to the WAR, and
  	re-push the application.
  
  ### <a id='slow-start'></a>Slow Starting Java or Grails Apps ###
  
  Some Java and Grails applications do not start quickly, and the DEA health check
  for an application can fail if an application starts too slowly.
  
  The current Java buildpack implementation sets the Tomcat `bindOnInit` property
  to `false`. This prevents Tomcat from listening for HTTP requests until an
  application has deployed.
  
  If your application does not start quickly, the DEA health check may fail
  because it checks the health of the application before the application can
  accept requests.
  By default, the DEA health check fails after 60 seconds.
  
  To resolve this issue, use the `-t` flag with the `cf push` to increase the
  timeout threshold.
  
  <pre class="terminal">
  $ cf push my-app -t 180
  </pre>
  
  <p class="note"><strong>Note</strong>: The timeout threshold cannot exceed 180 seconds. Specifying a timeout threshold greater than 180 seconds results in the following error: <code>Server error, status code: 400, error code: 100001, message: The app is invalid: health_check_timeout maximum_exceeded</code>.</p>
  
  ## <a id='extension'></a>Extension ##
  The Java Buildpack is also designed to be easily extended.
  It creates abstractions for [three types of components][a] (containers,
  frameworks, and JREs) in order to allow users to easily add functionality.
  In addition to these abstractions, there are a number of [utility classes][e]
  for simplifying typical buildpack behaviors.
  
  As an example, the New Relic framework looks like the following:
  
  