<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p> Checks that constant names conform to a format specified by the format property. A <em>constant</em> is a <strong>static</strong> and <strong>final</strong> field or an interface/annotation field, except <strong>serialVersionUID</strong> and <strong>serialPersistentFields</strong>. </p>