##### Overview

- Download PMD 5.0.4
- What's new in PMD 5.0.4
- PMD in the news
- PMD-related products and books
- Best practices
- Future directions
- Similar projects
- Credits
- License
- What does 'PMD' mean?

##### Usage

- Installation
- Command line usage
- Ant task usage
- Maven plugin usage
- Mvn plugin usage
- IDE plugin usage
- Suppressing warnings
- Finding duplicated code
- JSP support

##### Customizing PMD

- Compiling PMD
- How to write a rule
- Writing XPath rules
- How to make a rule set
- How it works
- Rule guidelines
- PMD developers information
- PMD Release Process

##### For example

- Run PMD on a Sourceforge project

##### Misc.

- XPath tutorial (Gregorian)

##### Rule Sets

- ecmascript
  - Basic Ecmascript
  - Braces
  - Unnecessary
- java
  - Android
  - Basic
  - Braces
  - Clone Implementation
  - Code Size
  - Comments
  - Controversial
  - Coupling
  - Design
  - Empty Code
  - Finalizer
  - Import Statements
  - J2EE
  - JavaBeans
  - JUnit
  - Jakarta Commons Logging
  - Java Logging
  - Migration
  - Naming
  - Optimization
  - Strict Exceptions
  - String and StringBuffer
  - Security Code Guidelines
  - Type Resolution
  - Unnecessary
  - Unused Code
- jsp
  - Basic JSF
  - Basic JSP
- xml
  - Basic XML
- xsl
  - XPath in XSL

##### Project Documentation

- Project Information
- Project Reports

## Import Statements

These rules deal with different problems that can occur with import statements.

### DuplicateImports

Since: PMD 0.5

Duplicate or overlapping import statements should be avoided.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.imports.DuplicateImportsRule

Example(s):

    import java.lang.String;
    import java.lang.*;
    public class Foo {}

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.

### DontImportJavaLang

Since: PMD 0.5

Avoid importing anything from the package 'java.lang'. These classes are automatically imported (JLS 7.5.3).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.imports.DontImportJavaLangRule

Example(s):

    import java.lang.String;	// this is unnecessary

    public class Foo {}

    // --- in another source code file...

    import java.lang.*;	// this is bad

    public class Foo {}

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.

### UnusedImports

Since: PMD 1.0

Avoid the use of unused import statements to prevent unwanted dependencies.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.imports.UnusedImportsRule

Example(s):

    // this is bad
    import java.io.File;
    public class Foo {}

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.

### ImportFromSamePackage

Since: PMD 1.02

There is no need to import a type that lives in the same package.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.imports.ImportFromSamePackageRule

Example(s):

     package foo;

     import foo.Buz; // no need for this
     import foo.*; // or this

     public class Bar{}

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.

### TooManyStaticImports

Since: PMD 4.1

If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from (Sun 1.5 Language Guide).

    .[count(ImportDeclaration[@Static = 'true']) > $maximumStaticImports]

Example(s):

    import static Lennon;
    import static Ringo;
    import static George;
    import static Paul;
    import static Yoko; // Too much !

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
maximumStaticImports | 4 | All static imports can be disallowed by setting this to 0

### UnnecessaryFullyQualifiedName

Since: PMD 5.0

Import statements allow the use of non-fully qualified names. The use of a fully qualified name which is covered by an import statement is redundant. Consider using the non-fully qualified name.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.imports.UnnecessaryFullyQualifiedNameRule

Example(s):

    import java.util.List;

    public class Foo {
       private java.util.List list1; // Unnecessary FQN
       private List list2; // More appropriate given import of 'java.util.List'
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.