Compilation Instructions for Java

Compilation Guide

See Supported Languages and Platforms for instructions for other platforms.

Supported Java JREs and Compilers

Language Platforms Supported Versions Compilers

Java SE, Java EE, JSP

JRE 1.4–1.9, 10, 11, 12, 13, 14
  • JDK and OpenJDK 1.3–1.9, 10, 11, 12, 13, 14
  • IBM JDK 1.7–1.8
  • Tomcat Jasper 7
  • WebLogic 12.x

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

Certain findings found in code compiled with an earlier compiler version may be mitigated when you run that code on a later runtime environment. 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  

Commons Attributes
Commons BeanUtils
Commons ClassScan
Commons CLI
Commons Codec
Commons DBCP
Commons Discovery
Commons FileUpload
Commons Lang
Commons Logging
Commons Performance
Commons Pool
Commons ThreadPool

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 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  
Google App Engine 1.9.24  
Google Web Toolkit (GWT) 2.8.0  
Hibernate 1.x, 2.x, 3.x, 4.0  
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 Liferay applications that have been customized using Hook plugins are not supported.
Play 2.0–2.7.x  
Servlets 3.x  
Spring Boot 1.x, 2.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  
Spring Data Access 5.x  
Spring MVC 2.x, 3.x, 4.x, 5.x  
Spring Security 3.x, 4.x, 5.x  
Struts 1.x, 2.x  
Tiles 2.x  

Compilation Guidance (for debug builds)

Using the standard java compiler, at the command line add the -g option to get debug symbols, for example:
javac -g
If the project is being built using Ant, then the debug property in the javac tasks needs to be turned on, for example:
<javac debug="on"> ... set of classes
If the project is being built using Maven, you should include a directive to use the Maven compiler plugin in pom.xml, for example:
 <build> <plugins>
     <plugin> <artifactId>maven-compiler-plugin</artifactId> 
     </plugins> </build>

After making this change, use mvn compile and/or mvn package to build and package the project as usual, and it will include debug symbols with the application.

If you use Gradle to build the project, after applying the Java plugin, configure the build task to add line numbers and local variables, for example:
apply plugin: 'java'
gradle build
If you are developing the project with Eclipse, go to Project > Properties and select the Java Compiler properties. Under Classfile Generation, select the following:
  • Add variable attributes to generated class files.
  • Add line number attributes to generated class files.
  • Add source file name to generated class files.

Packaging the Application as a WAR, EAR, or JAR

The Veracode Platform expects you to submit Java web applications in a standard WAR or EAR format. Specifically, the WAR must contain the following directories and be structured as follows:

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

Veracode determines the scope of analysis by examining the contents of the WAR or EAR file. All classes to be analyzed must be referenced in the /WEB-INF/web.xml file, or be present within the /WEB-INF/classes directory.

Veracode recommends that EAR files contain a /META-INF/application.xml file. If there are no WAR files within an EAR file, it is not required 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 supports the scanning of JAR files that contain a web.xml file in the /WEB-INF/ directory. Veracode scans these JARs as if they were WAR files, which improves support for application servers and packaging methods that handle this deployment method, including OSGi.

Note: Veracode does not scan JAR files nested inside other JAR files, except for Spring Boot applications. Veracode does support analysis of uber-jar files created by the Maven Shade plugin.

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 JSP files that are uploaded prior to performing analysis on them. The Veracode Platform uses 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. 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 the source is also included. Precompiled JSP files are not analyzed. Ensure that any JSP files generated from templates or components, such as include files, are in a successfully compilable state prior to 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 avoid 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 instance, rather than pointing to the namespace, point to the namespace
Note: JSP tags and tag attributes are case-sensitive.

If JSP files are dynamically generated at runtime, they cannot be statically analyzed and will be identified as missing dependencies during prescan verification. Static instances of these files, or stubs, should be provided to facilitate analysis.

The Veracode Platform cannot scan JSP files that cannot be compiled. JSP compilation errors are reported as part of the prescan verification process. An application that has JSP compilation errors can be submitted for scanning, but JSP files with compilation errors will not be analyzed.

Apache Velocity Template Files

Before scanning .vm files that you upload in a WAR archive, the Veracode Platform automatically compiles them using a custom compiler. Veracode does not scan .vm files that are inside JAR files, therefore, before submitting your application, be sure to package these files within WAR or EAR archives. The Veracode Platform 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 are including 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. For further information on the creation of .wsdd files, please see 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 the following directories and be structured as follows:
  • /META-INF/
  • /META-INF/module.xml (contains all modules files)
  • /class_files (contains all class files)
AAR files must contain the following directories and be structured as follows:
  • /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 to identify which jars contain the classes that are indicated as missing by the Veracode Platform. You may also find the JAR Class Finder Plugin for Eclipse helpful.

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 Packaging the Application as a WAR, EAR, or JAR. Ensure that the WAR file contains the following 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 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
    • The method handleRequest that overrides
  • Classes implementing
    • The method
  • 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
    • All public functions that have up to two input parameters that the Lambda Deployment package does not reference

Software Composition Analysis

If you have a Veracode Software Composition Analysis subscription, you can include third-party components in your static analysis submission to report on vulnerabilities in those components. To effectively scan third-party components, the submitted application must also meet the packaging requirements for SCA upload and scan.