YOU ARE HERE: HOMEVeracode Compilation Instructions for Java

Veracode Compilation Instructions for Java

This document is for customer licensed Veracode SAST. Last check and update 11-Jan-2018.

Supported Java JREs and Compilers

Language Platforms Versions Compilers

Java SE, Java EE, JSP

JRE 1.4-1.8

JDK 1.3-1.8, WebLogic 12.x, OpenJDK 1.6 – 1.8, IBM JDK 1.7-1.8

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 flaws found. For a successful scan, you cannot obfuscate Java applications.

It is possible that certain flaws found in code compiled with an earlier compiler version may be mitigated when that code is run on a later runtime environment. In such cases, the flaw descriptions contain a note describing the version dependency.

Supported Java Frameworks

Framework Supported Version(s) Notes
Apache Axiom
Apache Axis 1.x
Apache Axis2 1.6.2
Apache Commons Includes Commons Attributes, Commons BeanUtils, Commons ClassScan, Commons CLI, Commons DBCP, Commons Discovery, Commons FileUpload, Commons Lang, Commons Logging, Commons Performance, Commons Pool, Commons ThreadPool.
Apache CXF 2.7.0 Support is only for the parts of CXF that expand JAX-WS
Apache Jersey 2.x
Apache Oro 2.x
Apache Velocity 1.7 Support is only for the web rendering usage of the default Velocity servlet for binaries uploaded in a WAR file.
Apache Xerces 2.x
Apache XMLBeans 2.x
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.5.9
Servlets 3.x
Spring Boot 1.x
Spring Core 1.x, 2.x, 3.x, 4.x
Spring MVC 2.x, 3.x
Spring Security 3.x, 4.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 task(s) 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> </plugin>
     </plugins> </build>

Once this change is made, 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 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.

Please note, Veracode does not scan JAR files nested inside other JAR files, except for Spring Boot applications. See below for more information on how to package 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 during the build process, this must be performed before the files can be submitted for a static scan. Any JSP files generated from templates or components, such as include files, should be 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

Please ensure that your Spring Boot application includes either the Spring-Boot-Classes or Spring-Boot-Lib strings within the META-INF/MANIFEST.MF file.

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

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 above. See the Spring Boot Documentation for additional details.

Veracode does not support Spring Boot applications that have been built with embedded launcher shell scripts. This is an option controlled within the application’s Maven POM file or Gradle configuration. Applications packaged in this way include a bash script embedded in the file, which causes the JAR file to no longer adhere to the standard JAR file format.

If your Spring Boot application uses this option for deployment, please remove the <executable>true</executable> statement from the application’s POM file prior to submitting it to Veracode.

If your Spring Boot application is deployed with Gradle, please remove this equivalent line from the Gradle configuration:

apply plugin: 'spring-boot'

springBoot {
    executable = true