...
Java programmers need more help than that provided by the Java Language Specification (JLS) [JLS 2013] to produce reliable and secure Java programs. Java contains language features and APIs that can easily be misused, and guidance is needed to avoid theses pitfalls.
...
Some of these guidelines are stylistic, but they are nonetheless important for readability and maintainability of the code. For Java, Oracle provides a set of Code Conventions [Conventions 2009] to help programmers produce a consistent programming style, and these conventions are widely adopted by Java programmers.
The CERT® Oracle® Secure Coding Standard for Java
Java™ Coding Guidelines is written by the authors of The CERT® Oracle® Secure Coding Standard for Java [Long 2011]. That coding standard provides a set of rules for secure coding in the Java programming language. The goal of those rules is to eliminate insecure coding practices that can lead to exploitable vulnerabilities. The Secure Coding Standard establishes normative requirements for software systems. These software systems can then be evaluated for conformance to the coding standard, for example, by using the Source Code Analysis Laboratory (SCALEeSCALe) [Seacord 2013]. However, there are poor Java coding practices that, despite not warranting inclusion in a secure coding standard for Java, can lead to unreliable or insecure programs. Java Coding Guidelines serves to document and warn against such coding practices.
Although not included in the The CERT® Oracle® Secure Coding Standard for Java, these guidelines should not be considered less important. Guidelines must be excluded from a coding standard when it is not possible to form a normative requirement. There are many reasons that a normative requirement cannot be formed. Perhaps the most common is that the rule depends on programmer intent. Such rules cannot be automatically enforced unless it is possible for the programmer's intent to be specified, in which case, a rule could require consistency between the code and the specified intent. Forming a normative requirement also requires that a violation of that requirement represent a defect in the code. Guidelines have been excluded from the coding standard (but included in this book) in cases where compliance with the guideline is always a good idea, but violating the guideline does not always result in an error. This distinction is made because a system cannot be cited for nonconformance without a specific defect. Consequently, coding rules must be very narrowly defined. Coding guidelines can often have a more far-reaching impact on security and reliability just because they can be more broadly defined.
...
Cross references to other guidelines throughout this book are given simply by the number and title of the guideline.
Rec.: Contents and Organization
Rec.: Automatically Generated Code
Rec.: Tool Selection and Validation
...