Java packaging

Your Java applications must meet specific packaging and compilation requirements before you can submit them for scanning.

See Supported languages and platforms for instructions for other platforms.

You can analyze applications using Veracode Static Analysis or Veracode Software Composition Analysis (SCA) upload and scan, if licensed. For SCA agent-based scan requirements, see Using Veracode SCA with Programming Languages.

Automated packaging

Auto-packaging simplifies the packaging process for Java projects.

Java manual packaging tutorial

Watch the tutorial.

Supported Java JREs and compilers

Language	Platforms	Supported versions	Compilers
Java	Java SE, Java EE, Jakarta, JSP	JRE 1.4–1.9, 10–23	JDK and OpenJDK 1.3–1.9 10–23 IBM JDK 1.7–1.8 Tomcat Jasper 7 WebLogic 12.x

Veracode can analyze Java code with or without debug symbols. Providing debug builds of Java application code allows Veracode to provide source file and line number information about the location of findings found. For a successful scan, you cannot obfuscate Java applications.

You may mitigate certain findings in code compiled with an earlier compiler version when you run that code on a another runtime environment later. In such cases, the finding descriptions contain a note describing the version dependency.

Supported Java frameworks

Framework/Technology	Supported versions	Notes
Adobe Experience Manager	6.4 and earlier	Veracode supports compiled Java code for Sling Servlets, OSGi services, and AEM custom components, packaged as a JAR file.
Apache Axiom
Apache Axis	1.x
Apache Axis2	1.6.2
Apache Chemistry	1.1.0
Apache Commons		Includes: Commons Attributes Commons BeanUtils Commons ClassScan Commons CLI Commons Codec Commons Collections Commons Collections4 Commons Crypto Commons CSV Commons Daemon Commons DBCP Commons DbUtils Commons Discovery Commons Email Commons FileUpload- Commons Lang- Commons Lang 3 Commons Logging Commons Net Commons Performance Commons Pool Commons ThreadPool Commons Text
Apache CXF	2.7.0	Veracode only supports the parts of CXF that expand JAX-WS.
Apache Jersey	2.x
Apache Oro	2.x
Apache Log4j	1.x, 2.x
Apache Velocity	1.7	Veracode only supports the web rendering usage of the default Velocity servlet for binaries uploaded in a WAR file.
Apache Xerces	2.x
Apache XMLBeans	2.x
AWS SDK for Java	1.11, 2.0
Azure Functions	2.x, 3.x
Google App Engine	1.9.24
Google Web Toolkit (GWT)	2.8.0
Hibernate	1.x, 2.x, 3.x, 4.x, 5.x
Java Portlets	1.0, 2.0
Java Servlets	3.x
JAX-RS	1.x, 2.x
JAX-WS	2.x
JAXB	2.x
JDBC	4.2 and earlier
JDOM	1.x
JSF	1.x, 2.x
JSTL	1.x
Liferay	6.x	Veracode does not support Liferay applications if you customize them using Hook plugins.
Micronaut	3.8.x
Play	2.0–2.7.x
Quarkus	2.x, 3.x
Servlets	3.x
Spring Boot	1.x, 2.x, 3.x	Supports executable JARs, also known as Uber FAT JARs, and JARs with dependencies
Spring Core	1.x, 2.x , 3.x, 4.x, 5.x, 6.x
Spring Data Access	5.x
Spring MVC	2.x, 3.x, 4.x, 5.x
Spring Security	3.x, 4.x, 5.x, 6.x
Struts	1.x, 2.x
Tiles	2.x

Template engines

Name	Supported versions
Thymeleaf	2.x, 3.x

Obtaining compilation debug symbols

Using the standard Java compiler, run the javac command with the -g option to obtain debug symbols, for example:

javac -g test1.java

Eclipse IDE settings

If you develop the project with Eclipse:

1. Go to Project > Properties.
2. Select the Java compiler properties.
3. Under Classfile Generation, select these options:
   • Add variable attributes to generated class files
   • Add line number attributes to generated class files
   • Add source file name to generated class files

Maven settings

If you build the project using Maven, include a directive to use the Maven compiler plugin in pom.xml, for example:

<build>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <debug>true</debug>
        <debuglevel>lines,vars,source</debuglevel>
      </configuration>
    </plugin>
  </plugins>
</build>

After making this change, use mvn compile or mvn package to build and package the project. The project now includes debug symbols with the application.

Veracode SCA upload scans are more accurate when the Fat JAR files include the JAR files of the project dependencies. To ensure you package your applications to include the dependency JAR files, Veracode recommends you add the OneJar Maven Plugin or, for Spring Boot, the Maven Spring Boot Plugin in the <build><plugins/></build> element of pom.xml. For example:

• OneJar Maven Plugin

  <plugin>
    <groupId>com.jolira</groupId>
    <artifactId>onejar-maven-plugin</artifactId>
    <version>1.4.4</version>
    <executions>
      <execution>
        <goals>
          <goal>one-jar</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

• Maven Spring Boot Plugin

  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.3.4.RELEASE</version>
    <executions>
      <execution>
        <goals>
          <goal>repackage</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

Gradle settings

If you use Gradle to build the project, after applying the Java plugin, configure the build task to add line numbers and local variables in the build.gradle file. For example:

apply plugin: 'java'
compileJava.options.debug = true
compileJava.options.debugOptions.debugLevel = "source,lines,vars"

Ant settings

If you build the project using Ant, you must enable the debug property in the javac tasks, for example:

<javac debug="on"> ... set of classes
     </javac>

Packaging the application as a WAR, EAR, or JAR

Veracode expects you to submit Java web applications in a standard WAR or EAR format. Specifically, the WAR file must contain these directories with these structures:

• /WEB-INF/
• /WEB-INF/classes/: contains all class files
• /WEB-INF/lib/: contains all supporting libraries
• /WEB-INF/web.xml

To determine the scope of analysis, Veracode examines the contents of the WAR or EAR file. Ensure that all classes that you want to analyze exist in either:

• The /WEB-INF/classes directory
• A non-third party library in /WEB-INF/lib

Veracode recommends that EAR files contain a /META-INF/application.xml file. If an EAR file does not contain any WAR files, you do not need to include the /WEB-INF/ directory or the /WEB-INF/web.xml file.

For more information on how to prepare a WAR file, see the Java EE tutorial.

Veracode can scan JAR files that contain a web.xml file in /WEB-INF/. Veracode scans these JAR files the same as WAR files to improve support for application servers and packaging methods that manage this deployment method, including OSGi.

Veracode SCA upload and scan only analyzes JAR, WAR, and EAR files. It ignores Java build files, such as pom.xml and build.gradle. To return Veracode SCA results, either include third-party JAR files in /WEB-INF/lib inside a WAR file or upload them in a separate JAR file.

note

Veracode Static Analysis does not support JAR files nested inside other JAR files, except for Spring Boot applications. Veracode Static Analysis supports analysis of first-party code in uber-jar files created by the Maven Shade plugin. However, Veracode Software Composition Analysis has only limited support and may not detect all shaded dependencies.

For the best analysis result, Veracode recommends disabling Maven Shade on builds sent to Veracode for analysis.

See Packaging Spring Boot applications.

Veracode extracts client-side JavaScript from JSP files that are uploaded as part of a JAR, WAR, or EAR file, and creates a separate JavaScript module that is selectable for analysis.

JSP files

Veracode automatically compiles uploaded JSP files before performing analysis on them. Veracode uses either the Tomcat Jasper compiler version 7 or the WebLogic compiler version 12.x for WebLogic applications.

JSP files that are part of the application must be included in a correctly structured WAR or EAR file. Veracode appends JARs under the directory containing the WAR or EAR file and its subdirectories to the classpath of the JSP compiler. If JSP or other source files must undergo preprocessing during the build process, you must perform this preprocessing before you can submit files for a static scan. However, if artifacts contain precompiled JSP classes, ensure that you also include the source. Veracode does not analyze precompiled JSP files. Ensure that any JSP files that you generate from templates or components, such as include files, have compiled successfully before submission.

At compilation time, the Veracode compiler attempts to force expressions to evaluate so that they can be scanned. This action can sometimes result in compilation errors. Two possible workarounds can prevent these errors:

• In the TLD file included with the WAR, update the value of any <rtexprvalue> nodes to true.
• In individual JSPs, set the taglib URIs to point to versions of the taglibs that explicitly support rt-expressions. For example, instead of pointing to the namespace http://java.sun.com/jstl/core, point to the namespace http://java.sun.com/jstl/core_rt.

note

JSP tags and tag attributes are case-sensitive.

If JSP files are dynamically generated at runtime, Veracode cannot analyze them. Veracode identifies these files as missing dependencies during prescan verification. To facilitate analysis, provide static instances of these files or stubs.

Veracode cannot scan JSP files if you cannot compile those files. Veracode reports JSP compilation errors as part of the prescan verification process. You can submit an application that has JSP compilation errors for scanning, but Veracode does not analyze JSP files with compilation errors.

Apache Velocity template files

Before scanning VM files that you upload in a WAR archive, Veracode automatically compiles them using a custom compiler. Veracode does not scan VM files that are inside JAR files. Before submitting your application, ensure that you package these files within WAR or EAR archives. Veracode cannot scan VM files that an Apache Velocity engine cannot compile. Veracode does not scan any applications that do not meet these requirements.

Apache Axis and Axis2

If you include any Apache Axis web service code within your WAR file, you must make all WSDD files available in the /WEB-INF/ directory of the WAR file. For further information on the creation of WSDD files, see the Apache Axis documentation.

You must upload Axis2 modules in the MAR format and server-side Axis2 applications in the AAR format.

MAR files must contain these directories with these structures:

• /META-INF/
• /META-INF/module.xml: contains all module files
• /class_files: contains all class files

AAR files must contain these directories with these structures:

• /META-INF/
• /META-INF/services.xml: contains all services files
• /class_files: contains all class files

WebSphere applications

For applications that are deployed on WebSphere, a common cause of JSP compilation failure is missing standard WebSphere libraries that are in the WebSphere environment but not packaged with the application. In the event of JSP compilation failure combined with warnings about missing classes, you can check the standard WebSphere directories for your deployed version of the JAR containing these classes; this may include the <was>lib/app directory or the ws.ext.dirs.

You can use a resource such as FindJar.com to identify which JARs contain the classes that Veracode indicated as missing. You may use the JAR Class Finder Plugin for Eclipse.

In some cases, Veracode can substitute a stock library for libraries that are not provided with the application. It is generally better to provide the version of the library that your project uses to ensure that the application model accurately represents the functionality of your application.

Packaging Spring Boot applications

Spring Boot applications submitted as WAR files should be structured according to the guidance in the Packaging the Application as a WAR, EAR, or JAR section. Ensure that the WAR file contains these directories:

• /BOOT-INF/classes/: contains all class files
• /BOOT-INF/lib/: contains dependencies

See the Spring Boot documentation for additional details.

Packaging AWS Lambda applications

Veracode requires you to submit applications built for AWS Lambda according to the AWS Lambda Deployment Package formats. For information, see https://docs.aws.amazon.com/ and search for AWS Lambda Deployment Package in Java.

note

Veracode does not support the analysis of dependencies submitted as Lambda layers. To analyze Lambda components deployed in layers, submit them as standard deployment packages, or consider repackaging the function to include layer components as part of the lambda function package.

Identifying Lambda handlers for Java

The analysis of Lambda functions relies on the identification of Lambda Handler methods. Veracode uses this set of heuristics to identify methods that can be candidates for handler methods:

• Classes implementing com.amazonaws.services.lambda.runtime.RequestHandler:
  • The method handleRequest that overrides com.amazonaws.services.lambda.runtime.RequestHandler.handleRequest
• Classes implementing com.amazonaws.services.lambda.runtime.RequestStreamHandler.handleRequest:
  • The method com.amazonaws.services.lambda.runtime.RequestStreamHandler.handleRequest
• Deployment packages that reference AWS components or namespaces and classes that do not implement an AWS class:
  • All public functions that have up to two input parameters, where the second parameter is of type com.amazonaws.services.lambda.runtime.Context
  • All public functions that have up to two input parameters that the Lambda Deployment package does not reference

Packaging Adobe Experience Manager applications

As part of the build process for typical Adobe Experience Manager projects, you can use mvn install. After the build completes, upload all ZIP files containing OSGi components or other compiled Java code. The Java code includes any code in the ui.apps ZIP archive, which is usually found in ui.apps/target/.

Upload each package individually. Do not upload multiple packages in a ZIP file. Veracode does not support ZIP archives containing ZIP files.

Packaging Quarkus applications

1. To compile the application, run the following command:

   mvn package -Dquarkus.package.type=uber-jar

2. Upload the file target/{your_application_name}-runner.jar to Veracode. This JAR file contains the first-party code and most of the application dependencies, but it does not contain the Quarkus libraries.

3. Optionally, for SCA results, upload the Quarkus libraries separate from your Java files.