#64 Java 1.5 support

Michael Studman


I've attached a patch that adds initial support for Java
1.5 source code.

I've implemented the java 1.5 grammar; updated
TokenTypes with the new token types; replaced the 1.4
parser with the 1.5 parser in TreeWalker; and updated
certain checks so that they support 1.5 language
features or at least are less likely to choke on the
new nodes/node positions when they find them.

Here's an overview of the check changes I've done:

General check changes:

  • checks interested in package definitions changed to
    support cases when annotations are present on
    declaration (first child is no longer the package name)

  • many checks applicable to classes have been
    extended to support enum and enum constants; same
    has been done for checks supporting interfaces - now
    support same behaviour on annotations

Specific check changes:

  • LeftCurlyCheck - supports Java 1.5 constructs when
    calculating of correct left curly positions

  • HiddenFieldCheck - supports checking of fields in enum
    and enum constant class blocks

  • FinalClassCheck - ignores enum ctors

  • import checks changed to support static imports:

    • AvoidStarImportCheck
    • IllegalImportCheck
    • ImportOrderCheck
    • RedundantImportCheck
    • UnusedImportsCheck
  • javadoc checks changed to support and check
    javadoc on applicable Java 1.5 constructs:

    • JavadocMethodCheck - checks javadoc of
      annotation fields (which are akin to interface methods)
    • JavadocStyleCheck
    • JavadocTypeCheck - checks enum definitions and
      annotation definitions
    • JavadocVariableCheck - checks enum constants
      (akin to regular class/interface constants)
  • FinalParametersCheck - checks for-each clause
    parameter declarations for finality

  • ModifierOrderCheck - enhanced to check annotations
    (which are, in effect, special types of modifiers) are
    always first in set of modifiers

  • RedundantModifierCheck - enhanced to check
    redundant modifiers on annotation fields

Here's what I think needs to be done next:

  • Thorough examination of exisiting checks/creation of
    supplimental test input source to ensure full Java 1.5
    compatibility in all checks

  • Propose and implement new checks for Java 1.5-
    based coding standards

  • Decide if checkstyle is going to move its own code
    base to use Java 1.5 language features ("eating our own
    dog food", Oliver ;).

Here are some things to remember when
upgrading/testing checks for new language features:

  • PACKAGE_DEF node's first children may be
    ANNOTATION nodes (although this should only happen
    once per package and in the file "package-info.java" - a
    good candidate for the first Java 1.5-specific check, I

*STATIC_IMPORT's first child is the LITERAL_STATIC
node, then followed by the identifier

  • MODIFIERS node may contain zero or more
    ANNOTATION nodes (possibly interspersed with
    MODIFIER nodes and in any order)

  • LITERAL_FOR node may now have a FOREACH_CLAUSE

  • OBJECTBLOCKs have been reused for the body of
    ANNOTATION_DEF nodes so they may no longer hold
    what you expect

  • ENUM_CONSTANT_DEF nodes may not have
    MODIFIERS (but they may have annotations) so if you
    add this to your default/supported node set along with
    other types (CLASS_DEF etc), remember to be prepared
    for the MODIFIERS node to be null.

  • CLASS_DEFs and INTERFACE_DEFs may have a
    TYPE_PARAMETERS node immediately after the name
    IDENT node

  • Generic method invocations Foo.<String>bar() will
    result in a TYPE_ARGUMENTS node situated between
    the "Foo" IDENT node and the "bar" IDENT node. This is
    similar for fully qualified type names in expressions. E.g.
    new com.foo.Bar<String>.SomeInnerClass<Integer> s =
    new com.foo.Bar<String>().new

  • PARAMETER_DEF nodes may contain a TRIPLE_DOT
    node immediately after the parameter type node.

Michael Studman.


  • Logged In: YES

    I believe this patch is already applied by Michael,
    so I close it.