Checkstyle 3.4 released


News: Checkstyle 3.4 released

  1. Checkstyle 3.4 released (27 messages)

    Announcing that Checkstyle version 3.4 has been released and is available from See the release notes for the many changes since the last widely announced release -

    Checkstyle is a tool for performing analysis on Java source code. It is most infamous for performing syntax checks and enforcing coding standards. However, it is very flexible and includes checks for:

      * J2EE coding problems (
      * Unused declarations (
      * Metrics analysis (
      * Coding Problems (
      * Class Design (
      * Many others including Javadoc Comments, Naming Conventions, Headers, Imports, Size Violations, Whitespace, Modifiers, Blocks, Duplicate Code, Miscellaneous others.

    The Checkstyle architecture has been designed to allow custom checks to be easily developed. See for more details.

    Plenty of documentation is available at

    Third-party plug-ins are available for Maven, jEdit, NetBeans, Centipede, JBuilder, Eclipse/WSAD, Emacs JDE, BlueJ.


    PS: The Checkstyle team are not responsible for any suffering caused by inappropriate use! :-)

    Threaded Messages (27)

  2. Checkstyle 3.4 released[ Go to top ]

    Suggestion: Ideally I should be able to review that error or suggestion and mark it as OK, the tool will see the mark and do not show that ‘violation’ again.
    For instance I really want to hide a field with local variable by whatever reason: I should be able to mark such place as reviewed and be OK.
  3. Filtering errors[ Go to top ]

    It is possible to filter messages by configuring a filter submodule. See for details. The SuppressionFilter is probably the most appropriate for what you are suggesting.

  4. Filtering errors[ Go to top ]

    The SuppressionFilter is probably the most appropriate for what you are suggesting.
    Yes, that filter can do the trick but it is not inconvenient for use IMO:
    Such check as
    <suppress checks="MagicNumberCheck"
    implies that I should edit the file and edit the file again when I edit main source file. Looks like error prone and inconvenient routine. How about some source code level remarks like:
    // @checkstyle:ignoreNextLines n=1
    for( int myStupidLongNameForLoopingVariable = 0;
  5. Filtering errors[ Go to top ]

    It's an open source project. If it doesn't do what you want, feel free to write your own improved version.
  6. Filtering errors[ Go to top ]

    It's an open source project. If it doesn't do what you want, feel free to write your own improved version.
    This exact attitude kills Open Source. No! Somebody (me) should not start new project just because an existing does not do exactly what that someone wants!!!
    Contribute!!! Ideas, code, submit bugs, etc.
  7. Filtering errors[ Go to top ]

    If an open source project doesn't do what you want you have three choices:

    1. Bitch and whine about the fact that it doesn't do what you want and expect someone else to fix it for you for free.
    2. Take the code and create your own version with the features you want. Whether you keep this version for your own private use or make it publicly available is up to you (depending on the licence terms).
    3. Take the code and add the features you want and submit it back to the original project so that others can benefit from your work, if it's judged good enough and useful enough.

    You seem to have opted for choice number 1.
  8. Filtering errors[ Go to top ]

    Bitch and whine about the fact that it doesn't do what you want
    Name depends on attitude. Are you trying to say that Open Source authors should accept no feature requests?
    and expect someone else to fix it for you for free.
    Yes, I do expect. Why not? Authors know codebase way better and what might be one hour work for them will require week or more from a lazy guy like me.
  9. Such check as<suppress checks="MagicNumberCheck"              files=""              lines="221"/>implies that I should edit the file and edit the file again when I edit main source file. Looks like error prone and inconvenient routine. How about some source code level remarks like:// @checkstyle:ignoreNextLines n=1for( int myStupidLongNameForLoopingVariable = 0;
    Could XDoclet be used to generate the suppressions file?
  10. Could XDoclet be used to generate the suppressions file?
    Good idea. Although I think XDoclet will not serve well because it does not care about line numbers IMO, so it will require a human to take care of line numbers and their changes.
    But a simple regexp based parser might work very well: algorithm might look like this: on a first pass parse all files line-by-line and search for comments like // @checkstyle:ignoreNextLines n=5, as the parser will have exact line number where such comment was discovered it may generate suppress file correctly and keep track of line number changes automatically.
  11. Filtering errors[ Go to top ]

    Check out Hammurapi waivers. They aren't bound to line numbers but to parse tree path. So if you have a waiver in, say, second for loop in third try block in method a() of class B you can freely modify all the rest of your code and the waiver will stay in place. If you modify that method, then waiver can become invalid. I think it is more robust way of binding to position in the source file comparing with line numbers.
  12. Filtering errors[ Go to top ]

    There was a long discussion about whether to use an embedded notation to suppress errors. Ultimately it was decided to not use this approach as:

    - It stopped Java code being polluted with "noise"

    - It allowed a central place where suppressions were entered - and hence monitored.

    - It allowed for more powerful suppressions like, ignore all complexity errors in package a.b.c.

    In practice, I use it on a large commercial project, this approach has worked well. But yeh, YMMV.
  13. Rather than filter out results, I'd suggest writing a custom check to replace the one you'd like to filter.

    As you have the source of the check you'd like to change, it should be simple to copy it and modify it to scan for
    // checkstyle:skip next line
    and throw away the error.

    I'm not sure I'd suggest going down this path though, as adding a facility to allow users to defeat the style checking system seems somewhat risky. I'd preffer to suffer through some noise in the result set.
  14. Thanks ;)[ Go to top ]

    Kudos and thanks to the CheckStyle team. I've been using it for years now, and it's been consistently helpful. I hope the 3.4 release improves the performance of the usage checks (unused method, can-be-private, etc.).
  15. Could you tell me what the theoretical basis of the metrics you compute is? NPathComplexity mentions Nejmeh (that I have never heard of), and CyclomaticComplexity sounds like McCabe, but I'm not sure.

    If you can give a short description of the background of the metrics, or point me to an url with a paper describing them, I would be very thankful.

  16. A good description of metrics can be found at This is the excellent plug-in for Eclipse. Search for Metrics - Meanings.
  17. Checkstyle 3.4 released[ Go to top ]

    This should be compulsory, if you've got a coding standard, use this, it's a must!

    Works a treat with Maven too.

  18. I tested hammurapi today and it seems to be pretty good (although seeing
    these 100+ warnings per file is not really fun ;) ). Is checkstyle
    something similar? Maybe somebody could post little comparision?

  19. There may be incompatibility with using the checkstyle ant task and ant 1.6's new import feature.

    I get a
    Can't find/access AST Node
    with a matching
    0: Got an exception - java.lang.ClassCastException
    for every file in the source.

    Using the supplied ant task.

    Did some googling and saw that Maven had a similiar problem a year ago.

    Guess I'll try a prior release or wait for a patch.
  20. Just a little more information on incompatiblity with 1.6:

    Checkstyle ANT Task documentation at:
    says that the task has been tested using ANT 1.5.

    Darn. We are using subant and import extensively so rolling back to 1.5 is out. Guess I will wait for the patch.
  21. Have you actually tried it? We use Checkstyle 3.4 successfully at work with Ant 1.6.1 and IBM JDK 1.3.1.
  22. Thank you everybody who responded to my post.

    It turns out it was weblogic.jar in my classpath that was stopping checkstyle from working. After removing it, checkstyle worked great. Weblogic also uses classes from Antlr (whatever that is, must be a java parser or something similiar).

    I'm happy now, was hoping it was something small on my part.
  23. George, we use Checkstyle with Ant 1.6.1 and have no problems with it.
  24. In fact we define a custom checkstyle macro with a standard set of stuff being done using the macrodef tag in a 'commons' ant build.xml and import this into our other builds, using checkstyle 3.4, ant 1.6.1 and ibm jdk 1.3.1 as oliver said and this this works great under cygwin, aix, and eclipse on NT environments.

    You can see samples of the macrodef and import in action on my blog entry;

    You will see the two example I use are clover and checkstyle.
  25. The reason for this problem is probably due to the way the classpath is set up, and not Ant 1.6 (I had the same problem with Ant 1.5 before I found a fix).

    To fix the problem make sure you do not have any old version of "antlr" in your classpath (either as antlr.jar, or bundled inside something else, which e.g. is done in weblogic.jar).

  26. Categorizing of deviations[ Go to top ]

    We've got huge code base with lots of deviations, we can't fix them all at once but we do want to keep track of different categories.
    Example categories are:
    - Whitespace issues
    - Coding issues
    - Documentation issues
    - Complexity issues
    - Block issues

    As I can see possible implementations are:
    1. add <property name="severity" value="XXXX"/> for each module used (checkstyle.xml), where XXXX can be "whitespace", "coding", "bug"...
    2. patch from checkstyle to accept any severity level defined in checkstyle.xml, not only "warning", "error", "ignore" and "info"
    3. write/adjust .xsl file which uses custom severity levels in generated xml output to group checkstyle errors.
    Any better ideas?
  27. ... no problems, but we don't use import yet. The ANTLR on the classpath sounds like a good thing to check ;)
  28. I had the exact same problem earlier. I ran ant from Cygwin. The script "ant" came with 1.6 release. It failed with those " Can't find/access AST Node " messages.

    Then I manually invoked ant: java -classpath "$ant_home/lib/ant.jar;$ant_home/lib/ant-launcher.jar" org....AntLauncher my_target

    It all worked fine. Then I looked at the "ant" script that I used earlier. It was almost the same except it didn't include ant.jar in -classpath switch.

    Don't know why. I have a really strange environment here: couple of ant versions plus Eclipse's own. So didn't try debug any further. Hope this helps though.